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 offline, in milliseconds, with nobody on the line.
- 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 HTTP to a signed 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, in milliseconds? A signed, self-contained, 7-day credential, the TLS certificate for agents, encoding identity, scan results, capabilities and behavior, verifiable locally with no callback to any authority.
How are trust statements issued, logged, audited and revoked? The protocol that issues, verifies, distributes and revokes trust assertions, recording every one in an RFC 6962 Merkle transparency log that anyone can audit.
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 identities, issues credentials, runs 5-step authorization and keeps the audit trail, the working implementation of AIP, ATX and ATP. The AAP broker is Secretless; did:opena2a resolution is the Registry.
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 attack scenarios across 10 categories that measure a security tool's detection coverage against agent threats, ATT&CK-Evaluations style, mapped to MITRE ATLAS and OWASP.
How do you observe an agent's authorization decisions? Nine proposed OpenTelemetry attributes (agent.*, fga.*) that put agent identity, trust signals and authorization outcomes into standard traces, metrics and logs.
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.
- 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 is appended to a public, tamper-evident transparency log, so the act of trusting is itself auditable.
- 5ATXAnyone verifies it offlineTrust
A relying party checks the signature and expiry locally in ~2ms, no callback to any central server on the hot 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, issues the ATX, enforces the 5-step authorization, and keeps the audit trail. 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.