Standards position · v0.1
Agent Accountability Evidence Layer for Autonomous AI Systems
A minimum profile for signed agent identity, public standing, append-only events, and evidence exports.
Summary
Autonomous agents need a common evidence layer. A buyer, gateway, auditor, or regulator should be able to ask what the agent is, who is responsible for it, what it may do, whether it is still in good standing, which key identifies it, and where its evidence can be checked.
Agent Seal is one running implementation. The point is not that every system must use Agent Seal. The point is that accountable agents should expose equivalent evidence.
Minimum claims
| Claim | Purpose |
|---|---|
| Agent id | Stable identifier for the agent. |
| Public key | Key used to verify agent-signed events or claims. |
| Keeper | Human or organisation responsible for the agent. |
| Scope | Capabilities the agent may use and actions it may not take. |
| Status | Registered, suspended, revoked, or equivalent standing. |
| Signed card | Portable machine-readable identity document. |
| Event history | Append-only updates for name, version, scope, metadata, and revocation. |
| Evidence export | Trace, status, and proof links for audit or review. |
| Redaction policy | Clear public/private evidence boundary. |
| Incident pointer | Procedure URL or reference for serious incidents and complaints. |
Minimum endpoints
HTTP is not the only possible transport, but it is easy to inspect. A useful profile should expose the same claims through predictable routes or equivalent messages.
| Endpoint | Role |
|---|---|
/.well-known/agent-card.json | Registry or service card. |
/.well-known/jwks.json | Public keys for card verification. |
/v1/agents/{id_or_did}/card | Registry-issued card for one agent. |
/v1/public/agents/{id}/status | Public standing and core identity facts. |
/v1/agents/{id}/events | Append-only event history. |
/v1/agents/{id}/state | Current state derived from events. |
/v1/public/agents/{id}/court-export | Public evidence export. |
/v1/public/evidence-redaction-policy | Public/private evidence boundary. |
Signature and event model
The basic model is direct. The agent has a public key. The keeper or registry signs the public card. The agent or keeper signs append-only events. The verifier checks the card against published keys and makes sure the card subject matches the expected agent id.
Registration should be hard to rewrite. Later changes should be events: name updates, version updates, capability updates, compliance metadata, anchor transfer, revocation, and intent-chain records.
Evidence and redaction
The public record should usually contain hashes, roots, counts, statuses, public keys, keeper names, procedure links, and public governance references. It should not publish private incident reports, complaint bodies, customer messages, applicant files, raw proof arrays, or raw timestamp receipt bytes.
What standards groups should consider
- Treat autonomous agents as a distinct evidence problem.
- Require portable signed identity for sensitive workflows.
- Include a controller or keeper claim.
- Include machine-readable scope and denied scope.
- Require public standing and revocation checks.
- Prefer append-only signed event history over operator edits.
- Make redaction policy part of the evidence profile.
- Allow incident and complaint pointers without publishing private reports.
- Keep the profile vendor-neutral.
- Test the profile with running code.
Closing
The question is not whether every agent needs a ceremony. The question is whether serious agents need a record. They do. An accountable agent evidence layer should show the agent, the keeper, the scope, the status, the evidence, and what is deliberately not public.