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. Allowlisting fails in the field for organizational reasons more than technical ones. 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 three 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. Specifically: where 90% of access requests get auto-resolved without anyone looking, and the human approver only sees the 10% where their judgment is actually needed.
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 actually 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.
The 90% that shouldn't need a human
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 twenty-four 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 two 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: ninety seconds.
Handle access this way across every routine session and the approval queue contracts by an order of magnitude. The 90% isn't a stretch. It's what happens when access decisions that don't need human judgment stop demanding it.
The 10% that has to stay
What remains in the queue after the system auto-handles routine work is what the IT lead's judgment is actually useful for. 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.
The first is 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.
The second is behavioral history as input to the access 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 actually 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 two services for thirty minutes. The user previously had standing read on twelve services indefinitely. Scope is narrower. Review is rarer. Both at once.
The system doesn't decide everything. Approvers approve. The decisions that need judgment stay with the people whose job it is to apply it. What the system removes is the bookkeeping. Anthropic puts this well: automate the bookkeeping around incidents, not the decisions. The same principle applies to access.
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.
What to do with this
If you're rolling out agent access controls and worried about the friction objection Kane named, the question to ask isn't "how strict can we go." It's "what fraction of the requests we currently route to humans can we auto-resolve without losing the security property." If the answer is meaningfully less than 90%, the system isn't reasoning about intent or behavior, and the queue will grow until your team rolls it back.
Allowlisting isn't the wrong instinct. The model around it does most of the work.