Personal memory can be messy. Team memory cannot be messy in the same way.
The moment memory becomes shared, it starts doing organizational work. It can become source material for decisions, drafts, status updates, plans, and external actions. That means permissions are not an administrative detail. They are part of the architecture.
Job
The permissions layer decides who can read, write, approve, and act.
It also decides which records an agent is allowed to use as source material.
Inputs
The layer needs a map of:
- memory sources
- owners
- reviewers
- read access
- write access
- approval rights
- external action rights
- retention rules
- records that must never be used as source material
The system should not rely on vibes like "the team has access." Access to a folder is not the same as permission to use a record in an agent-generated answer.
Processing
Before retrieval runs, the system should filter by the requester's permissions and the workflow's authority.
Before action runs, the system should check whether the action is allowed, whether approval is required, and what must be logged.
Before memory is updated, the system should check whether the update changes a canonical record, who approved it, and whether older records should be superseded.
Output
The output is an authorization decision plus a trace.
The trace should say what was allowed, what was blocked, and why. A blocked record can still matter. Sometimes the system should say, "There may be relevant context, but this workflow is not allowed to use it."
Review Question
The review question is: could a human with the same role have used this source or taken this action?
If not, the agent should not be able to do it quietly.
Failure Mode
The failure mode is implicit permission.
The agent retrieves from everywhere it can technically reach, then a human reviews the polished output without seeing which boundaries were crossed. That is not a productivity problem. It is an accountability problem.