Delegation Receipts: Proving an AI Agent Only Ever Lost Authority, Offline
The question nobody else lets you answer offline
When an AI agent does something that matters, someone eventually has to verify it. An auditor. A regulator. A customer whose data the agent touched. A counterparty whose system the agent called. The question they ask is simple: what was this agent allowed to do, and did it stay inside those lines?
Today, every major answer to that question routes through a vendor's server. Okta, Microsoft Entra, Ping, and CyberArk all reached general availability for agent identity in 2026, and they are serious products. But they share one property without exception: to verify that an agent is who it claims, was permitted what it claims, and did what it claims, you call their authorization server. Take Okta or Entra offline and the proof is gone. The crypto-native alternatives go the other way and put agent reputation on a blockchain, which means wallets, gas, and a permanent public ledger that most regulated enterprises will not touch.
There is a seam between those two worlds, and it is where the hardest verification problem lives: can a counterparty verify an agent's identity, its permissions, and its history with no vendor in the loop and no blockchain anywhere? As of @vorim/verify 0.5.0, the answer is yes, and the proof artifact has a name: the delegation receipt.
What a delegation receipt is
Agents delegate. A user authorises agent A. A hands a narrower slice of that authority to agent B. B hands a narrower slice still to agent C. This is how real agent systems work, and it is also where authority quietly leaks: at each hop, did the scope actually shrink, or did someone widen it?
A delegation receipt is a human-readable record of that chain, rendered from a cryptographic verification, showing exactly how authority narrowed at each step:
═══════════════════════════════════════════════════════════════
DELEGATION RECEIPT (offline-verified — no vendor, no blockchain)
═══════════════════════════════════════════════════════════════
Chain chain_demo_001
✓ VERIFIED
depth: 2 hops
┌─ hop 1: agent_A → agent_B
scopes: [agent:read, agent:write, agent:execute]
sub-delegation budget remaining: 2
└─ hop 2: agent_B → agent_C
scopes: [agent:read]
↓ dropped: [agent:write, agent:execute] (authority narrowed)
sub-delegation budget remaining: 1You can read it in five seconds: agent A could read, write, and execute. By the time authority reached agent C, write and execute had been dropped. C can only read. And critically, the ✓ VERIFIED is not a label we printed for decoration. It comes from the same offline cryptographic check as the rest of the bundle.
Why the "✓" is trustworthy
A receipt that draws a pretty tree but lies about whether it verified would be worse than useless. So the receipt is rendered from the real verdict, not the other way around. Before any hop is drawn, the verifier checks, offline, against public keys carried inside the bundle itself:
- Signature. Each link must be signed by the delegator's Ed25519 key. A forged link fails here first, before any structural check can be gamed.
- Continuity. Each hop's delegator must be the previous hop's delegate. This stops a splice attack, where two independently-valid links (A→B and X→Y) are stitched together to attest authority that never actually flowed from B to X.
- Depth cap. If a parent link said "you may not sub-delegate," a child link that tries to is rejected, not drawn.
- Scope subset. Each link's scopes must be a subset of its parent's, with multiset semantics so duplicate-padding cannot widen authority past the signed parent set.
If any of these fail, the receipt renders the chain as broken, not verified. A widened or tampered chain cannot masquerade as a clean one. We test exactly this: a chain that tries to grant a scope its parent never had comes back DELEGATION SCOPE EXCEEDED, never ✓ VERIFIED.
No vendor, no blockchain — and why that is the whole point
The receipt is produced by @vorim/verify, an open-source, zero-dependency npm package. It makes no network calls. It does not contact Vorim. Every public key it needs to check a signature is embedded in the bundle. You can verify a delegation chain with Vorim offline, or with Vorim gone entirely.
That is the property the incumbents cannot match. Their verification is the call to their server. And it is the property the on-chain approaches achieve only by putting your agent's interactions on a public ledger. Vorim sits in the seam: centralised issuer for convenience, but verification that needs neither the issuer nor a chain.
This is the one thing competitors do not have
We are being honest about the field, because a vendor who overclaims is not worth trusting on cryptography of all things. Signed audit at source is no longer ours alone, and on-chain agent reputation now exists too, via ERC-8004 on Ethereum mainnet, backed by contributors from the Ethereum Foundation, Google, and Coinbase.
But attenuated multi-hop delegation, verified offline, is still category-of-one. Okta and Auth0 do OAuth scope grants. Microsoft Entra does on-behalf-of impersonation. Google's A2A protocol explicitly defines no way to cap what a downstream agent can spend. None of them produce a portable, offline-checkable record of how authority narrowed across an agent chain. The delegation receipt is exactly that record, and it is shipped, tested, and open source today.
Try it
npx @vorim/verify --receipts bundle.json@vorim/verify is on npm under the MIT licence, with zero dependencies and a Python verifier alongside it. Export a signed audit bundle from Vorim, run the command, and read the receipt. No account needed to verify; no network call made.
If you are building or governing AI agents and need to prove what your agents were allowed to do, not just assert it, this is live now. Full documentation is at vorim.ai/docs, and we are happy to talk through the threat model at team@vorim.ai.
Ready to build with agent identity?
Free plan: 3 agents, 10K auth events/month, full SDK access. No credit card.