Skip to content
1Claw Academy
Curriculum/Agents & Access Control3 minIntermediate · Lesson 10 of 15

Peer memory: access control for what nobody granted

Several agents can share a model of one human. That model is derived, not granted, which changes what access control has to mean.

Everything so far in this track has been about access to something a human explicitly created or owns: a secret, a vault, a delegation. Peer memory is different in kind. When several agents serve the same person, each one that learns their approval habits independently learns less than the group could learn together. A peer is that shared model: what a person has approved, how confidently, and why the system believes it.

It is also the most sensitive thing an agent can read about someone, and unlike a secret, nobody deliberately granted it. A password exists because a human typed it in. A behavioral profile exists because the system noticed a pattern. That difference is why the access model here is stricter than anything else in this track, not looser.

  • An agent may read or write a peer only if it is named in observer_agent_ids, full stop.
  • Same organization grants nothing. Same platform connection grants nothing. A broad scope grants nothing.
  • A peer with no observers is readable by no agent at all, not by every agent.
  • Creating a peer, which decides who observes it, is human-only. An agent that could create one could add itself as an observer.
Watch out

That third point is deliberate, not an oversight. If an empty observer list meant "everyone", forgetting to set observers would expose someone's behavioral profile to every agent in the org, silently and totally. Empty means nobody, the same deny-by-default default this course has taught since Access Control Models.

What actually gets derived is narrower than it sounds. The system tracks approval tendencies, and only from a consistent history: per fingerprint bucket (action, amount band, new-or-known recipient), never per action type in general, so three approvals of $5 do not become a belief that spans $500. Three observations minimum: two is a coincidence. A mixed history, someone who sometimes says no, is not recorded as a tendency at all, because deciding case by case is the opposite of a pattern worth automating. And confidence is capped below certainty; a score of 1.0 would read downstream as "no need to check", which is never true.

Concept

POST /v1/peers/{id}/predict-approval returns likelihood (an observation about the person) and suggest_auto (a statement about your own action_approval_policy) as two separate fields. suggest_auto is true only where a rule you already wrote would auto-approve this exact case, and it carries a blocked_reason when it is not.

That separation is the whole point. A confident model of a person never becomes new authority by itself. If you never wrote a rule for this action, no_matching_rule comes back regardless of how many times the person has said yes before. An absent rule is not permission, the same principle behind deny-by-default policy engines, applied to a prediction instead of a request.

Every derived fact carries provenance, naming the events it came from. When those events pass the 90-day retention window, each entry becomes a tombstone: it keeps the kind of event and the decision, and drops the content. The belief outlives its transcript without losing its basis, so "why does this system think that about me" stays answerable years later. A human correction always outranks a re-derived inference; editing a fact stops the processor from overwriting it, because a correction that inference silently reverses is not a correction.

Decide

Two of your agents serve the same customer-support user: a triage bot and a refund bot. The refund bot's policy auto-approves refunds under $20 for a peer with a strong approval history. The triage bot calls predict-approval on that peer to decide whether to fast-track a $15 refund request it received.

What does the triage bot's call return, and why?

Platform connections provision a peer automatically on bootstrap, with that connection's agents as observers, and re-running bootstrap merges observers rather than replacing them, so adding a new agent to a connection does not revoke the ones already watching. MCP exposes only get_peer_context to agents; creating a peer and changing its observer list have no MCP tool and stay human actions, the same pattern this course has taught for every action with a high blast radius.

Check your understanding

4 questions
1

An agent is in the same organization as a peer but not named in its observer_agent_ids. What can it read?

2

Why does an empty observer_agent_ids list mean "no agent may read this peer" rather than "every agent may"?

3

predict-approval returns likelihood: 0.9 and suggest_auto: false with blocked_reason: no_matching_rule. What does this mean?

4

A fact's supporting event passes the 90-day retention window. What happens to the fact?