Why it exists
did:opena2a gives an agent a name. AIP makes that name meansomething. It is the open standard for creating an agent's cryptographic identity, declaring what it can do, provingit holds the key behind its name, and distilling all of that into a single trust score. In the spec's words, it answers “which agent is this, what can it do, and should I trust it?”
A naming note from the spec itself
Several unrelated Internet-Drafts also abbreviate to “AIP.” When referenced elsewhere, the spec asks you to use the fully-qualified name OpenA2A AIP.The identity, built from a keypair
An identity begins with an Ed25519 keypair. The agent id is derived from the public key, so it cannot be chosen or spoofed independently of the key. The private key is encrypted at rest; only the public key is ever shared with an identity provider.
{
"id": "aim_7f3a9c2e", // "aim_" + first 8 hex of SHA-256(pubkey)
"name": "my-agent",
"type": "claude", // informational only, never a security signal
"publicKey": "ed25519:x8Kp2mN...4RqW",
"encryptedPrivateKey": "aes-256-gcm:...",
"capabilities": ["file:read", "api:call"],
"status": "verified"
}Capabilities: what it's allowed to attempt
Capabilities are declared in a simple namespace:action form. The namespace carries an inherent risk level, so a verifier can reason about system:* differently from file:read.
A capability violation is logged and costs the agent trust, scaled by severity (from −2% for a low-risk slip to −20% for a critical one), trust is continuously earned and lost, not granted once.
Proving identity: challenge-response
This is the heart of AIP and the reason identity here is not just a claim. A relying party issues a random, single-use nonce (valid five minutes); the agent signs it; the relying party verifies the signature against the registered key. Watch it run:
Verifier asks , “Prove you’re acme/billing. Sign this nonce: 9f3a…”
It is the TLS handshake, applied to agents: possession of the private key, not a self-asserted name, is what is checked.
The 9-factor trust score
AIP composes a single 0.0-1.0 score from nine weighted signals. Each factor also carries a confidence (how much data backs it); factors with no data are excluded and their weight redistributed, so the score is honest about what it actually knows.
A score, not a verdict
The trust score is a continuous, explainable signal, every component is visible. A relying party sets its own threshold per action: reading public data might need 0.4; processing a payment, 0.8.Three conformance levels
AIP scales from a single developer to a whole ecosystem. The levels describe deployment topology, layering capability on capability.
- Level 1, Local
- Keypair, local identity file, local capability declaration and audit log. No server. For an individual developer.
- Level 2, Managed
- Adds an identity provider: challenge-response verification, trust scoring, server-side audit, drift detection. For organizations.
- Level 3, Federated
- Adds DID-based identifiers, verifiable-credential trust assertions, cross-platform capability negotiation, and ATP integration. For ecosystem-wide trust.
Cryptography
- Ed25519 (RFC 8032) for all signatures and challenge-response.
- ML-DSA-65 (FIPS 204) recommended for Level 3, a hybrid signature so quantum-aware verifiers check both, classical ones check Ed25519.
- Private keys encrypted at rest (AES-256-GCM, system keychain, or HSM); never transmitted. Nonces single-use, five-minute lifetime.
Where it sits
AIP is the identity and behavior layer. Its trust score and verified identity become inputs to ATX (the credential that carries them) and ATP(the protocol that logs and federates them). The reference implementation of AIP's trust calculator lives in AIM.