A buyer's clerk once met a supplier's salesperson face to face, and authority was clear: one person spoke for a firm, and a signature bound the firm. An AI agent holds no face and no firm, so the question "who sent you?" needs a written answer that a machine can check. This walkthrough shows that answer as a delegation chain: a person authorises an agent, the agent may hand a narrower slice to a sub-agent, every hop is signed and cites its parent, a receiver can walk the chain back to a person, limits are enforced on the way, a human checkpoint gates the high-value step, and revocation ends it. Every value on this page is illustrative and labelled as such. Nothing here runs, signs, or contacts anything; the page is static and checks nothing for you.
Show how an agent can carry an authority a human can trace: authorise, delegate a narrower slice, sign every hop, refuse what the scope excludes, pause for a person where the value is high, and stop when revoked. The pattern is a design sketch from the public "The Gordian Stack for Cloudflare" note (see the citation in step 1); the estate does not ship these fields today, and step 7 names what it does ship.
a3f9…, and never as complete digests. No signature on this page was produced by any key.The chain starts with a person, called the principal. The principal writes down three things and signs them: what the agent may do (a scope), how much it may commit (a cap), and when the writing expires. Without all three, "the agent works for me" is a rumour. It grants nothing.
Scope, cap and expiry do different jobs. The scope names the actions, so anything absent is out by default rather than forbidden in a list. The cap bounds loss if the agent misreads the world. The expiry bounds loss if the writing simply circulates too long. The design reference for this shape is the public note "The Gordian Stack for Cloudflare", which describes carrying an authorisation in an Envelope and gating high-value actions with a passkey; it is cited here as a public source, and its own status is an unpublished design sketch rather than a standard.
Agent A needs a price checked, so it brings in a sub-agent S. Delegation can only narrow: the slice S holds must sit inside the scope A holds, under the same or a smaller cap, and expire no later. A delegation that widens the grant is the one move this design makes structurally impossible to trust.
The narrowing rule is what makes a chain auditable without a central referee. Any receiver can test each link locally: compare the child's scope, cap and expiry against the parent's. If the child ever exceeds the parent anywhere, the chain is broken at that link and everything after it inherits the break.
When sub-agent S presents a result, the receiver does not take S's word about itself. S hands over its own signed hop, which names A as its parent; A's hop names P. The receiver walks backward link by link, checking each signature and each narrowing rule, until the chain ends at a person.
Two properties fall out of this shape. First, accountability has an endpoint: the walk terminates at a person, so the answer to "who sent this agent?" is a name on the last hop rather than another agent. Second, the walk is local: the receiver needs no directory, no online lookup and no trust in the sender, only the hops themselves, the three limits on each, and the keys that signed them.
A receiver checks the chain before acting, and the check has teeth. Sub-agent S asks to move 80.00 USDC. Its slice carried a cap of zero and a read-only scope, so the request fails twice, and the refusal is itself the interesting output: the agent is stopped here instead of somewhere downstream after the money moved.
The refusal scene is the one a reviewer should study hardest, because a design that only ever shows successes proves nothing about its limits. A receiver that walks the chain and enforces scope and cap turns a forged or over-reaching request into a recorded refusal. The failure lands on the record with the same treatment as a pass, which is what makes the limit visible to whoever audits the session later.
Some actions should not complete on an agent's authority at any scope or cap. The design puts a human checkpoint in the path: when the step's value crosses the line the principal set, the chain stops and waits. The person approves with a passkey tap on a device they hold, and the agent's key cannot release the step. The tap does.
The passkey matters because it puts the approval on hardware the person controls. A tap on a roaming authenticator cannot be replayed for a different step, and the approval is recorded as its own signed hop. Where the chain answers "who sent this agent?", the checkpoint answers the adjacent question, "who decided this particular step?", and keeps the two answers distinct on the record.
Authority that cannot be taken back was never granted, only lost. The design gives the principal a signed revocation. After it exists, any receiver that checks the chain finds the revocation ahead of the new action in the sequence, and the action fails. The chain keeps its history: the earlier, authorised steps stay valid, and only what comes after the revocation stops.
Revocation is order-sensitive, which is why every hop carries its position and time. A receiver sorts the revocation against the action it is checking and refuses anything the revocation precedes. The expiry from step 1 is the same idea on a timer; revocation is the same idea on demand. Neither erases the past, and both only fence the future.
Assembled, the walkthrough ends in one human-legible card: who holds authority, where it narrowed, where a person intervened, and how it ends. A verifier tool for exactly this card is the companion piece to this page. Here is the card for the walkthrough's own chain, with the three field names this design proposes, each labelled spec-pending because they exist in no shipped schema yet.
The estate carries the scope-and-expiry half of this design today, inside signed Policy Mandate documents: section 3.1 of the mandate schema holds the workflow scope and validity window a run must match, and mandate version 1.1 adds the caveats field for named conditions on top. Key loss and key replacement, the revocation problem for the signing keys themselves, is covered by the key rotation and revocation explainer. What the estate does not have today is the delegation chain: the field names delegation_chain, human_checkpoints and revocable_by are labels from a design discussion, and no shipped schema carries them today. No agent decision lineage card is live on the site yet. When it ships, it will render the pp.lineage receipt shape, and this card is what it would show for a chain like the one walked here. That is a design, never presented as a shipped capability.