Identity.
Trust.
Authorization.
continuous trust for AI agents
Knowing who an agent is is not enough. Agents are persuadable, so trust here is re-checked, not granted once. The web already solved this with PKI; we re-point it at agents.
The agent you authorized five minutes ago may not be the one acting now.
We have gotten good at answering who an agent is. The harder question is whether the agent you authorized five minutes ago is still safe for the action it is about to take. AI agents are persuadable: the same agent you verified a minute ago could read an indirect prompt injection on a website and become compromised. A one-time identity check is a snapshot of something that changes by the minute. Identity is necessary, but it is not enough.
Continuous trust needs a credential that expires on purpose, an auditable trust log, and authorization that never hands the agent a secret it could be convinced into leaking. The web already solved the equivalent problem with PKI, and we are re-pointing that model at agents.
of indirect prompt injections against security-tooling agents that ingested external content reached a payload callback in our honeypots.
- 1,207 of 1,317 attempts · 30-day window, May to June 2026
- all-sector baseline 1.30%
First-party honeypot research, not a third-party claim.
Read the specs, and tell us where they are wrong
These are early and openly seeking co-authors. The fastest way in is to read one and push back on it, or to take the attacker's seat and try to break the verification yourself.
Ready to go further? Co-author a spec with us.
7 places agents are already acting
Each is real industry motion, not OpenA2A adoption: evidence that the problem is here and the trust layer is missing.
Break it, and watch which spec catches it
One request runs through all five gates. Every check starts valid. Flip any one to its failure state and the request is denied at the exact gate that owns that check, with the reason it exists.
Flip a condition
Every check defaults to valid. Set one to its failure state to see which spec catches it.
Each layer stands on the one below it
Identity is the foundation. Trust is built on proven identity. Authorization is built on verifiable trust. AIM implements all three.
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 →Grouped by how far along they are
A spec we wrote is not the same as a standard the ecosystem has adopted. These are grouped by that distinction: what is in an external standards process, what is published and openly seeking co-authors, and the software that implements it all.
In external standards processes
2 specsFiled with, or under review by, an external standards body.
To belong here a spec needs a confirmable, linkable filing in an external standards organization. No filing, no placement.
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.
Nine proposed OpenTelemetry attributes (agent.*, fga.*) that put agent identity, trust signals and authorization outcomes into standard traces, metrics and logs.
Proposed for adoption
9 specsComplete specification and a working reference implementation, open to external co-authors.
A published spec document and a runnable reference implementation. These are OpenA2A-authored and openly seeking co-authors, not yet adopted by an external body.
An open standard for creating cryptographic agent identities, declaring capabilities, proving key possession via challenge-response, and computing a 9-factor trust score.
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.
The protocol that issues, verifies, distributes and revokes trust assertions, recording every one in an RFC 6962 Merkle transparency log that anyone can audit.
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.
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.
An open, YARA-style detection-signature format for AI prompt injections and exposed agent infrastructure, shareable rules any scanner can run.
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).
Also OASB-2: the behavioral governance companion to the OASB benchmark.
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.
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.
Security benchmark; its governance companion is OASB-2 (ABGS).
Reference implementation
1 specReference implementation, not a specification: the platform that issues and enforces the specs above.
Runnable software, not a standard.
These specs are early, and open to co-authors
Every specification here is authored in the open and published with a working reference implementation. We are looking for co-authors, independent implementers, security reviewers, and threat researchers to help shape them before they go to external standards bodies.
You already trust this exact design
Every time your browser opens a padlock, it runs this playbook. OpenA2A re-uses it, almost one-to-one, for agents.