Agent Work Attestation Protocol — v0.1

Status: Draft, 2026-04-27. Editor: Lex Oleksiienko (@AItoolerylab). License: Open spec (CC0 / public domain). Reference implementations MIT-licensed.

Abstract

This document specifies a portable, signature-based attestation format for autonomous AI agent work. The format enables any third party — payment gateway, regulatory auditor, insurance underwriter, downstream agent — to cryptographically verify that an agent completed a specified task without requiring access to confidential payload contents. The protocol is platform-neutral and supports chain-of-proof for multi-hop delegation.

The attestation is the on-the-wire artifact. A separate companion specification (Section 6) describes a public ledger format for storing and querying attestations to compute agent reputation.

1. Motivation

Autonomous AI agents now execute tasks with real-world consequences: they move money, write code that ships, respond to customers, file regulatory documents. Three classes of stakeholder need provable evidence of that work:

1. Downstream agents and orchestrators about to depend on the output need to verify it was produced by the claimed agent against the claimed specification.
2. Regulators require auditable records under EU AI Act Article 19 (effective 2026-08-02) and equivalent emerging US frameworks.
3. Insurance and bonding underwriters pricing AI liability policies need standardized telemetry, not vendor-specific log formats.

Today, every platform (OpenAI, Anthropic, Google, Stripe, Cloudflare) is shipping its own logging. Cross-vendor agents cannot transact without a neutral attestation layer. This specification fills that gap.

2. Conformance

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.

A producer is conformant if it emits attestations that validate against attestation-v0.1.schema.json.

A verifier is conformant if it rejects attestations that fail schema validation, signature verification, or canonicalization round-trip.

3. Attestation Object

Each attestation is a single JSON object conforming to attestation-v0.1.schema.json. The required top-level fields are:

4. Canonicalization

Before signing or hashing, attestations and hashed payloads MUST be canonicalized using JCS (JSON Canonicalization Scheme), RFC 8785. Specifically:

• Object keys sorted lexicographically.
• No insignificant whitespace.
• Numbers in canonical form (no trailing zeros, exponent normalization).
• UTF-8 encoded output.

The signature value covers the canonicalized form of the attestation excluding the signature.value field itself but including all other signature subfields.

5. Hashes

All hashes are SHA-256, hex-encoded, prefixed with sha256:. Future versions of this spec MAY register additional hash functions; verifiers MUST reject unknown prefixes.

sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

6. Identity and Key Resolution

The signature.key_id field MUST resolve to a public key. Conforming verifiers SHOULD support at least one of:

• DNS-anchored: key_id is a DNS name; verifier fetches https://{name}/.well-known/agent-keys.json and matches by fingerprint. Compatible with Identity Digital DNSid.
• DID: key_id is a DID URI (e.g. did:web:example.com); verifier resolves per W3C DID Core.
• HTTP: key_id is an https:// URL returning a JWK or PEM public key.
• Fingerprint: key_id is a sha256:... fingerprint; verifier looks up the key in a known directory (e.g. ledger registry).

The protocol does NOT mandate a single identity backend; verifiers MAY accept any combination they trust.

7. Chain of Proof for Multi-Hop Delegation

When Agent A delegates a sub-task to Agent B, Agent B's attestation SHOULD set task.delegation_parent to Agent A's attestation_id. Verifiers can walk the chain to reconstruct the full delegation tree.

This enables verifying composite tasks: "Agent A booked a flight, which required Agent B to negotiate with a vendor, which required Agent C to lookup historical pricing." Each link is independently verifiable; together they form an auditable chain.

A separate envelope attestation MAY be issued by the orchestrator to commit to the entire chain.

8. Confidentiality and Zero-Knowledge Mode

For tasks where the input or output cannot be revealed (medical records, financial trades, M&A diligence), producers MAY:

1. Set redaction_policy to zk-only on the relevant payload object.
2. Provide a zk_proof object with a system, circuit_id, and proof bytes.

The circuit MUST commit to (a) the spec hash from task.spec_hash, and (b) the same input/output hashes published in the attestation. Verifiers without access to the payload can still gain cryptographic certainty that work conforming to the published specification was performed.

This specification does NOT prescribe a specific ZK system. Implementations are RECOMMENDED to use Groth16 or PLONK for compactness, or STARK for post-quantum resistance.

9. Reputation Tags

The reputation_tags array carries self-reported claims about the agent's compliance posture (e.g. hipaa-eligible, eu-ai-act-article-19, soc2-tier-1). These are HINTS, not proof. Verifiers MUST NOT treat reputation tags as authoritative without an independent attestor's co_signatures entry confirming the claim.

A reputation registry (Section 11) aggregates verified tags across an agent's history.

10. Example Attestation

{
  "version": "0.1.0",
  "attestation_id": "att_x7QrJ8k2pL4mN9vBfH3wXa",
  "agent": {
    "id": "asst_kn4XJZ8K2pLm9N",
    "platform": "openai",
    "model": "gpt-5o-2026-04-15",
    "operator": "https://example-fintech.com"
  },
  "task": {
    "type": "fintech.kyc.verify-identity",
    "spec_hash": "sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
  },
  "input": {
    "hash": "sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824",
    "size_bytes": 2048,
    "redaction_policy": "full-redacted"
  },
  "output": {
    "hash": "sha256:486ea46224d1bb4fb680f34f7c9ad96a8f24ec88be73ea8e5a6c65260e9cb8a7",
    "verdict": "success",
    "redaction_policy": "fields-redacted"
  },
  "tool_calls": [
    {
      "tool": "stripe:identity.verify",
      "input_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "output_hash": "sha256:01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b",
      "timestamp": "2026-04-27T18:15:23.451Z",
      "duration_ms": 1240
    }
  ],
  "timestamps": {
    "task_started": "2026-04-27T18:15:22.000Z",
    "task_completed": "2026-04-27T18:15:24.812Z",
    "attestation_emitted": "2026-04-27T18:15:24.890Z"
  },
  "signature": {
    "alg": "ed25519",
    "key_id": "https://example-fintech.com/.well-known/agent-keys.json#ops-2026",
    "value": "MEUCIQDxyz...truncated..."
  },
  "reputation_tags": ["soc2-tier-2", "kyc-verified", "stripe-identity-eligible"]
}

11. Companion Ledger Specification (Section to be expanded in v0.2)

A reference public ledger MUST:

• Accept canonicalized attestations via REST API: POST /attest
• Validate schema, signature, and canonicalization round-trip before accepting.
• Append accepted attestations to a per-epoch Merkle tree; publish epoch root publicly.
• Expose query endpoints: GET /verify/:attestation_id, GET /agent/:agent_id/score.
• Compute per-agent reputation scores from accepted attestations weighted by:
  • Verdict outcomes
  • Tool call error rates
  • Co-signature presence
  • Audit claim verification
  • Time-decay weighting

The reference implementation lives in lib/.

12. Security Considerations

• Replay: Verifiers MUST treat duplicate attestation_id values as suspect.
• Spec confusion: The task.spec_hash ensures verifiers and producers agree on the task contract. Different specs SHOULD have different hashes; mutable specs without versioning are an anti-pattern.
• Compromised keys: Producers SHOULD publish revocation lists at the same key_id resolution endpoint. Future spec versions will define a standard revocation format.
• Self-reported verdicts: output.verdict is a producer claim. High-stakes verifiers SHOULD require co-signatures or independent verification before trusting success.

13. Privacy Considerations

The hashed-payload design ensures that publishing attestations to a public ledger does not expose payload contents. Hashes are one-way and salted by the canonical encoding of the surrounding context (timestamps, agent ID, signature). For very small input spaces (e.g. binary verdicts), implementations SHOULD use ZK proofs instead of plain hashes to prevent dictionary attacks.

14. IANA Considerations

This specification has not yet been submitted to IANA. Future versions intended for IETF standardization will request:

• A media type: application/agent-attestation+json
• A .well-known path: /.well-known/agent-keys.json (already informally adopted)

15. Open Questions for v0.2

• Standardized revocation list format and refresh cadence.
• Required vs OPTIONAL for co_signatures in regulated verticals.
• Cross-platform agent identity bridging (ANS, DNSid, DID).
• Batched attestation envelope for high-frequency low-value tasks.
• Attestation aggregation for streaming outputs (long-running agents).

Feedback welcome via GitHub Issues at the canonical repository.