Loop custody needs a credential, not a policy page · The Pritam Edge

I closed an earlier essay saying loop custody needs a list of loops and a name next to each one. I was wrong. A name in a governance document is not custody. Custody is only real when the agent cannot act without carrying proof of who authorized it, and that proof survives every hop.

Devika did exactly what I told her to do.

She has a list of loops. She has a name next to each one. On the loop that matters this morning, the name is hers. She wrote the register herself, walked it through review, and got it signed. By the standard I published in July, her organization is governed.

At 6:40 this morning, an agent she owns delegated a piece of work to a second agent. The second agent called a tool. The tool moved a payment.

Every hop was authorized. The first agent was permitted to delegate. The second was permitted to call that tool. The tool was permitted to move money. Three green lights in a row, each one locally correct, and a payment at the end of them that Devika would not have approved if anyone had thought to ask her.

Now she goes looking for the moment her authority entered that chain. She finds a document with her name in it. That is all she finds. The payment carries no trace of her. The tool never knew she existed. The chain as a whole was authorized by nobody, because nothing in the chain was ever asked to carry the authorization.

The sentence I have to take back

In July I closed an essay on loop custody with this line:

"The fix does not require a framework, a platform, or a committee. It requires a list of loops and a name next to each one."

I wrote that. I no longer believe it, and I would rather say so in public than let it quietly age into something people are still quoting back to me next year.

What changed my mind was watching delegation chains, in the seventeen agents I run in my own lab and in the literature that has arrived since. The register I was so pleased with is a document. Documents are read by humans, at human speed, after the fact. The chain that moved Devika's money ran across three trust boundaries in under a second, and not one component in it could read her register, would have known to look, or had anywhere to put her name if it had found it.

A name in a governance document is a claim about who would have said yes. It is not evidence that anyone did. Custody is only real when the agent cannot take a consequential action without carrying proof of who authorized it, and that proof survives every hop.

That is the corrected position. Three threads on why it took me six months to get there.

1. The hops are authorized. The chain is not.

Here is the structural thing I under-weighted. Authorization in an agent system is granted pairwise. A grants to B. B presents to the tool. The tool acts on the resource. Each edge is checked. The path is not.

Tallam's position paper on agentic identity, published in May, gives the failure a decent vocabulary. Transitive delegation: authority passed down a chain acquires a scope nobody at the top ever granted. Aggregation inference: individually harmless permissions compose into a capability that would never have survived review as a single request. Temporal validity: authority that was correct when it was issued and is no longer correct when it is finally exercised, several hops later. It is a position paper rather than a measurement study, so I will attach no failure rate to any of that. I do not need one. The shape is enough, because the shape is the same shape I have watched in my own lab.

The most useful sentence I have read on the mechanics comes from an internet-draft on agent authentication, and it is blunt: "It is an anti-pattern for Tools to forward access tokens it received from the Agent to Services or Resources." Read that as an engineering instruction and it says something uncomfortable about most agent stacks shipping today. Passing the same token down the chain is the default in almost every framework I have opened. The draft's alternative is exchange at each hop: every component trades what it was given for a fresh, narrowed credential that names who it is acting for and why. Exchange is what preserves the record. Forwarding is what destroys it, which is why a forwarded token tells you a payment was authorized and never tells you by whom.

The same draft is direct about the other half: "Agents MUST possess credentials that provide a cryptographic binding to the agent identifier." A credential the agent holds, bound to the agent, presented at every boundary. Not a row in a register.

2. Why everyone writes a policy page instead

Now the generous part, and I mean it generously, because I was one of the people writing the policy page.

Organizations are not writing governance documents because they are lazy or because they prefer theatre. They are writing them because there is currently nothing else to write. Six months into the most serious attention this problem has ever received, there is still no credential for an agent to carry.

Look at what the last six months actually produced. In February, NIST's NCCoE put out an initial public draft of a concept paper on adoption of software and AI agent identity. Comments closed on April 2. A concept paper is a statement that a problem is worth organizing around; it is not a framework, and nobody should read it as one. On the standards side, the agent-authentication draft I quoted above is an individual internet-draft at revision -00, filed in March by authors from four different vendors. It expires on September 3, about a week after this essay publishes. Internet-drafts expire routinely and most of them go nowhere. It is not a working-group product, it is not adopted, and it may never become either.

I want to be precise, because this is exactly where commentary goes bad: no standard exists here. None is required of anyone. I am not predicting that one arrives. What I am pointing at is a gap between the operational need and the available machinery, and that gap is what the policy page is filling.

So when a governance lead ships a register with names in it, that is not a failure of seriousness. It is the only artifact currently purchasable. My July essay was popular precisely because it was implementable on a Monday with a spreadsheet, which should have been my first clue that it was solving the tractable half of the problem.

Here is why it does not hold. A policy page is enforced by memory and goodwill, at the speed of meetings. The chain it governs runs at machine speed, across process and vendor boundaries, in a context where nobody is present. Any control that lives only in a document is a control that the system it governs cannot see. Call it what it is: paper custody. Custody that exists in a file, has a name on it, satisfies an auditor's first question, and is structurally incapable of stopping the thing it was written about.

Paper custody is not worthless. It tells you who to call. It is simply not custody, and I spent six months conflating the two.

3. What a carried credential would have to do

If custody has to travel with the action rather than sit in a binder, then the requirement is testable, and I would rather state the test than pretend I can hand anyone an implementation.

It would have to be bound. Cryptographically tied to the identity of the agent presenting it, so that possession by the wrong actor proves nothing. An identifier that anyone can assert is a username, not an identity.

It would have to be exchanged, not forwarded. Narrowed at every hop, so that what the tool presents to the payment resource is derived from what Devika authorized rather than a copy of a token that has been laundering its way down the chain acquiring scope.

It would have to carry the human. This is the part I most clearly missed in July. Somewhere in that credential is the assertion that a named human set this goal, funded this work, and accepted these consequences, and that assertion has to remain legible at hop three, in a component that has never heard of her register.

And it would have to expire and be revocable in flight. Temporal validity is the quiet one. Authority that was correct at 06:40 and wrong at 06:41 needs a mechanism to become wrong, not a note in a postmortem.

Tallam's framing is the right altitude to close on: identity governance "must be treated as infrastructure: evaluated continuously, enforced at every interaction boundary, and designed into the system before orchestration logic is allowed to scale." Enforced at every interaction boundary. Not asserted once, at the top, in a document.

Nobody uses my term for this. NIST does not say loop custody. The IETF draft does not say loop custody. That phrase is mine, and I am not going to pretend otherwise by implying that a standards body has blessed my vocabulary. What those sources establish is narrower and more useful: the identity and authorization problem underneath the vocabulary is unsolved at the level where solutions are supposed to come from, and the people trying to solve it agree that forwarding a token down a chain is the wrong shape.

Which leaves the honest position, and I would rather hold an honest position than a comfortable one. Extend the power of the LLMs; contain the abandon of the agents. The containing turns out to require plumbing that does not exist yet, and the interval between recognizing that and having it is exactly where every organization currently running delegation chains is standing.

Devika's register was not wrong. It was just the only half of the problem she could reach.

A name tells you who would have said yes. A credential is proof that somebody did, still binding at the third hop, when nobody is in the room.

Custody that cannot travel is not custody. It is paperwork with a name on it.