Receipt identity
Last updated: 5 July 2026
Agent identity is a per-action question
When an AI agent acts in a regulated workflow, the question that matters afterwards is an identity question: which agent acted, on whose behalf, under what constraints, and can someone who was not in the room prove it. A login session cannot answer that; it identifies a connection, not an act.
ATTESTATION-v1 answers it per action. Every receipt is a signed, self-contained identity statement for one act: the twelve fields below name the principal, the agent surface, the constraints applied, and carry the cryptographic proof, verifiable offline against a published key, with no call back to Aqta.
The twelve fields, read as identity primitives
| Field | Identity role | What it establishes |
|---|---|---|
| org_id | Principal | The organisation on whose behalf the agent acted. Every receipt is tenant-scoped; no action is anonymous. |
| model | Agent surface | Which model or agent runtime produced the decision (for action receipts, a namespaced agent such as spectra/gemini-live). |
| policy_applied | Authority and constraints | The named policies enforced before the action executed. The receipt does not just say who acted; it says what rules bound the act. |
| outcome | Decision | What the enforcement point decided (passed). Denied calls are separately audit-logged. |
| attestation_id | Act identity | A unique identifier for this single act. One act, one receipt. |
| trace_id | Session identity | Groups the acts of one session or workflow, so a chain of agent actions reads as one accountable episode. |
| request_hash | What was asked, content-free | SHA-256 over the canonicalised request. Binds the receipt to the exact input without storing or revealing it. |
| timestamp | When | Signing time. Receipts are issued at runtime, before the action returns, not reconstructed later. |
| cost_prevented_eur | Impact accounting | Spend the policy layer prevented, where applicable. Conformance field; zero on most receipts. |
| v | Contract | The specification version (ATTESTATION-v1), so any conforming verifier knows exactly what it is checking. |
| public_key | Issuer identity | The Ed25519 public key of the signer, embedded in the receipt itself, so verification needs no directory lookup. |
| signature | Proof | Ed25519 signature over the canonical receipt. Change one character anywhere and verification fails, for anyone, offline. |
Verifying an identity claim
Any receipts panel, auditor, or peer agent can check a receipt two ways. Neither requires an API key, and the first requires no network at all.
- Offline: run the published verifier (aqta-verify-receipt on PyPI and npm) against the receipt. The public key travels inside the receipt; the check is pure local computation.
- By id: GET /api/v1/actions/verify/{id} on the gateway returns the verification result with action-shaped fields (agent, action type, outcome), public, no authentication, so a viewer can show "verified" without holding credentials.
The spec, conformance vectors, and both verifier implementations are open: ATTESTATION-v1 on GitHub.
What a receipt does not claim
A receipt proves the record was signed by the holder of the signing key, for the named organisation, under the named policies, and that nothing was altered since. It does not, by itself, bind that organisation or agent to a legal identity; binding keys to legal entities (enterprise PKI, eIDAS) is a deployment decision made with the customer. We state this plainly because an identity primitive that overclaims is worse than none.