Authority Is Granted in Four Places

When a team goes looking for how their agent got permission, they open the identity system. That's one surface of four — and it's the only one with an owner, a review cycle, and an auditor.

When a team goes looking for how their agent got permission to do something, they look in one place.

They open the identity system. They pull the role, they read the policy attached to it, and they either find the permission or they do not. If they do not find it, the investigation stalls, because as far as the organization is concerned that was the place where permission lives.

It is one of four.

The Four Doors

The credential. The first, and the only one with a mature discipline around it. It answers what the agent can reach — which systems, which data, which environments. It has owners, review cadences, tooling, and in regulated shops an auditor who asks about it on a schedule. Everything in last week’s piece lives here.

The tool grant. What functions the agent is allowed to call. It lives in code or in configuration: a list of tools registered to an agent, a set of capabilities enabled at startup, a schema describing what the model is permitted to invoke. It gets reviewed exactly once, at merge, by a reviewer evaluating whether the code works — not whether the organization meant to grant that capability. After merge it is never looked at again, because nothing in your process is set up to look at it.

The instruction. The one that surprises people. The system prompt, the task description, the operating policy written in prose and handed to the model. “Escalate anything above this threshold.” “Do not issue refunds without a second check.” “Treat these accounts as priority.” Every one of those is a grant or a restriction of authority, expressed in English, stored in a file, and changed by whoever has commit access. It reads like documentation. It functions like policy.

The memory. What the system has written down about itself, its past, and how work gets done here. An agent that recorded the approved workflow is to skip step three has granted itself an exemption no human ever issued — and it will apply that exemption consistently, forever, with full confidence, because as far as it is concerned that is simply what the approved workflow is.

The Audit Asymmetry

The asymmetry is the whole point of this piece.

Surface one has an owner, a review cycle, a budget line, and an external party who checks. Surfaces two, three, and four have a code reviewer who was evaluating something else, a prose author who may not have understood they were writing policy, and — for the fourth — nobody at all.

And the three unwatched surfaces are where the interesting behavior lives. The credential only establishes what is reachable. What actually gets done, and under what conditions, and with what exceptions, is decided almost entirely by the other three. So when the question arrives — who authorized this — the answer is sitting in whichever surface actually granted it, and three out of four have no name attached to the grant.

There is a measurement of this worth carrying. Anthropic’s study of roughly 400,000 Claude Code sessions, published in June 2026, found that humans made 70% of the planning decisions and only 20% of the execution decisions. Planning is where the instruction gets written. Execution is where it gets applied, ten thousand times, with nobody in the room.

Not a Tooling Gap. A Categorization Gap.

These three things were filed as engineering, so they got engineering’s review model, which is optimized for correctness rather than authorization. Nobody decided to exempt them from governance. They were simply never nominated.

The Grid

The remedy is legible and it is mostly clerical. For each of the four surfaces, answer the same four questions:

• Where does it physically live?
• Who can change it?
• What event triggers a review?
• Does a change leave a record with a human name on it?

Run that grid and the failure pattern falls out immediately, because it is almost always identical: surface one scores four out of four, surfaces two and three score one or two, and surface four scores zero across the board.

The fourth column is usually blank not because the team is negligent but because there is no native tooling that makes context and memory inspectable the way an identity console makes access inspectable. That gap is exactly what the Context Architecture Blueprint was built to close. It is free, MIT-licensed, and the source is on GitHub if you would rather read it before you run it.

But the tooling is downstream. The move that matters is the reclassification — treating all four as authorization surfaces rather than one authorization surface and three implementation details.

Most of those grants were correct when they were made. That is worth saying plainly, because the instinct on reading this is to assume a hidden mess, and usually there isn’t one. What there is, is a set of reasonable decisions made by competent people under deadline, distributed across four surfaces, three of which have no mechanism for anyone to revisit them.

Next week: what the record looks like when you can answer the question.