OpenA2A/specs
OpenA2A trust authorityproof no. 001 · MMXXVI

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.

did:opena2a nameAIP proofATX credentialATP logAAP grant
vendor-neutral · Apache-2.0 implementationsdid · aip · atx · atp · aap
The problem in one line

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.

expires on purpose · ATXauditable log · ATPno leakable secret · AAP
T-2002

Indirect prompt injection: malicious instructions embedded in external data an agent consumes through retrieval or tool responses.

  • tactic · initial access
  • evidence tier · observed, confirmed in real-world production systems

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.

Where this bites

7 places agents are already acting

all 7 use cases →

Each is real industry motion, not OpenA2A adoption: evidence that the problem is here and the trust layer is missing.

§01 · See it decide

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.

Fig. 06 · run a request through the stack
agentcaller
DID
AIP
ATX
ATP
AAP
secretsealed
·Evaluating did:opena2a…

Flip a condition

did:opena2aDoes the identity resolve?
AIPDoes it hold the key?
ATXIs the credential valid?
ATPHas it been revoked?
AAPIs the action in scope?

Every check defaults to valid. Set one to its failure state to see which spec catches it.

§02 · The core stack

Each layer stands on the one below it

Identity is the foundation. Trust is built on proven identity. Authorization is built on verifiable trust. OpenA2A AIM implements identity, credential issuance and runtime authorization; the ATP trust authority runs in the OpenA2A Registry, and the AAP broker is a library in Secretless.

Each layer assumes the one beneath it · authorization needs verifiable trust · trust needs proven identity
§03 · The specifications

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.

Tier 1

In external standards processes

2 specs

Filed 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.

did:opena2a0.3 (draft)W3C
Decentralized Identifier Method

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.

Filed: W3C DID method registrymerged 2026-07-04
OTelDraft / proposalOpenTelemetry
OTel Semantic Conventions for Agent Identity

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.

Filed: OpenTelemetry semantic conventionspull request #291 open, not merged (issue #180)
Tier 2

Proposed for adoption

9 specs

Complete specification, all but ai-safety.txt with a working reference implementation, open to external co-authors.

A published spec document and, for every spec here except ai-safety.txt, a runnable reference implementation. These are OpenA2A-authored and openly seeking co-authors, not yet adopted by an external body.

AIP1.2.0-draftOpenA2A
OpenA2A Agent Identity Protocol

An open standard for creating cryptographic agent identities, declaring capabilities, proving key possession via challenge-response, and computing a 9-factor trust score.

Filed: IETFindividual Internet-Draftdraft-fane-opena2a-aip-04
ATX1.2.0-draftOpenA2A
Agent Trust eXtension

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.

Status: Working text; the last final version, 1.1.0-final, is tagged v1.1.0; ATX 1.1 is the normative wire format (core.md §1.3a)
ATP1.1.0-draftOpenA2A
Agent Trust Protocol

The protocol that issues, verifies, distributes and revokes trust assertions, recording every one in an RFC 6962 Merkle transparency log that anyone can audit.

Status: Draft, dated September 2026
AAP0.5.1-draftOpenA2A
Agent Authorization Protocol

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.

Filed: IETFindividual Internet-Draftdraft-fane-opena2a-aap-02
ATM1.2OpenA2A
AI Agent Threat Matrix

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.

Status: Published (September 2026)
AIIS0.4.0OpenA2A
AI Injection & Infrastructure Signatures

An open, YARA-style detection-signature format for AI prompt injections and exposed agent infrastructure, shareable rules any scanner can run.

Status: Active; corpus v0.4.0 with schema 0.2 (2026-09-08)
ABGS1.0.0-draftOpenA2A
Agent Behavioral Governance Specification

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).

Status: Draft

Also OASB-2: the behavioral governance companion to the OASB benchmark.

ai-safety.txtdraft-01OpenA2A
Domain AI-safety declaration

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.

Filed: IETFindividual Internet-Draftdraft-fane-ai-safety-txt-01
OASB0.4.0OpenA2A
Open Agent Security Benchmark

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.

Status: Stable

Security benchmark; its governance companion is OASB-2 (ABGS).

Tier 3

Reference implementation

1 spec

Reference implementation, not a specification: the platform that mints identities, issues credentials and runs authorization.

Runnable software, not a standard.

AIMAgent Identity Management

The reference platform that mints identities, issues credentials, runs 5-step authorization and keeps its own audit log: the working implementation of AIP and ATX issuance. The ATP trust authority and did:opena2a resolution run in the OpenA2A Registry; the AAP broker is a library in Secretless.

Repo ↗
§04 · Get involved

These specs are early, and open to co-authors

Every specification here is authored in the open, and all but ai-safety.txt and the OTel semantic conventions are 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.

Track 1
Co-author a specification
Review, build a second implementation, or audit a proposed spec.
Track 2
Adopt or integrate
Run OASB against your detector, or deploy AIM and report gaps.
Track 3
Contribute threat research
Submit validated techniques, signatures, or a disclosure.
§05 · Nothing here is new, only new for agents

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.

The web you already trust
OpenA2A for agents
Certificate AuthorityDigiCert, Let’s Encrypt
→
Trust authorityATPissues credentials
TLS / X.509 certificateproves a server
→
ATX credentialATXproves an agent
Certificate Transparency logRFC 6962
→
Transparency logATPsame Merkle tree
OAuth token exchangescoped access
→
grant:// + brokerAAPsecret never seen
Same guarantees, same math, re-pointed from domains to agents.