Threat model

behalf’s v1 integrity claim is deliberately narrow and stated in full: tamper-evidence against after-the-fact modification, deletion, or reordering of receipts — by anyone, the operating customer included. The claim is grounded in signed receipts hash-chained into an append-only log, signed checkpoints over that log, and an independent witness that holds tree heads outside the customer’s control. What is not claimed is listed below, ships in the documentation, and is reflected in the verifier’s own output: the verifier reports exactly what it checked and nothing more.

What verification proves

Every receipt, and every delegation hop inside it, carries one of three verification states. Three states, not two — collapsing the middle state into “broken” would misrepresent evidence that was honestly recorded but is not cryptographically provable.

• verified — the cryptography checks out: the signature is valid over the exact stored bytes, and for a delegation root, the key binding holds. A verified state proves the bytes were signed by the named key and have not changed since.
• asserted — recorded faithfully at capture, but resting on a claim the cryptography cannot independently prove: a self-reported client label, an emitter-to-actor association, a human approval click, an imported record. Asserted evidence is still evidence — it is simply labelled as testimony rather than proof, and nothing ever silently upgrades it.
• broken — an invalid signature or a violated chain invariant. Broken means the evidence fails its own integrity check and says so.

The receipt-level state is the weakest hop in its chain. A typical fresh installation renders as “verified root, asserted chain”: an honest description of what the cryptography covers, not a defect.

Verification runs twice, both in customer territory: the capture surface verifies at capture, and the offline verifier re-verifies an export with no call to behalf or the identity provider. A third party can verify an export independently.

Adversaries

Adversary	What stops them	What they can still do
A prompt-injected or malfunctioning agent	Cannot forge identity (chain signatures); cannot exceed granted scope (proxy enforcement); cannot act unrecorded when routed through the proxy in enforcement mode	Can emit lying content; that content is recorded and stays asserted — behalf makes no claim about the agent’s own integrity
The workstation user	—	Can remove hooks or route around the proxy entirely. Out of scope for v1 integrity claims; mitigated by capture-coverage visibility, closable only by managed policy in a later milestone
The operator / customer admin	Cannot rewrite or truncate history undetected: witnessed checkpoints make a restore that presents a tree older than the last witnessed checkpoint detectable, and any tail loss must be declared in a restore-epoch receipt rather than absorbed silently	Can stop capture going forward — which is visible as silence in the log
behalf itself	Holds no payloads, no plaintext identity, and cannot alter customer logs it never touches	—
A checkpoint-key thief	Bounded by the witness’s independently held tree heads: a forged history diverges from what the witness has already signed	Full key-compromise recovery procedure is a later milestone
A flooding attacker	Bounded by the append-latency threshold and spool policy: overload sheds to signed loss_marker receipts rather than silent loss	—
Legal compulsion against behalf	Yields digests and metadata only, by construction — payload content and plaintext identity are not in behalf’s possession	—

What behalf does not claim

These exclusions are part of the specification, not fine print.

• No defense against pre-capture suppression. Custody begins at capture-signature. An agent or process that never routes through the capture surface leaves no receipt, and behalf cannot prove the absence of actions it never saw. The published claim is “custody from capture-signature; suppression before capture is out of scope.”
• No agent self-integrity claims. behalf records what an agent did across trust boundaries. It makes no claim that the agent’s reasoning, self-reports, or emitted content are truthful; such content is captured and marked asserted.
• The workstation user is out of scope for v1. A user with control of the machine can disable or bypass capture. Coverage gaps are made visible rather than prevented.
• No confidentiality of volume or timing toward witnesses. Checkpoints sent to witnesses contain tree heads and origin, never receipt content — but the existence, rate, and timing of activity is necessarily visible to a witness.
• Payload availability is not guaranteed by behalf. Payloads are customer-held; a receipt whose payload is missing, deleted, or unreadable still verifies, and says which of those states applies.

If verification fails

An append-only store has no hotfix path, so the failure procedure is defined before any incident, and the schema reserves a chain-epoch/exception receipt so that the first incident annotates history rather than inventing a mechanism after the fact:

1. Freeze appends and snapshot the log.
2. Bisect with the verifier to the first divergent leaf.
3. Classify: implementation bug versus tampering.
4. For a bug: re-attest the affected segment under an epoch statement that is itself part of the log. For tampering: preserve the evidence and disclose.
5. Customer notification obligations apply in either case and are stated in the documentation.

A restore from backup may never present a tree older than the last witnessed checkpoint; the witness makes restore-as-truncation detectable, and any tail loss is declared in a restore-epoch receipt rather than absorbed silently.