The trust model #

The system does not have a single trust level. Five properties vary independently, and an honest description names each one separately.

The five properties #

Distinctness. Does each agent context have its own identity at all? This is naming and provisioning, it costs almost nothing, and it is what makes every other property expressible. Without it there is one credential shared by everything the user runs, and no question below can even be asked.

Custody. Can an agent act as another agent? This depends entirely on where keys live and what separates them from the agent. It is the property that swings hardest with environment: subagents sharing a process are the hard case, and a container per agent makes it nearly free.

Propagation. Does the identity reach a downstream callee in a form it can verify? Orthogonal to custody — a system can propagate an identity nobody can check, or hold keys perfectly and never tell anyone downstream who is calling.

Provenance. Is there a statement from outside this stack about where an agent came from? A device credential, a cloud instance identity document, a workload attestation. Note that this moves in the opposite direction from custody: a shared local machine gives weak custody and usable provenance, while a cloud deployment gives strong custody and stronger provenance still.

Accountability. Can a stranger trace an agent to a responsible human, and can that be withdrawn? Two records, one written by the server into the agent's repository and one written by the owner into their own, checked against each other by somebody who trusts neither — see verifying who an agent belongs to. It holds at any state of the other four, though it means less when custody is weak, because then it attests to an identity somebody else could have claimed.

Where this implementation sits #

The strongest verifiable claim is about the node. Below that:

• Session is asserted by the harness. Credentials are delivered at this granularity, because CLAUDE_ENV_FILE is the only supported way to put a value into tool execution and it is session-scoped.
• Subagent is attribution only. Subagents spawned by the Task tool share a process with their parent; distinct identities scope policy and label actions, and are not claimed to contain a hostile in-process subagent.

What the model can and cannot lie about #

An agent's own model never asserts which agent it is. Identity comes from the harness's hook payload; the model supplies only content. So a model that has been prompt-injected, or is simply confused, can lie about what it is doing. It cannot lie about which agent is doing it.

This is mechanically enforced, not merely organisational: a stamp the harness writes always overwrites whatever a model put under the same key, and a call arriving with a stamp that disagrees with what the harness independently computes is denied outright rather than silently corrected — a forged claim is loud, not merely ineffective.

That guarantee stops at the trust domain. Arbitrary code execution in the same domain can address the credential path directly and claim any agent within it. Per-agent unix users or containers move that boundary and remain a deployment choice.

What follows from this #

Identity is the harness's to assert, never the model's. A record's author comes from the hook payload. A model can lie about what it is doing and not about which agent is doing it.

Only facts an agent cannot assert about itself may select policy. The node is attested. The agent and its parent are known because this server minted them. Anything an agent writes — its status text, a requested label — selects nothing.

Every provenance claim carries how it was learned. attested is a credential that was checked, server is something known because this server did it, harness is the tooling's word, transcript is read out of a file with no promised shape. A rule keyed on a transcript-sourced value is weaker than one keyed on the node, and the record says so.

Policy is authored where this server cannot write. The owner writes it to their own personal data server. This server polls it and enforces it, and holds no write scope there. A compromised server can therefore break policy but not change it, and the rule it is breaking stays readable somewhere it cannot reach.

Withdrawal is refusal at the write. A token is permission to write here, so a live token is not authority: the write arrives, current policy is read, and it is refused. There is nothing to revoke.

Three things are auditable from outside. From an agent: which server it is on. From an agent or a server: which DID controls it. From a controlling DID: what policy it has published, and which agents it claims. The third is derived from the server's own listing and is a lower bound, not a roster; ownership-verification.md says what makes it undercount.