Shared agent memory needs a permission check on every read

I work at Permit. One of our AI engineers wrote a post about shared memory for coding agents, and since we sell authorization, read the framing with that in mind. I think the problem it describes holds up either way.

Shared team memory for coding agents is handy. One agent figures out a repo's quirks, and the next person's agent gets that context for free. Those entries can also hold architecture details, internal file paths, hints about credentials and old decisions. Once memory outlives a session and spans users, every retrieval is an agent being handed access to that knowledge on someone's behalf.

The revocation gap

Say someone loses access to a repo at 2:00 PM. If memory access was decided at onboarding, or got cached high in the stack, their agent can still pull what it learned about that repo at 2:01 PM. Reads and writes need a check at the time they happen, against current state.

Redaction and encryption don't decide who reads what

Redaction strips known-sensitive bits before they're stored. It helps, but it depends on patterns and misses secrets that don't look like secrets. Encryption protects the data at rest and in transit. Neither one says whether this person should see this plaintext once it's decrypted. That's an authorization decision, and it has to be made per request.

Modeling it as relationships

The post uses ReBAC. A human operates or delegates to an agent, the agent works in a team context, the team belongs to a project, and memory entries hang off the project, optionally scoped by repo and path. A rule then reads like this: the agent can read an entry if it acts for an active project member, the team can see the repo, and the current task scope matches the entry's tags. Remove one relationship and everything downstream of it stops resolving.

Whose permissions does the memory server use?

Picking just one source causes trouble. Inheriting the human's permissions overexposes memory when agents juggle several tasks or async jobs. Project-level inheritance is too broad for repos with mixed sensitivity. Agent-level inheritance lets long-lived agents build up standing privilege. The post lands on the intersection of the human's rights, project policy and the agent's scope for the current task, all evaluated at decision time.

What to log

For each retrieval decision the post wants human, agent, project, query, memory entry, decision and outcome, plus a timestamp, the policy version and a correlation ID. Without those you can't explain why an agent saw something, or whether a revocation took effect in time.

The full post also has an FAQ on team vs. project scoping and on Claude Code and Codex team memory: https://www.permit.io/blog/shared-agent-memory-is-a-permissions-problem?utm_source=devto&utm_medium=social&utm_campaign=shared-agent-memory-is-a-permissions-problem&utm_content=authbyexample-article

If you run shared memory for agents today, where does your check sit: inside the memory server, or in front of it?