A proposed technical framework for establishing who is accountable for an autonomous software agent, how strongly that accountability is evidenced, and what a website can verify about an agent that contacts it.
Trust model
An Operator — a legal entity — runs an Agent that holds its own key. The Registry records the agent and issues it credentials. A Relying Party — a website or API — verifies them. When the agent acts for someone, a Principal grants that authority.
The relationship everything rests on is Operator → Registry: the agent is a credential holder, the registry a record-keeper, and a relying party's recourse runs to the operator — which is why sanctions attach to the operator, not only to one identifier.
Scope
A framework that overclaims is worse than none, because it induces reliance it cannot support. AIAF states the boundary precisely, and requires implementations not to present the “no” rows as verified.
| Claim | Provable | Mechanism |
|---|---|---|
| This request came from the holder of key K | Yes | RFC 9421 signature over bound components |
| Key K is bound to identifier A | Yes | Registry-signed credential, cnf (RFC 7800) |
| The operator is a real legal entity | Yes, at OAL ≥ 2 | Business-registry evidence, human review |
| Key K is in certified hardware | Yes, at KAL ≥ 2 | Remote attestation to a pinned root |
| A may act for principal P | Yes, at DAL ≥ 2 | Signed, scoped delegation grant |
| Identifier A is valid right now | Within the revocation window | Signed revocation feed and short credential lifetime |
| A is running model M | No | Self-asserted; unverifiable over the wire |
| A will behave as declared | No | A declaration is a commitment, not a control |
| A has not been prompt-injected | No | A compromised agent still holds valid credentials |
| Unregistered traffic is malicious | No | No credential means unidentified, nothing more |
Assurance
A hobbyist with a hardware key has excellent key protection and no recourse; a bank with a key in a plain container has recourse and a stealable key. A single scale puts both in the same bucket. AIAF grades each axis separately.
OAL
Who is accountable, and how well evidenced?
KAL
How well is the agent's key protected and bound?
DAL
By what authority does it act for someone else?
A floor on the weaker of the two accountability axes: an agent cannot buy its way up with hardware alone, nor with paperwork alone. Delegation is kept separate, so a high AgAL never implies authority the agent was not given.
AgAL = min(OAL, KAL) for OAL ≥ 1 and KAL ≥ 1
| Scenario | OAL | KAL | DAL | AgAL |
|---|---|---|---|---|
| Hobbyist crawler, verified domain | 1 | 1 | 0 | 1 |
| Crawler at a verified company | 2 | 2 | 0 | 2 |
| Support agent for a signed-in customer | 2 | 2 | 2 | 2 |
| Payment agent initiating a transfer | 3 | 3 | 3 | 3 |
| Verified bank, key in a plain container | 2 | 1 | 0 | 1 |
How it works
1 · Register
The operator generates the key pair and submits only the public key. A registry must reject any private key material.
2 · Prove possession
The agent signs a single-use, domain-separated challenge. Until it does, it gets no credential and verifies nowhere.
3 · Present
Each request carries a credential of at most 15 minutes and an RFC 9421 signature over method, authority and path.
4 · Verify offline
The relying party checks both against cached registry keys and a signed revocation feed — no call to the registry per request.
GET /api/products HTTP/1.1
Host: shop.example
Signature-Input: sig1=("@method" "@authority" "@path");
created=1790243730;keyid="aid:v1:acme-corp:01J8Z…";
alg="ed25519";nonce="k9Xr…";tag="aiaf"
Signature: sig1=:MEUCIQD…:
Agent-Credential: eyJhbGciOiJFZERTQSIsInR5cCI6…{
// verified by the registry
"sub": "aid:v1:acme-corp:01J8Z…",
"org_domains": ["acme.example"],
"oal": 2, "kal": 2, "agal": 2,
"cnf": { "jwk": { … } }, "exp": iat + 900,
// self-asserted by the operator: never verified
"declared": { "model_family": "…", "purposes": ["…"] }
}Verified claims sit at the top level; anything the operator merely asserts is nested under
declared, so a relying party can never mistake one for the other. Trust decisions key on the
(registry, verified domain) pair — never on a namespace string alone.
For relying parties
Our verifier SDKs for Node.js, Python and Go implement these checks, and are held to the same results by shared cross-language test vectors.
Get the verifier SDKskeyid equal to the credential's subject.declared values as verified, or derive delegation authority from AgAL.For enterprise architects
Policy document · Markdown
The full framework: trust model, assurance levels, lifecycle, wire format, accountability and due process, conformance requirements, privacy and security considerations, and governance.
66 KB · SHA-256 78dcfea0ef7d458fa2e07b84032cece7fe4df226bd73dcd9bca0465594dbe772
Download the draftOpen Policy Agent · Rego
The OPA policy the AIDR registry runs for every operator action: roles and capabilities, the actions that need a hardware authenticator, dual control, and read-only limits — a working reference for how a conforming registry enforces separation of duties.
8 KB · SHA-256 5b7a06a0b87f0fa1777f66f5c848de901f02e99d1c52e81936923427fdfbabca
Download the OPA rules