Start here
Agents now act on our behalf. The web can't yet verify them.
Software agents are starting to hold credentials, move money, and call other agents on their own, reasoning in natural language as they go. The web's identity tools were built for people and for servers, not for software that can be persuaded. There is no shared way to ask an agent “who are you, and should I trust you with this?” and get an answer you can verify.
OpenA2A is an open family of specifications that closes that gap. It gives every agent a verifiable identity, a portable proof of trustworthiness, and a way to use credentials it can never actually see, re-using the cryptography that already secures the web. It is developed in the open and filed with the standards bodies that govern the web, so the trust layer for agents belongs to no single vendor. If you read only this page, this is the idea.
The mental model
Think of an agent the way your browser thinks of a website. Before it trusts a site, it checks a certificate, signed by an authority, logged in public. OpenA2A is that same chain of reasoning, rebuilt for agents that act on your behalf, not for pages you read.Why the web's existing tools aren't enough
Passwords identify people. TLS certificates identify servers. Neither was designed for software that reasons in natural language and can be talked into things. An agent can be persuaded to misuse access it legitimately holds, to leak a secret sitting in its context, or to impersonate another agent it is talking to. Closing that gap takes three properties familiar crypto does not provide on its own:
- Identity that can be challenged, prove you hold the key, don't just claim a name.
- Trust that travels, a signed credential a verifier checks locally against cached keys, in milliseconds, with no authority on the request path.
- Authorization that withholds the secret, the agent gets the result of an action, never the credential behind it.
An open standard, not a product
OpenA2A is a specification, not a vendor platform. The pieces are being standardized where the web is already standardized: did:opena2a is filed with the W3C as a DID method, and the agent-identity attributes are proposed to OpenTelemetry's semantic conventions so any tracing stack can read them. Anyone can implement the specs; AIM is one open-source reference implementation, included so you can see the standard run, not because the standard requires it. The aim is a shared, auditable trust layer for agents, the way TLS and OAuth became shared layers nobody owns.
The specifications, in plain language
What is this agent called, and how do I look it up? A W3C DID method where did:opena2a:<type>:<id> resolves over HTTPS to a DID Document, so any verifier can fetch an agent's public key and trust endpoints.
Which agent is this, what can it do, and should I trust it? An open standard for creating cryptographic agent identities, declaring capabilities, proving key possession via challenge-response, and computing a 9-factor trust score.
Can I verify this agent's trust offline, with cached keys, in milliseconds? A signed, self-contained, 7-day credential, the TLS certificate for agents, encoding identity, scan results, capabilities and behavior, verified locally against cached keys and a cached revocation list, with no authority on the request path.
How are trust statements issued, logged, audited and revoked? The protocol that issues, verifies, distributes and revokes trust assertions. Issuance and revocation events are appended to an RFC 6962 Merkle log; the Registry publishes signed tree heads and inclusion and consistency proofs that anyone can fetch and check; no monitor outside OpenA2A runs today.
How does an agent use a credential it must never see? An authorization layer where an agent emits an abstract grant:// reference and a local broker resolves scoped access, so no secret, token, or backend name ever enters the model's context.
Where do all these specs actually run? The reference platform that mints provider scoped identities, requests ATX credentials from the OpenA2A Registry and verifies them, runs five step authorization and keeps its own audit log: the reference implementation of AIP. ATX issuance, the ATP trust authority and did:opena2a resolution run in the OpenA2A Registry; the AAP broker is a library in Secretless.
How can an agent be attacked, and is each threat real? A MITRE ATT&CK-style catalog of 61 techniques across 9 attacker tactics, each tagged by real-world evidence and mapped to detection checks, lab scenarios and controls.
How do tools detect injections and exposed AI infrastructure? An open, YARA-style detection-signature format for AI prompt injections and exposed agent infrastructure, shareable rules any scanner can run.
What behavior must an agent promise, and can we audit it? Defines what goes in an agent's SOUL.md governance file: 9 behavioral domains, 72 controls and 3 conformance levels. Also known as OASB-2 (behavioral domains 11-19).
What AI-safety posture does this domain declare to agents? A domain AI-safety declaration published at /.well-known/ai-safety.txt, where a site states its AI-safety posture to consuming agents in a robots.txt-style file.
Does a security tool actually catch agent attacks? 222 scenarios across 10 categories that measure a security tool's detection coverage against agent threats, ATT&CK-Evaluations style, most of them mapped to MITRE ATLAS.
How do you observe an agent's authorization decisions? Nine proposed OpenTelemetry attributes under gen_ai.agent.* that put agent identity and trust signals into standard traces, metrics and logs; the repository also defines fga.* attributes for authorization outcomes.
How they fit together, end to end
Here is the whole lifecycle of an agent that wants to read a database, told as one story. Each step belongs to one spec.
- 1did:opena2aThe agent gets a nameIdentity
It is registered and assigned a DID like did:opena2a:agent:acme/billing, an identifier that resolves to a public key and trust endpoints; today the reference resolver returns the registry's signing key for every DID, not the agent's own key.
- 2AIPIt proves the name is its ownIdentity
A verifier sends a random challenge; the agent signs it with its private key. Claiming a name and proving it are now different things.
- 3ATXIt receives a credentialTrust
At build time it is scanned and issued a signed, 7-day ATX credential that bundles its identity, scan results, capabilities and behavior.
- 4ATPThe credential is loggedTrust
Issuance and revocation events are appended to an RFC 6962 Merkle log; the Registry publishes signed tree heads and inclusion and consistency proofs that anyone can fetch and check; no monitor outside OpenA2A runs today.
- 5ATXAnyone verifies it offline, with cached keysTrust
A relying party checks the signature and expiry locally in under 5ms, against cached keys and a cached revocation list, with no authority on the request path.
- 6AAPIt’s granted scoped accessAuthorization
To read the database it emits grant://orders-db. A local broker verifies the ATX and resolves a scoped credential, which never enters the agent’s context.
- 7AIMA reference implementation runs itReference
AIM is one open-source platform that mints the identity, obtains the ATX from the OpenA2A Registry and verifies it, enforces the 5-step authorization, and keeps its own audit log. Any conformant implementation works the same way.
See that it's real
You do not have to take the cryptography on faith. The interactive lab runs the real verification in your browser, with no server on the line, so you can watch it accept the genuine credential and reject every forgery. In the Adversary Console you take the attacker's seat: tamper a field, mint your own key and re-sign the credential, paste a forged signature, even try the post-quantum signature. Every attack fails, and the panel names the exact check that caught it. A cryptographically valid signature over the wrong key is still rejected, because trust is bound to identity, not to math. That property is the whole point of the standard, and you can prove it to yourself in a minute.
Suggested reading order
Follow the layers bottom-up: did:opena2a → AIP → ATX → ATP → AAP, then AIM to see it implemented. Prefer analogies? Jump to Mapped to PKI & the web.