OpenA2A/specs
OpenA2A trust authorityproof no. 001 · MMXXVI

Identity.
Trust.
Authorization.

open specifications for AI agents

The security the web already runs on, certificates, transparency logs, and scoped grants, re-engraved for autonomous agents.

did:opena2a nameAIP proofATX credentialATP logAAP grant
vendor-neutral · Apache-2.0 implementationsdid · aip · atx · atp · aap
§01 · Why these specs exist

An agent is not a user, and not a server.

Humans log in with passwords and MFA. Servers prove themselves with TLS certificates. But an AI agent is a moving target: the same agent, with the same permissions, behaves differently depending on its prompt, its memory, and what it just read on a web page.

That breaks the assumptions behind OAuth, SAML and API keys. An agent can be talked into misusing a credential it legitimately holds. It can leak a secret simply by being asked nicely. And it can claim to be anyone.

OpenA2A treats agents as first-class cryptographic principals, with verifiable names, portable trust, and authorization that never puts a secret where a hijacked model could read it.

Identity
Who is this agent?
A cryptographic identity, not a self-declared name.
Identity
Is it really them?
Prove possession of the private key with a challenge.
Trust
Should I trust it?
A signed, portable, offline-verifiable credential.
Trust
Can I audit that?
Every trust decision in a tamper-evident public log.
Authorization
What may it touch?
Scoped access via a broker, the secret never reaches it.
Implementation
Where does it run?
AIM, the reference platform that issues & enforces it all.
§02 · 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.

§03 · 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. AIM implements all three.

L3Authorization

How is trust turned into scoped access, safely?

L2Trust

How much should I trust it, and can I prove it offline?

L1Identity

Who is this agent, and is it really them?

Implementation
AIM

Issues and enforces every layer above. The reference platform.

Explore →
Each layer assumes the one beneath it · authorization needs verifiable trust · trust needs proven identity
§04 · 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.1.0-draftW3C
Decentralized Identifier Method

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.

Filed: W3C DID method registryprovisional, under review
OTelDraft / proposalOpenTelemetry
OTel Semantic Conventions for Agent Identity

Nine proposed OpenTelemetry attributes (agent.*, fga.*) that put agent identity, trust signals and authorization outcomes into standard traces, metrics and logs.

Filed: OpenTelemetry semantic conventionsproposed, under discussion
Tier 2

Proposed for adoption

8 specs

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

AIP1.0.0-draftOpenA2A
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.

Status: Draft
ATX1.0.0OpenA2A
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: Published; v1.1 issued in production
ATP1.0.0-rc1OpenA2A
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: Release candidate
AAP0.2.0-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.

Status: Draft (intended IETF Internet-Draft)
ATM1.1.0OpenA2A
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 (June 2026)
AIIS0.2.1OpenA2A
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
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.

OASB0.3.2OpenA2A
Open Agent Security Benchmark

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.

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 issues and enforces the specs above.

Runnable software, not a standard.

AIMAgent Identity Management

The reference platform that mints identities, issues credentials, runs 5-step authorization and keeps the audit trail, the working implementation of AIP, ATX, ATP, AAP and did:opena2a.

Repo ↗
§05 · Get involved

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.

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.
§06 · 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.