Overview

behalf is an append-only, tamper-evident action-receipt log for AI agent systems. Every time an agent’s action crosses a trust boundary — a tool call through the MCP proxy, a resource read, a delegation to a sub-agent, a human approval or denial — the capture surface writes one signed receipt. Receipts are immutable, hash-chained, and verifiable offline by a third party who has never spoken to behalf.

Receipts carry digests, references, and signed metadata. Payload content — the actual request and response bodies — stays in the customer’s own storage, referenced by digest. behalf holds the index, digests, sizes, content types, and custody state; never content.

The two governing invariants

1. Stored bytes are the signed bytes are the hashed bytes. There is no canonicalization step. Receipts are wrapped in a DSSE envelope with pre-authentication encoding (PAE), so serialization is never re-derived and there is no canonicalization function that a writer and a verifier, possibly years apart and in different languages, must agree on byte-for-byte. Schema evolution lives entirely on the read path; a schema version bump never rewrites or re-chains an existing record.

2. Verification needs no network. The verifier checks an export file offline: signatures against embedded public keys, leaf hashes, and the chain, with no call to behalf, the identity provider, or anything else.

The specification set

• Receipt schema v1 — the receipt payload: record kinds, envelope fields, identity, the delegation chain, attribution, payload custody, and which fields are frozen and why.
• Export format v1 — the interchange file that behalf verify checks: file layout, the byte-span rule, the chain rule, the verifier’s check order, tamper classes, and exit codes.
• Threat model — who the adversaries are, what verification proves at each state, and what behalf explicitly does not claim.

A machine-readable JSON Schema for the receipt payload is published at /schemas/receipt-v1.schema.json.

Versioning and status

Receipt schema v1 is frozen. The fields it defines are the ones that must exist in the first receipt ever written, because receipts are immutable and hash-chained and nothing can be re-cut onto historical records. The schema can grow forward; it cannot be retrofitted backward.

Export format v1 is the current interchange format. It will gain checkpoint and inclusion-proof material from the transparency log under a new format string; files in the v1 format remain readable. Key provenance via a published key log is a later milestone; today, verification checks signatures against the keys embedded in the export, and the verifier’s output does not claim more than that.