WIMSE, AIP, and draft-klrc-aiagent-auth all address service-to-agent trust: how a downstream API verifies that an agent is authorized to call it. None of them address user-to-operator trust: whether the operator's instructions to the agent actually reflect what the user authorized.

The trust gap is structural. The delegation chain is User → Operator → Agent → Services. The user tells the operator what they want. The operator writes a system prompt. But there is no cryptographic record of the user's original intent at the moment of delegation. The operator becomes an unchecked intermediary. If an operator is compromised, goes rogue, or is compelled by a court order, the agent cannot distinguish that from legitimate instruction. The user has no recourse. Auditors have no evidence chain.

AuthProof fills that gap with a *Delegation Receipt*: a signed Authorization Object anchored to a decentralized append-only log before any agent action begins. Four fields: a structured scope (explicit allowlist, deny by default), hard boundaries the operator cannot override, a time window anchored to the log timestamp not the client clock, and a hash of the operator's stated instructions at delegation time. If the operator later instructs the agent differently, the hash mismatch is provable from the log.

The trust stack has three layers:

1. *Signed capability manifest* — the scope field references the hash of a signed server manifest, not the operator's self-reported schema. Tool server behavior that diverges from the manifest is detectable.

2. *Delegation Receipt* — removes trust in the operator as a faithful intermediary.

3. *Safescript execution binding* — the `executes` scope class requires the hash of a specific Safescript program's static capability DAG. Safescript is statically analyzable before execution; there's no dynamic dispatch. If the operator supplies a different program than the one the user authorized, it doesn't run.

For out-of-scope tool calls, the agent pauses and requests a micro-receipt from the user for that specific action. No silent capability expansion.

Anticipating the obvious objections:

*"Why not just use OAuth scopes?"* OAuth scopes represent the operator's request for access, not the user's authorization of a specific agent behavior. The operator controls the token request. AuthProof commits the user's authorization before the operator's instructions reach the agent.

*"Why a custom log? Why not a blockchain?"* The protocol is log-agnostic. Any tamper-evident append-only log with fork detection works. Certificate Transparency-style logs are a natural fit. Blockchain is one option; it's not required.

*"What if the user doesn't understand the scope they're signing?"* The scope is structured, not natural language — that's a deliberate protocol constraint. UI is a separate problem. The protocol guarantees that what the user signs is what the agent is bound by; it doesn't guarantee the user will read it carefully, any more than a contract guarantees the signer read it.

*"Safescript is obscure."* It is. The `executes` layer is the most ambitious part of the protocol and the least mature. It's a design stake in the ground for what the correct solution looks like; the practical adoption path for execution binding may involve other static-analysis tools.

npm: `npm install authproof-sdk` Whitepaper: WHITEPAPER.md in the repo

Interested in serious critique on the log design and the micro-receipt UX problem.

Cryptographic delegation receipts to close the user-to-operator agent trust gap