Permission to spend, without the party granting it learning what for.
Before an agent is allowed to spend, something usually has to approve it: a credit check, an allowlist, a compliance desk. Every one of those learns what the agent is doing, because the approval and the job travel together. They do not have to.
A third-party caveat splits them. The service writes into the credential "this is valid only if the voucher confirms X", sealed so only the voucher can read it. The voucher answers X and nothing else. The service never contacts the voucher, the voucher never learns the job, and the discharge it issues works for this one credential and no other. Everything here runs in this tab: HMAC-SHA256 chains and AES-GCM sealing. No server, no node, no wallet.
Holds the root key. Writes the caveat and checks the result. Never speaks to the voucher.
Holds the credential. Must fetch a discharge before it can spend. Sees both, understands neither.
Answers one sealed question. Never learns the job, the amount, or the service's key.
The caveat is not a string the agent could edit. It is a sealed blob that only the voucher can open, containing a fresh key and the single question the voucher must answer.
The signature is perfectly valid. It is refused anyway, because a third-party caveat is not satisfied by holding the credential.
The voucher opens the sealed caveat, sees a predicate and a key, and issues a discharge bound to this credential. What it sees is printed in full below, so you can check what it did not.
With the discharge attached the credential works. Then two abuses: reuse that discharge on a different job, and forge one outright.
The service learns that its question was answered, and never what the voucher saw. The voucher learns one predicate and one key, and never the job, the budget, or which service asked. The agent carries both and can read neither. Two things are load-bearing and no more: the root key stays secret, and the voucher answers its question honestly. Neither of them has to be online when the other acts, because the discharge travels with the agent.
Implemented: macaroon minting and verification over an HMAC-SHA256 chain, third-party caveats with an AES-GCM sealed caveat identifier, discharge macaroon issuance, and cryptographic binding of a discharge to one root credential. Not implemented: payment, chained third-party caveats where a discharge itself carries one, caveat expiry, and key distribution between service and voucher, which is assumed here to have happened already. This page proves the authorization mechanism; it moves no money and contacts no network.