Architecture
The layered stack
The five specs are not a menu, they are a stack. Each layer is only meaningful because the layer beneath it holds. Read this page to understand why the order matters.
How is trust turned into scoped access, safely?
How much should I trust it, and can I prove it offline?
Who is this agent, and is it really them?
Issues and enforces every layer above. The reference platform.
Explore →Layer 1, Identity: who is this?
Everything starts with a name you can verify. did:opena2aprovides the name, a decentralized identifier that resolves, over HTTP, to a signed document containing the agent's public key. AIP provides the proof: a challenge-response handshake where the agent signs a random nonce, so that claiming an identity and holding it are different acts.
Why identity must come first
Trust placed in an unverified name is worthless. If an agent can simply assert “I am acme/billing,” every trust signal above it can be spoofed. The signature over a fresh challenge is what makes the whole tower stand up.Layer 2, Trust: how much, and provably?
Once an identity is proven, the question becomes how much to trust it. ATX is the answer in physical form: a signed, self-contained credential, the TLS certificate for agents, that packages identity, scan results, capabilities and a behavioral profile, and expires after seven days. Critically, it is verified locally: a relying party checks the signature in about two milliseconds, with no call to any central authority on the request path.
ATP is the protocol around that credential, how it is issued, distributed, revoked, and, above all, logged. Every issuance and revocation is appended to an RFC 6962 Merkle transparency log, the same structure that underpins Certificate Transparency. The act of trusting is itself made auditable.
Layer 3, Authorization: what may it touch?
Trust is not permission. A perfect, highly-trusted ATX says who an agent is and how it behaves, it is never, by itself, a key to your database. AAP is the layer that turns trust into scopedaccess, and it does so with one defining rule: the credential must never enter the agent's reasoning context. The agent emits an abstract grant:// reference; a local broker verifies the ATX, applies a default-deny policy, and runs the operation behind a trust boundary, returning only the result.
The trap this avoids
An agent that can read a secret can be talked into leaking it. By keeping the secret entirely behind the broker, even a fully hijacked agent can exfiltrate only a grant name and a result, nothing reusable.The spine, AIM: where it all runs
The four specs above are paper. AIM (Agent Identity Management) is the reference implementation: the platform that mints keypairs and DIDs (did:opena2a, AIP), issues credentials (ATX), records every action in an audit trail and trust history (ATP), and enforces a 5-step fine-grained authorization on every call (AAP). When a developer writes secure("my-agent"), AIM is what answers.
The dependency, stated plainly
- Authorization is only safe because trust is verifiable.
- Trust is only meaningful because identity is proven.
- Identity is only useful because it is cryptographic, not asserted.
Remove any layer and the ones above it collapse into security theater. That is the whole argument for treating these as a stack rather than a grab-bag of features.