Allowlisting is the right instinct and the wrong implementation. It fails on organisational friction rather than on technical grounds, which is why a stricter allowlist never fixes it and a model where most of the allowlist never reaches a person does.
Kane Narraway, writing about Anthropic's Zero Trust for AI Agents guide last month:
The call for more of an allowlisting approach I think a lot of orgs will struggle with. Locking things down adds a lot of friction, and it's more of an organisational problem that employees aren't always onboard with.
He's right, and the friction has a specific shape. The IT manager at a 400-person company doesn't get bypassed because their controls are weak. They get bypassed because their queue is six requests deep and the engineer needs read access to a production log right now, and the right answer is either "wait 3 hours" or "open it up." One of those is what happens, every day, at every company that tried to lock down and didn't think about what came next.
The fix isn't a better allowlist. It's a model where the allowlist is invisible most of the time: most access requests auto-resolve without anyone looking, and the human approver only sees the ones where their judgment changes the answer.
We write that target as 90/10. It's a design goal rather than a measurement, and it's worth saying so plainly, because the number is doing real work in the argument. What we can defend is the mechanism: if the fraction reaching a human doesn't fall by roughly an order of magnitude, the queue grows back and the rollout gets reversed. 90/10 is where the model stops being theoretical.
That's the rest of this post. Where the 90% comes from, what stays in the 10%, and what has to be true for that ratio to hold.
Where allowlisting breaks
When a team rolls out a strict allowlist, the friction shows up in three places.
-
The queue. Every request the system can't auto-approve goes to a human. If your controls were lax and the friction was zero, switching to strict adds friction at every action. The queue grows. The approver, who has a day job, develops a fifteen-second approval cadence. Rubber-stamping starts within a week.
-
The workaround. Engineers find the way around. They use a personal account. They share credentials. They pipe API keys directly into the AI tool. Kane has written about this in another post: people grab session cookies out of browser local storage when the supported path is blocked. The harder you make the supported path, the harder employees work to avoid it.
-
The political cost. The IT team becomes the team that says no. Leadership leans on them to relax controls because sales can't close, engineering can't ship, support can't resolve. The allowlist stops being a security control and starts being a budget negotiation.
These three failure modes share a shape. They show up when the system treats every access request as if it warranted human judgment. Most don't.
Where the split falls
Strip the access requests an AI agent makes during a typical day into categories. Most of them fall into patterns the system has seen a thousand times before. An engineer debugging a payment service queries the same set of logs, in the same time window, against the same payment processor. The system has the pattern. It has the user's history. It has the agent's track record. There's nothing for a human to add.
This is the work that disappears from the approval queue when the access layer treats sessions as the unit of governance, not entitlements. A session begins with a declared intent: "investigate payment retry failures for the last 24 hours." The system scopes the session: read on the payment service logs and traces, time-bounded, no write access. If the agent stays inside that envelope, no human approves anything. The session opens, the work happens, the session closes. The audit trail captures the intent, the actions, the outcome.
The same pattern handles routine new-user access. James joins the data team. His session begins: "pull Q4 revenue from analytics." The system identifies a new user, no prior sessions, requesting read on three specific tables. It scopes the session to 2 hours, read only, on the named tables. The team lead gets one Slack notification with the recommendation already structured. Most of the time, the team lead taps approve in the notification and that's the entire workflow. The session is auto-bounded; the human is auto-briefed. Total elapsed time from the user's prompt to the data being available: 90 seconds.
Handle access this way across every routine session and the approval queue contracts by an order of magnitude. That isn't a stretch. It's what happens when access decisions that don't need human judgment stop demanding it.
What remains in the queue after the system auto-handles routine work is where the IT lead's judgment earns its place. Anomalous patterns. New scope requests. Scope expansions mid-session. Agents attempting actions outside their declared intent. The contractor whose session is asking for a wider envelope than usual.
This is the work that doesn't compress. It needs context: who is this user, why are they doing this now, is the change reversible. The IT lead approving write scope to a payments database needs to know the story. The system can supply most of it: prior history, trust score, blast radius, alternatives offered. The lead applies judgment to what the system can't decide.
What's different from the original allowlist model is the volume. The lead isn't approving fifteen requests a day, half of them rubber-stamps. They're approving two or three a day, each with actual stakes. The rubber-stamp pattern doesn't form because the rubber-stamp situations never reach the lead.
This is the answer to Kane's organizational objection. Allowlisting at scale doesn't fail because allowlisting is wrong. It fails because the model that puts every request in front of a human is structurally incompatible with the volume of agent activity. Change the model.
What has to be true for the ratio to hold
Two things, and the order they get checked in is the whole mechanism.
session opens with a declared intent
|
+-- is there an intent at all?
| no ------------------------> QUEUE a human decides everything
| yes
|
+-- is the requested scope inside that intent?
| no ------------------------> QUEUE scope expansion needs judgment
| yes
|
+-- has this actor run this pattern before?
no ------------------------> QUEUE new actor or new shape
yes ------------------------> AUTO time-bounded, logged, no approver
~90% resolve here ~10% reach a person
narrower scope than the each one with real stakes
standing access it replaced and the context attached1. Intent as a primitive at session start. Without a declared intent, the system can't tell what's inside the envelope and what isn't. Every action becomes ambiguous and the 90% collapses. Most current IAM stacks don't have this primitive. They have credentials and scopes. The session-with-intent is the layer above the credential that makes auto-resolution possible.
2. Behavioural history as an input to the decision. A new user gets more scrutiny than a senior engineer who has run this pattern eighty times. A contractor in the first month of their engagement runs in tighter mode than a full-time engineer. Anthropic's whitepaper gestures at this with attribute-based access control. The practical version is a per-actor trust score that updates continuously based on what the actor actually does.
Without these two pieces, the split doesn't form. The system has no way to know what's routine and what isn't, and every request defaults back to the queue. The friction Kane describes becomes the friction in your organization. With them, the queue contracts to what needs a human, and the rest happens at the speed the work demands.
What this is not
A few things to clear up.
-
It isn't a wider allowlist. The 90% that auto-resolves runs inside a tighter envelope than the original allowlist would have permitted. A debug session has read access to 2 services for 30 minutes. The user previously had standing read on 12 services indefinitely. Scope is narrower. Review is rarer. Both at once.
-
It isn't fragile. The intent declaration isn't optional, and out-of-scope actions don't get a pass. If an agent attempts to write to a database when its session intent is read-only, the action is blocked. The friction surfaces exactly where friction is warranted, which is also exactly where the approver's attention pays off.
Doing this without a tool
You can approximate the split with what you already run, and the approximation is worth building even if you never buy anything, because it tells you your real ratio.
- Log every access request for 2 weeks with what was asked for, who asked, and what the approver decided. Nothing else changes yet.
- Sort them into repeat and novel. A repeat is the same actor, the same resource, the same shape of work. Whatever fraction comes back as repeats is your own ceiling for auto-resolution, and it's the only version of this number you should trust, because it came from your environment rather than ours.
- Write standing time-bounded grants for the top repeat patterns. A short-lived role assumed on demand, expiring on a timer, is the crudest version of a session and it works.
- Make expiry the default, not an option someone remembers. Anything without a timer is standing access wearing a different name.
- Route only the novel requests to a person, with the actor's history attached so the decision is fast.
- Re-sort monthly. Patterns that were novel become repeats, and if you never promote them the queue creeps back.
The sorting exercise costs an afternoon and it settles the argument either way.
If most of what your team approves turns out to be the same handful of shapes coming back, you've just measured how much attention is going into decisions that were never decisions. If it doesn't, the friction is real and this model won't fix it.
What still needs a person
The system doesn't decide everything, and shouldn't. Approvers approve. What comes off their plate is the bookkeeping, not the judgment. Anthropic puts this well: automate the bookkeeping around incidents, not the decisions.
Three things stay human. Write access to anything whose blast radius is hard to reverse. A scope expansion mid-session, because the reason for it lives outside the system. And the first session for a new actor, where there's no history to reason from and somebody has to set the precedent.
Where Iden fits
Steps 3 and 4 above, without the spreadsheet in the middle.
A request carries its intent, the duration comes from the template rather than from whoever is typing, and the grant expires on its own. The only thing a person writes is the reason.
Die Anfrage dort, wo ohnehin gearbeitet wird. Dauer und IAM-Gruppen kommen aus der Vorlage, getippt wird nur die Begründung.
The request lives where the work already happens, which matters more than it sounds: a supported path that requires leaving the tool is the path people route around.