Agent memory access control

If an agent can read everything a user can see — or write anything into the index — you do not have a company brain. You have a confused deputy with a vector store. Agent memory access control means agents are principals with explicit rights over memory operations: read, write, promote, and admin.

Why agents need their own scopes

Humans already have messy entitlements. Agents multiply risk:

  • They act at machine speed across many tools
  • They are invoked in shared channels where the “user” is ambiguous
  • They may be chained (agent A calls agent B) with inherited context
  • Prompt injection can steer them toward exfiltrating memory

Least privilege is not optional once memory drives customer, HR, or financial actions.

Operations to gate

Model policy on verbs, not only documents:

Verb Meaning
memory.read Retrieve records / chunks in a class
memory.write_draft Propose new or updated memory
memory.promote Move draft → canonical (usually human or privileged agent)
memory.delete / retire Tombstone or remove
memory.admin Change owners, ACLs, retention

A support agent might read playbooks and write_draft incident notes, but never promote pricing policy.

Design principles

  1. Separate human and agent identities — Service accounts / agent IDs in your IdP or brain product.
  2. Scope by data class — e.g. public product docs vs employee records vs customer PII.
  3. Default deny on write — Especially promote and delete.
  4. Short-lived credentials — Tokens bound to session, workflow, or ticket.
  5. No ambient authority from the chat UI — Opening a thread should not grant the agent the opener’s full drive.
  6. Log every memory access that influences an action — query, record IDs, policy decision.

Patterns that work

  • Brokers — Agents call a memory API that enforces policy; they never get raw DB credentials.
  • View-like projections — Materialize safe subsets for particular agent roles.
  • Dual control — Promote requires human approval or a second privileged principal.
  • MCP / tool servers with per-tool ACLs — expose search_playbooks not sql_query.

Products such as Mensara aim to make policy part of the memory plane; whether you buy or build, insist on agent-level ACL demos.

Anti-patterns

  • Indexing all Confluence into one collection shared by every bot
  • “The agent uses the user’s OAuth” for all memory with no reduction
  • Storing secrets in the same store as narrative playbooks
  • Skipping audit logs because “it’s just RAG”

Proof for operators

In a design review, demand:

  • A matrix of agent roles × memory classes × verbs
  • A forced-denial demo (agent blocked from HR memory)
  • Sample audit events for a single customer reply
  • Incident response: how to revoke an agent’s memory scope quickly

Pair this guide with Governed memory vs RAG and Evaluating company brain products. Access control is where company brains become real systems instead of demos.