Agent identity

An agent is named by an agent:// URI, proves what it may do with a signed capability attestation, and derives its authority from a delegation that terminates at a human principal.

Naming: agent://

An agent is identified by a URI under an issuing authority:

agent://acme.example/agent/ap_clerk

The authority component is the domain that vouches for the agent. The path is the agent's identity within it. The URI is what appears in policy delegations, in provenance records, and on every transaction the agent proposes — so an auditor reading a five-year-old entry can say exactly which actor, under which issuing authority, proposed it.

Axorum consumes the published agent-uri crates as they are, without forking them. The scheme is meant to be a standard that outlives any one implementation of it, including this one.

Proving: PASETO attestations

Naming an agent is not the same as believing it. An intent carries a capability attestation: a PASETO v4.public token, signed by the issuing authority, that names the agent URI and the capabilities the authority grants it.

The gateway verifies the signature against the authority's registered public key, checks that the token is within its validity window, and checks that the action being proposed is covered by the capabilities the token grants. A token that authenticates the agent but does not cover the action is not enough. Identity and authority are separate questions and both are asked.

Verification takes its time as an injected parameter rather than reading a clock, so the check is deterministic and testable, and so that it cannot become a source of divergence between replicas.

Trusting: trust roots

An authority is believed because it was registered as a trust root: a domain paired with a public key, admitted through the administrative plane and replicated through consensus like any other ledger state.

An attestation signed by a key nobody registered is worth nothing, no matter how well-formed. The trust roots are the boundary of the system's credulity, and they are explicit, enumerable, and on the record.

Delegating: the chain to a principal

Identity and attestation establish that the agent is who it says and holds the capability it claims. Neither establishes that it should be spending this organization's money.

That comes from the delegation, declared in policy: a principal grants an agent a scope — which actions, in which roles, within which window of ticks. On every proposal the gateway resolves the delegation join, and it resolves it against this action, not merely against this agent. The delegation is live only if the agent matches and the proposed action falls inside its scope and its window.

The chain terminates at a principal: a human who can be named, asked, and held responsible. An agent's authority is always borrowed. There is no rule that grants an agent standing on its own account, because an actor that cannot be held responsible cannot hold authority.

The gateway is the quarantine

The agent boundary is where non-determinism is allowed to exist: URI resolution, signature verification, clock-adjacent validity checks, capability coverage. All of it happens at the gateway, and none of it happens in the ledger.

An authentication failure is an error. It never reaches the commit point, it never produces a verdict, and it never appears in the normative log — because a request from an actor who could not be identified is not a refused transaction, it is not a transaction at all.

What crosses into the ledger is a proposal from an identified, attested, delegated actor. Everything past that boundary is deterministic, and that is precisely why the boundary is drawn there.