Sovereign Agentic Cognition

Portable Agent Records

This page uses sovereign for an agent whose identity, capability tokens, and Agent Passport can be presented across operators. Moving an agent to another host, operator, or wallet does not by itself transfer an operator's records or access decisions. The described DID, capability, and credential formats are shipped components; their use depends on the operator and policy configuration.

Identity Derived From a Key

An agent's identity is a DID of the form did:chio:<64-hex>, derived directly from an Ed25519 public key by the chio-did crate. Resolving it produces a standard W3C DID document. Resolution requires no network calls because the public key is encoded in the DID. The derivation is deterministic and local; no registry or issuer assigns the DID. The identifier encodes the agent's public key:

{
  "id": "did:chio:4f3c9a1e7b2d5f80c6e91a3b7d4f2c8e1a5b9d3f7c2e8a4b6d1f9c3e7a5b2d8f"
}

The hex encodes the public key. DID resolution and signature verification use that key, although they are distinct operations. A holder of the matching private key can prove control of the DID to a verifier. This differs from workload identity, which identifies the process that presents a capability.

Authority in Capability Tokens

Chio represents authority as a capability token plus its delegation chain, and the kernel verifies both from the token itself: signature, expiry, and a scope-subset check (ToolGrant::is_subset_of) that checks whether a delegated grant is a subset of the authority the delegator held. This verification does not call the service that minted the token. The verification logic lives in chio-kernel-core, compiles no_std, and runs identically whether the enforcement point is a desktop sidecar, a browser tab (wasm), or a mobile app (UniFFI). Authority travels with the agent because the logic that checks it travels with the agent too. The token and its verifier can be presented with the agent; deployment policies still determine whether a verifier accepts them.

Reputation Credentials

An Agent Passport packages issuer-signed identity and reputation credentials (AgentPassport, backed by a ReputationCredential, minted by the chio-credentials crate). The passport projects into OID4VCI, OID4VP, and SD-JWT, the standard verifiable-credential issuance and presentation formats, so an external wallet the agent's principal controls can hold it directly. Cross-issuer migration requires support from both issuers and the relying party. See Reputation & Passports for the full credential shape.

Governing External Effects

Chio governs calls at the boundary. It does not inspect an agent's intermediate model tokens. A call routed through Chio is a mediated call that must clear the kernel before the tool receives it.

Two checks apply at that boundary:

• A capability answers “was this authorized?” It is a static question resolved against delegated authority fixed at issuance time (signature, expiry, scope).
• A guard answers “should this specific action happen now in this session?” It is a dynamic question, resolved against live context (session state, spend to date, the exact arguments of this call).

Both checks must pass for a mediated call. A valid capability without guard approval does not execute, and guard approval cannot grant authority absent from the capability. This boundary applies only to calls routed through the kernel.

Managed Processes and Portable Credentials

The following comparison distinguishes operator-managed records from portable credentials. Actual deployments can combine both models:

Potential Use in Markets

These components can give a counterparty inputs for dealing with an unfamiliar agent. It can resolve the agent's DID, inspect an Agent Passport, and verify signatures on mediated-decision receipts. The counterparty must still decide which issuers, receipts, policies, and assumptions it accepts.

See Compliance as Code for information on boundary controls and compliance mappings, and The Cognition Market for the proposed market model.

Summary

1. Portable records. Identity, capability tokens, and reputation credentials can be presented across operators when their policies support them.
2. Identity derives from a key. A did:chio:<64-hex> DID derived from an Ed25519 key resolves without network calls.
3. Authority uses capability tokens. A capability and its delegation chain, verified from the token itself, run identically across a desktop sidecar, wasm, and UniFFI.
4. Reputation uses a credential. The Agent Passport projects into standard verifiable-credential formats and supports cross-issuer migration where implemented.
5. Mediated calls are governed. A capability and a guard must both clear a call routed through the kernel.

Next Steps

• Compliance as Code · how governed-call controls map to compliance requirements
• Autonomous Commerce · how portable identity and authority participate in a mandate and settlement flow
• The Cognition Market · the proposed market model for agent work
• The Mediated Call · the boundary mechanics: how a capability and a guard both have to clear a single call
• Capabilities · the portable authority object: delegation chains, scope, and the subset check
• Reputation & Passports · the credential shape behind the Agent Passport and how it survives a change of issuer
• Workload Identity · the complementary layer that binds the process a capability runs in, not the agent that holds it