Permission Reference

What you can do in MemoryLake — what pages you can open, what buttons you can click, what API calls succeed — depends on the permissions your team admin has granted you. This page is your guide:

• Each capability is described in plain language with what it lets you do and what you’ll see when it’s missing.
• The exact permission identifier is shown in each entry — copy that to your admin if you need a permission added.

​

How permissions reach you

Permissions reach an individual member through three layers your admin controls:

1. Role — the built-in roles (Owner / Admin / Member) come with a default bundle of capabilities. Owners can also create custom roles by cloning a parent role or starting blank. See Roles and Permissions.
2. Permission policy — Allow / Deny rules layered on top of the role. Admins use these to override role defaults (e.g. let Members create projects).
3. Resource scope — per-member whitelist of specific workspaces, projects, or other resources a member can act on, plus the subset of operations allowed on each. This is how an instance-level capability gets narrowed to one or two workspaces or projects.

API Keys are programmatic identities (Service Accounts) — each one inherits the role and resource scope of the member who created it. Removing a member revokes every key they own.

​

How to spot a missing permission

You don’t have to memorize anything. MemoryLake makes missing permissions visible in predictable ways:

​

How permissions are grouped

Permissions live on seven resources. Every capability below belongs to one of them:

​

Lists are filtered, not gated

There is no permission for seeing a list. Every list endpoint returns the rows you may open and leaves out the rest, so a list is never refused for want of a permission — it comes back shorter. A workspace list shows the workspaces you hold workspace:read on, a project list the projects you hold project:read on, and so on down each resource. This replaces an earlier set of *_list capabilities, which could be held without the matching *_read and produced rows you could see but not open. If you are looking for project:list, workspace:list, actor:list, agent:list or any of their siblings, that is why they are gone: holding *_read is holding the list.

​

How permissions are granted

Every capability has a Level — instance or service — that determines whether your admin can narrow it down to specific resources. Each entry below shows the level in its Level line.

---

​

Common role recipes

These are typical capability bundles to use as starting points when you’re either building a custom role or adding permission policies on top of the built-in Member role. They are not pre-built roles — Owners assemble them via Team > Permission Settings, then narrow instance capabilities to the right resources via the member’s Resource Scope when assigning the role.

---

​

Working with workspaces

​

Create a new workspace

Lets you start a brand-new workspace from scratch. Without it: “New workspace” buttons are hidden or greyed out. Identifier: workspace:create Level: service — applies team-wide (not tied to a specific resource instance).

---

​

Open a workspace

Lets you open a workspace and view its contents. This permission also gates workspace-scoped search — the Search Memories API requires it. Without it: workspace cards appear faded and clicking does nothing. Typing the workspace URL directly shows a full-page “no permission” message. Workspace-level search calls return 403. Identifier: workspace:read Level: instance — granted on a specific workspace.

---

​

Edit workspace settings

Lets you rename a workspace, edit its description, and change its configuration. Without it: all “Rename” and “Edit” options are greyed out wherever they appear. Identifier: workspace:modify Level: instance — granted on a specific workspace.

---

​

Delete a workspace

Lets you permanently remove a workspace. Without it: “Delete” options are greyed out on every workspace card and dialog. Identifier: workspace:delete Level: instance — granted on a specific workspace.

---

​

Managing conversations in a workspace

Conversations are workspace-scoped — they live in a workspace and are linked to one or more projects where extracted facts are stored.

​

Read a conversation

Lets you open a conversation and read its messages, including batch-fetching multiple messages at once. Without it: conversation rows appear faded; clicking does nothing. Identifier: workspace:conv_read Level: instance — granted on a specific workspace.

---

​

Send a message to a conversation

Lets you append a new message to an existing conversation. Without it: the message input area is disabled and explains it needs the conversation-append permission. Identifier: workspace:conv_append Level: instance — granted on a specific workspace.

---

​

Delete a conversation

Lets you permanently remove a conversation from a workspace. Without it: “Delete” actions on conversations are greyed out. Identifier: workspace:conv_delete Level: instance — granted on a specific workspace.

---

​

Managing actor bindings in a workspace

Actors are created globally, then bound to workspaces to operate within them. These permissions control which actors can participate in a workspace.

​

Bind an actor to a workspace

Lets you add an existing actor to a workspace so they can participate in conversations and accumulate facts. Without it: the “Add actor” action is greyed out. Identifier: workspace_actor:create Level: instance — granted per actor, in one workspace.

---

​

Remove an actor from a workspace

Lets you unbind an actor from a workspace — they stop participating, but their globally-stored identity and facts remain. Without it: the per-actor “Remove” action is greyed out. Identifier: workspace_actor:delete Level: instance — granted per actor, in one workspace.

---

​

Managing actor facts in a workspace

Actor facts are knowledge about a specific person that accumulates across projects within a workspace. These permissions control access to that per-actor knowledge. An agent’s own facts are governed separately, by the workspace_agent:fact_* permissions under Managing agent facts in a workspace.

​

Read an actor fact

Lets you view the full content of a specific actor fact. Without it: fact rows appear faded; clicking does nothing. Identifier: workspace_actor:fact_read Level: instance — granted per actor, in one workspace. Covers these APIs: List Actor Facts, Get Actor Fact, Get Actor Fact Change History.

---

​

Update an actor fact

Lets you edit the content of an actor fact. Without it: “Edit” actions on actor facts are greyed out. Identifier: workspace_actor:fact_modify Level: instance — granted per actor, in one workspace. Covers these APIs: Add Actor Facts, Update Actor Fact.

---

​

Forget an actor fact

Lets you forget an actor fact, which takes it out of retrieval and search. Its change history is kept. Without it: “Forget” actions on actor facts are greyed out. Identifier: workspace_actor:fact_delete Level: instance — granted per actor, in one workspace. Covers these APIs: Forget Actor Fact, Batch Forget Actor Facts.

---

​

Review actor memory conflicts

Lets you list an actor’s memory conflicts and open one to see the facts involved. Without it: these requests return 403. Identifier: workspace_actor:fact_conflict_read Level: instance — granted per actor, in one workspace. Covers these APIs: List Actor Memory Conflicts, Get Actor Memory Conflict.

---

​

Resolve an actor memory conflict

Lets you resolve a conflict between an actor’s facts. Resolving can forget facts or rewrite their text. Without it: resolve requests return 403. Identifier: workspace_actor:fact_conflict_resolve Level: instance — granted per actor, in one workspace. Covers this API: Resolve Actor Memory Conflict.

---

​

Managing agent bindings in a workspace

Agents are created globally, then bound to workspaces to serve conversations. These permissions control which agents can operate in a workspace.

​

Bind an agent to a workspace

Lets you add an existing agent to a workspace so it can serve conversations. Without it: the “Add agent” action is greyed out. Identifier: workspace_agent:create Level: instance — granted per agent, in one workspace.

---

​

Remove an agent from a workspace

Lets you unbind an agent from a workspace — it stops serving conversations, but its global definition and version history remain. Without it: the per-agent “Remove” action is greyed out. Identifier: workspace_agent:delete Level: instance — granted per agent, in one workspace.

---

​

Managing agent facts in a workspace

An agent’s own facts — what it has learned, and how it is meant to behave — accumulate across projects within a workspace, separately from any person’s. These permissions control access to them. They are granted per agent, in one workspace, and are separate from the workspace_actor:fact_* permissions: access to a person’s memories gives none to an agent’s, and the other way round.

​

Read an agent fact

Lets you list an agent’s facts, read one, and read its change history. Without it: these requests return 403. Identifier: workspace_agent:fact_read Level: instance — granted per agent, in one workspace. Covers these APIs: List Agent Facts, Get Agent Fact, Get Agent Fact Change History.

---

​

Add or update an agent fact

Lets you add facts to an agent and edit existing ones. Without it: these requests return 403. Identifier: workspace_agent:fact_modify Level: instance — granted per agent, in one workspace. Covers these APIs: Add Agent Facts, Update Agent Fact.

---

​

Forget an agent fact

Lets you forget an agent fact, which takes it out of retrieval and search. Its change history is kept. Without it: these requests return 403. Identifier: workspace_agent:fact_delete Level: instance — granted per agent, in one workspace. Covers these APIs: Forget Agent Fact, Batch Forget Agent Facts.

---

​

Review agent memory conflicts

Lets you list an agent’s memory conflicts and open one to see the facts involved. Without it: these requests return 403. Identifier: workspace_agent:fact_conflict_read Level: instance — granted per agent, in one workspace. Covers these APIs: List Agent Memory Conflicts, Get Agent Memory Conflict.

---

​

Resolve an agent memory conflict

Lets you resolve a conflict between an agent’s facts. Resolving can forget facts or rewrite their text. Without it: resolve requests return 403. Identifier: workspace_agent:fact_conflict_resolve Level: instance — granted per agent, in one workspace. Covers this API: Resolve Agent Memory Conflict.

---

​

A2A protocol operations

​

Use the A2A protocol

Lets you initiate and participate in Agent-to-Agent (A2A) protocol operations within a workspace. Without it: A2A requests to this workspace return 403. Identifier: workspace_agent:a2a Level: instance — granted per agent, in one workspace.

---

​

Working with actors

​

Create an actor

Lets you create a new actor — a person or assistant that can accumulate facts across workspaces and projects. Without it: “New actor” buttons are hidden or greyed out. Identifier: actor:create Level: service — applies team-wide (not tied to a specific resource instance).

---

​

View an actor

Lets you open an actor and see their configuration and details. Without it: actor rows appear faded; clicking does nothing. Typing the actor URL directly shows a “no permission” message. Identifier: actor:read Level: instance — granted on a specific actor.

---

​

Edit an actor

Lets you update an actor’s name, description, and other settings. Without it: all “Edit” options on the actor are greyed out. Identifier: actor:modify Level: instance — granted on a specific actor.

---

​

Delete an actor

Lets you permanently remove an actor. Without it: “Delete” options on actors are greyed out. Identifier: actor:delete Level: instance — granted on a specific actor.

---

​

Working with agents

​

Create an agent

Lets you define a new agent with its model, system prompt, and capabilities. Creating an agent automatically creates a corresponding actor. Without it: “New agent” buttons are hidden or greyed out. Identifier: agent:create Level: service — applies team-wide (not tied to a specific resource instance).

---

​

View an agent

Lets you open an agent and see its configuration — model, system prompt, capabilities, and policies. Its version history comes with it: listing past versions and opening any one of them are part of reading the agent, not permissions of their own. Without it: agent rows appear faded; clicking does nothing. Identifier: agent:read Level: instance — granted on a specific agent.

---

​

Edit an agent’s identity

Lets you update an agent’s identity fields — name, description, and other top-level settings that apply across all versions. Publishing a new version is the same permission: a version is a snapshot of the agent, so changing what it will be next is changing the agent. Without it: “Edit” options on the agent’s identity are greyed out. Identifier: agent:modify Level: instance — granted on a specific agent.

---

​

Delete an agent

Lets you permanently remove an agent and all its versions. Without it: “Delete” options on agents are greyed out. Identifier: agent:delete Level: instance — granted on a specific agent.

---

​

Working with projects

​

Open a project

Lets you click a project card and view its contents — the project’s home page and every tab inside it. Without it: project cards appear faded and clicking does nothing. Typing the project URL directly shows a full-page “no permission” message. Identifier: project:read Level: instance — granted on a specific project.

---

​

Create a new project

Lets you start a brand-new project from scratch. Without it: “New project” buttons are hidden or greyed out — on the list page, in the first-project onboarding card, in the quick-start wizard, and on the integrations page. Identifier: project:create Level: service — applies team-wide (not tied to a specific resource instance).

---

​

Edit project settings

Lets you rename a project, edit its description, change which industry it belongs to, and share it with others. The “Bind industry” button inside the chat composer also depends on this. Without it: all “Rename”, “Edit”, and “Share” options are greyed out wherever they appear. Identifier: project:modify Level: instance — granted on a specific project.

---

​

Delete a project

Lets you permanently remove a project. Without it: “Delete” options are greyed out on every project card and dialog. Identifier: project:delete Level: instance — granted on a specific project.

---

​

Search across a project (API-only)

Lets you call the Search Memories API to query documents and facts within a project at once. Where this matters: API integrations only. In the console, search inside a project goes through the document-search and fact-search permissions below. Identifier: project:search Level: instance — granted on a specific project.

---

​

Working with documents inside a project

​

Read a single document

Lets you fetch full document details through the API. Where this matters: mostly API integrations, plus the console’s background poll that refreshes document processing status. Console file downloads go through the Read your files permission in the Library section. Identifier: project:doc_read Level: instance — granted on a specific project. Covers this API: Get Document.

---

​

Add a document to a project

Lets you bring a file into a project — through the “Add document” button, the empty-state upload card, and the upload icon inside the chat composer. Without it: every “Add document” / upload entry point is greyed out. Identifier: project:doc_add Level: instance — granted on a specific project.

---

​

Remove a document from a project

Lets you take a document out of a project, one at a time or in bulk. Without it: the per-row “Remove” action and the batch-remove action on the Files tab are greyed out. Identifier: project:doc_delete Level: instance — granted on a specific project.

---

​

Search documents inside a project (API-only)

Lets you run semantic search queries over the documents in a project. Where this matters: API integrations only. The console’s in-document search is wired to its own controls. Identifier: project:doc_search Level: instance — granted on a specific project.

---

​

Working with facts inside a project

​

Read a fact’s content

Lets you click a fact row to open its detail panel — full content, timestamps, and source information. Without it: fact rows show as faded; clicking does nothing; drilling into a keyword from the cloud also fails. Identifier: project:mem_read Level: instance — granted on a specific project. Covers these APIs: Get Fact, Get Fact Change History.

---

​

Search facts

Lets you find facts by keyword. The search box at the top of the Facts tab depends on this. Without it: the search box itself is hidden — you can scroll the list but you can’t filter it. Identifier: project:mem_search Level: instance — granted on a specific project. Covers this API: Search Memories.

---

​

Add a fact via API (API-only)

Lets you push a fact in directly through the API. Where this matters: API integrations only. Inside the console, facts are produced automatically from conversations and document ingestion — there’s no manual “add a fact” button. Identifier: project:mem_add Level: instance — granted on a specific project. Covers this API: Add Facts.

---

​

Update a fact

Lets you edit an existing fact’s content. Without it: “Edit” actions on facts are greyed out. Identifier: project:mem_modify Level: instance — granted on a specific project.

---

​

Forget (delete) a fact

Lets you make MemoryLake forget a fact, one at a time or in bulk. Without it: the per-row “Forget” action and the batch-forget action are greyed out. Identifier: project:mem_delete Level: instance — granted on a specific project.

---

​

Resolve conflicting facts

Lets you see the Conflicts tab inside a project, review each conflict, and pick how to resolve it. Without it: the Conflicts tab disappears entirely — you can’t see whether conflicts exist or what they’re about. Identifier: project:mem_conflict_resolve Level: instance — granted on a specific project.

---

​

Managing MCP for a project

An MCP server is the connection point that lets a third-party tool (Claude desktop, an MCP-compatible client, or your own app) talk to a specific project on your behalf. Each MCP server is issued its own credential. The four permissions below split the lifecycle into see / list / create / revoke.

​

See the Integrations tab

Lets you open the Integrations tab on a project — where MCP servers are listed and managed. Without it: the Integrations tab is hidden from the project’s side menu. Identifier: project:mcp_read Level: instance — granted on a specific project.

---

​

View existing MCP servers

Lets you see the list of MCP servers issued for a project, including when each one was created and what it’s named. Without it: the integrations page shows an empty “no permission” state, even when MCP servers exist. Identifier: project:mcp_list Level: instance — granted on a specific project.

---

​

Create a new MCP server

Lets you set up a new MCP server to connect a third-party tool to the project. Without it: the “Add integration” / “Create MCP server” button is greyed out. Identifier: project:mcp_add Level: instance — granted on a specific project.

---

​

Revoke an MCP server

Lets you delete an existing MCP server — immediately disconnecting everything that was using it. Without it: the per-row “Delete” / “Revoke” action is greyed out. Identifier: project:mcp_delete Level: instance — granted on a specific project.

---

​

Working with your Library

Your Library is the shared file space that sits underneath every project. When you “add a document to a project”, the file goes into your Library first and the project just links to it. The four permissions below apply across all your projects at once — they are not granted per project.

​

Read your files

Lets you browse the file tree, see thumbnails, preview files in the viewer, download files, and read the comments people have left on them. Without it: thumbnails fall back to plain file-type icons, “Download” menu items grey out, file previews are skipped, and comment panels degrade silently. Identifier: drive:item_read Level: service — applies team-wide (not tied to a specific resource instance). Covers these APIs: Get Item, List Items.

---

​

Upload and create files

Lets you upload files, create folders, and attach external storage. This is the permission that runs in the background whenever you click “Add document” or drag a file into the app. Without it: “New folder” and “Upload file” entry points are greyed out everywhere, including inside the “Add document” dialog. Identifier: drive:item_add Level: service — applies team-wide (not tied to a specific resource instance). Covers these APIs: Create Upload, Create Item.

---

​

Edit your files

Lets you rename files, move them between folders, edit their metadata and tags, and save comments. This also covers managing custom attributes (xattrs) on files via the API. Without it: rename, move, and edit-metadata options grey out. The “Save” button on the comment panel is disabled and explains it needs the file-edit permission. Identifier: drive:item_modify Level: service — applies team-wide (not tied to a specific resource instance). Covers these APIs: Set Item Xattrs, Delete Item Xattrs.

---

​

Delete files

Lets you permanently delete files and folders, one or in bulk. Without it: all “Delete” actions on files and folders are greyed out. Identifier: drive:item_delete Level: service — applies team-wide (not tied to a specific resource instance). Covers these APIs: Delete Item, Batch Delete Items.

---

​

Quick troubleshooting

---

Looking for a bird’s-eye list of all permissions grouped by area? See the Permission catalog on the Team collaboration overview. If the capability you need doesn’t appear on your role, contact your team’s owner or administrator. They can adjust roles in Teams > My Teams > Members.