Approval is an event. Delegation is a duration. Almost every system that lets an agent act on someone's behalf is built around the first and blind to the second.

The interface is always the same, and it is always convincing. A tool is connected. A scope is granted. A person clicks "allow" once, and from that moment on, an entity that is not a person performs actions that count as that person's actions. The timestamp is recorded. The scope is written down. Everyone downstream treats the resulting activity as authorized, because there is a row that proves it was.

What that row proves is that at time T, someone said yes to something. What it does not prove is that anyone knows what happened at time T+40 days, when the agent was still working, the scope was still open, and the system it was acting on had changed shape three times.

This is the delegation layer: the space between the act of granting and the ongoing fact of being represented.

The grant is cheap, the representation is not

Granting permission is a moment of optimism. It is designed to take four seconds, because every extra second lowers the conversion rate of whatever flow it sits in. The scope picker has a "select all" option; the consent screen has a pre-checked box; the OAuth dialog has been optimized by people whose job is to make it easy to say yes.

Representation is the opposite: it is the accumulated set of actions taken under that grant, and nobody optimizes it because nothing in the funnel depends on it. There is no screen that says "here is everything that has been done on your behalf this quarter, and here is which of those you would recognize."

So the asymmetry is structural. The company spends engineering effort making the grant frictionless and almost none making the representation legible. The person ends up having authorized far more than they believe, for far longer than they remember, in a form they cannot audit.

"Approved" describes a moment; the agent describes a trajectory

Consider what an approval actually contains. It contains an intent ("connect my calendar"), a scope ("read events"), and a subject ("this app"). It does not contain, and cannot contain, a description of the trajectory that follows: which events, how often, retained where, combined with what, forwarded to whom, under which future version of the tool's terms.

An agent's behavior is not a subset of its approval. It is a path through the space the approval opened. Two agents with identical scopes can produce wildly different paths, and the difference is exactly the part nobody wrote down at grant time.

This is why "we got explicit approval" and "we know what it did" diverge so reliably. The first is a fact about the past with a timestamp. The second is a claim about a trajectory that no one was watching, because watching was never anyone's job — the approval was supposed to make watching unnecessary.

Authorization was designed for humans, who are slow and observable

The entire vocabulary of access control was built for a world where the actor and the grantee were the same slow, embodied person. A human with read access to a database reads a few rows and gets tired. A human with send permission sends a few emails and goes to lunch. The rate limit on human action is attention, and attention is a very effective safety mechanism that nobody had to design.

Delegation removes that limiter and keeps the vocabulary. Scopes still say "read" and "write," but a read that happens ten thousand times an hour, correlated across every tenant, is a different act from a read that happens once. The scope is unchanged. The meaning is completely different.

This is the same failure as a consent record that counts clicks: the artifact is preserved, the semantics drift, and the artifact is what gets audited.

The interesting cases are the ones where delegation is refused

This week a large airline announced it would not let AI agents book flights on behalf of travelers. The immediate read is "luddism" or "protecting revenue." The more useful read is that this is what it looks like when a counterparty decides the authorization question is unanswerable.

Think about what the airline would have to know to accept an agent's booking: who is the principal, is the agent's authority current, is the specific transaction within it, and what happens when the transaction is wrong. Today, in practice, the answer to all four is "a token showed up." A token proves a credential was presented, not that a person authorized this purchase, this seat, this fare class, this payment method, right now.

When the receiving side cannot distinguish "the traveler decided" from "an agent decided on the traveler's behalf," the cheapest safe response is to refuse the whole class. That is what happened. It is not a policy failure on the airline's part; it is a measurement failure on ours. We shipped agents that act with authority we cannot transmit.

Multi-party delegation makes the gap visible

Single-hop delegation can hide behind a checkbox because the person and the principal are the same. Add one hop and the fiction collapses.

A team lead grants an agent access to the team's documents. The agent summarizes them into a shared channel. A downstream agent reads that channel and drafts customer emails. At no point did any human approve the specific act of one tenant's internal notes appearing in a customer-facing draft. Every hop was authorized. The composition was not.

This is the delegation layer's version of the subprocessor chain: each link is legal, documented, and individually defensible; the end-to-end path is invisible to every party that would care about it. And unlike a subprocessor list, there is no disclosure requirement, no register, and no one whose title includes the word.

Revocation is the only place delegation becomes measurable

If you want to know whether your delegation system is real or theatrical, do not audit the grant. Audit the revocation.

Ask: after the grant is withdrawn, how long does the agent keep acting? Not "when does the database row change" — when does the last action taken under the old authority stop? Agents cache credentials. They hold sessions. They have retry queues. They run on schedules someone set up months ago and nobody has looked at since.

Almost every team answers this question with a guess. The honest answer requires actually revoking something and watching, which nobody does, because the test is disruptive and the failure is embarrassing. So the property that matters most — can you stop it — is the one property that is never tested. It is untested in the same way that a backup is untested until the restore.

What to measure instead

Four cheap metrics, none of which require a new system.

First: one sentence per grant. For every standing authorization in your product, the person who granted it should be able to say, in one sentence and without looking, what it allows an agent to do on their behalf. If they cannot, the grant is not informed, whatever the checkbox said.

Second: the recognizability test. Take last quarter's agent actions for one account and show the list to the person who granted the access. Ask which of these they would have approved individually. The ones they would not have approved are your delegation gap, measured in transactions rather than adjectives.

Third: revocation latency. Revoke one standing grant in a staging environment and measure the time until zero further actions occur under it. This is the only number in this whole area that is unambiguous, and almost nobody has it.

Fourth: the composition question. For any agent output that reaches a third party, can you name every principal whose authority contributed to producing it? If the answer is "the person who ran it," you have single-hop accounting for a multi-hop system.

Friday exercise

Pick one standing delegation in your own systems — a connected app, an agent with a token, a service account with a broad scope. Write four lines:

  1. Granted. What exactly was approved, by whom, in what words on screen, and when?
  2. Done. What has actually been done under it since — not the scope, the actions.
  3. Composed. Whose data and whose authority combined to produce the outputs that left the system?
  4. Stopped. If you revoked it right now, what would still be running, and for how long?

Then do the fourth line for real, somewhere it does not matter. The number you get is the only honest measure of whether the delegation is yours to control.

Delegation is not a permissions problem. Permissions were solved, in the sense that we can store and check them. Delegation is a representation problem: an agent can act for you continuously, and there is no artifact anywhere that says, in a form you would recognize, what it has been doing with that. Approval was the moment you said yes. The layer is everything that happened after, and it has been running unattended.

If you have a standing grant somewhere — an integration that has been acting on your behalf since a quarter you no longer remember — say so in the comments. We keep a one-page worksheet with four lines: what was approved, what it actually did, whose data and permissions it combined, and what is still running after you revoke it, and I will send it over. No form, no email list.