The access review took a fortnight and produced a clean report. Every permission held by every agent traced back to a named requester, a business justification, and an approval. The identity team had done their job properly. That is what makes the finding awkward rather than embarrassing.
What the review did not do — what no access review does — is consider the permissions together.
A complaints-handling agent had been given the ability to read from a customer database. Later, a different manager asked for read access to an analytics store so complaint trends could be correlated against product data. Later still, someone added the ability to post summaries into a shared workspace, so the team could triage without opening the tool.
Three requests. Three approvals. Three sensible decisions, made five and then seven months apart by people who had no reason to talk to each other.
The analytics store contained a joined dataset with account identifiers in it. The shared workspace was shared with an outsourced quality-assurance vendor.
This is not a story about a careless bank. It is a story about a review process that answers a different question from the one the risk lives in.
Every approval asked: is this permission justified? None asked: is this set safe?
Why the old model held for people and breaks for agents
Role-based access control was built for humans doing bounded jobs, and for those it works well enough. Somebody in claims processing gets the claims role. The role is stable. The job is stable. If they start behaving oddly, colleagues notice — the social layer catches what the technical layer misses.
Agents dismantle each of those props.
They get broad credentials at the beginning of a session, because nobody can predict which tools a multi-step task will need before it runs. They hold everything they were granted for the duration, whether or not they use it — an agent issued eleven capabilities that exercises three still carries all eleven. And what they hold is frozen at the moment of issue. If a weakness in one of those capabilities is discovered forty minutes into a two-hour task, the credential does not find out. It was minted before anyone knew, and it stays as minted until the task ends.
Then multiply. One over-privileged agent is a manageable risk. Forty agents sharing overlapping capabilities across teams is a different animal, because a weakness found in one is almost certainly present in the rest, and the gap between finding it and containing it everywhere is precisely the window an attacker gets to work in.
And forty is a pilot. The number that should worry a planner is the one two years out, when agents are provisioned by other agents and the population is in the thousands. Every control described here has to survive that, which rules out two things immediately: anything requiring a human to review a set before it is granted, and anything requiring a central authority to be reachable at the moment of containment. Both are fine at forty and neither works at four thousand. Designing for the pilot is how organisations end up with a control they quietly stop running in year two.
The agent is not the person, and everything follows from that
There is a habit of speech worth breaking early, because it quietly causes the confusion. We say “the agent has Sarah’s access”. It does not, and it should never.
An agent acting on Sarah’s behalf holds an identity of its own — a non-human identity, distinct from hers, federated from the same provider that vouches for her. This is not a technicality. It is what makes any of the rest possible. If the agent is simply running as Sarah, then narrowing what it may do means narrowing Sarah, and no organisation will accept a control that degrades a named employee’s access every time an automated process looks suspicious. Separate the identities and you can contract the agent to nothing at three in the morning without touching the person it works for.
It also answers the accountability question that comes up in every review. Sarah authorised a task. She did not authorise each of the four hundred operations the agent performed to complete it, and pretending she did — by running everything under her name — produces an audit trail that is technically accurate and practically useless.
What the agent actually gets, and where it comes from
Given that separation, the entitlement issued to the agent is not simply a copy of what Sarah is allowed to do. It is assembled by narrowing, three times over, before any of the safety analysis in the next section even begins.
Start with what the person could delegate. The capabilities statically permitted to the federated identity the request arrives with. This is the ceiling and it is the only part that looks like conventional access control.
Intersect with what this agent has actually used. Not what it was granted — what it has been observed to exercise. An agent issued eleven capabilities that has only ever needed three does not keep being handed eleven. This is the difference between a permission model that accumulates and one that settles toward what the work requires.
Intersect with the current threat picture. If a capability is implicated in an active threat entry, the contraction that entry specifies is applied here, at issuance — so the credential is never minted in a state that was already known to be unwise.
Then condition on what is actually being asked for. The same agent requesting the same capability against a public reference table and against a table of account records is not making the same request, and does not get the same answer.
What emerges is a candidate set that is usually a good deal smaller than the grant it descends from, and smaller for reasons a human reviewer would agree with if they had time to look at every request individually, which nobody does.
The floor that is checked separately
There is one more element, and it exists because of a failure mode that would otherwise be easy to miss. Each entitlement carries a minimum-safe floor — the set below which the agent cannot usefully function at all, the things it must have or there is no point issuing anything.
That floor is evaluated first, and independently of everything else. The reason is uncomfortable and worth stating: if the floor is itself unsafe — if the minimum an agent needs to do its job already assembles a route from sensitive data to somewhere it should not go — then no amount of trimming elsewhere fixes it, and a system that trimmed anyway would produce a credential stamped safe that is not. Checking the floor on its own means that case surfaces as a visible refusal rather than a false assurance. It is the failure mode where it would have been easiest to look good and be wrong.
Two labels per capability, and the routes they open
The mechanism starts with something unglamorous: every capability gets two labels. A source — how sensitive is what it can read into the agent's context — and a sink — what is the most sensitive thing allowed to flow out through it.
Four levels, ordered.
With labels in place the question stops being a matter of judgement and becomes a graph search. Is there a path from a high source to a low sink through the capabilities we are about to hand over? If yes, this credential should not be issued as requested.
Say no as little as possible
Any security system can refuse. Refusing is easy, and refusing imprecisely is the reason controls get switched off — the agent cannot finish, a human gets pulled in, and the automation you bought stops paying for itself. So the interesting engineering is not in detecting the path. It is in removing it while taking away as little as you can.
When a path exists, the system computes the minimum cut: the smallest set of capabilities to withhold such that no route remains.
The issued credential then carries a machine-checkable certificate asserting that this property was verified. A downstream service can check the certificate rather than trusting that somebody upstream did the analysis and got it right.
A note on honesty in the failure case. If the capabilities an agent genuinely requires themselves form an unsafe set — no threshold works — the system does not quietly issue a credential stamped safe. It issues the set the work genuinely requires, with the certificate stating plainly that the safety condition was not met, and the enforcement point blocks the offending action at the moment it is attempted. A false assurance is worse than a visible refusal, and this is the case where it would have been easiest to fake.
The credential is alive, not a receipt
Everything above happens at issuance. The second half deals with the more common situation: the credential was correct when it was minted, and then the world changed.
When a detector fires — a compiled, machine-readable threat model, not a person writing a rule at three in the morning — the live credential is mutated. There are three tiers, and the reason there are three rather than one is the entire argument.
Tasks finish under reduced authority instead of dying. The authority the agent should no longer hold is gone inside the same session — not at the next token refresh, not after a change ticket.
One detection, forty agents
The part that changes the arithmetic of a bad morning is what happens to everyone else.
A detection at one agent triggers pre-emptive contraction of the intersecting capabilities across sibling agents' live credentials. If the implicated capability is also held by eleven other agents, those eleven are narrowed too — without waiting for each to be attacked in turn, and without a central distributor whose failure takes the mechanism down with it.
“But it has already read the data”
This is the first objection anyone sensible raises, and it is a good one. Taking a permission away does not take away what the agent already saw. If it spent twenty minutes reading customer records before the detection fired, the records are in its working context. Removing the read capability now closes a door the agent has already walked through.
So the agent’s own sensitivity rises with what it handles. An agent that has read restricted material is treated as restricted for the remainder of that session — it can no longer write to somewhere less trusted, even if it still holds that permission, and even though holding it was perfectly legitimate five minutes earlier.
The safety question is therefore asked repeatedly rather than once. Not just “is this set of permissions safe to grant” at the start, but “is it still safe now that the agent knows what it knows” as the work proceeds.
Permissions describe what an agent may reach. After an hour of work, the more important question is what it is carrying.
It uses the identity you already have
Nothing described here asks you to replace your identity provider, and this matters more to most organisations than any of the mechanics.
The credential an agent carries is the ordinary kind your systems already accept, issued through the federation you already run, and verified downstream by services and payment rails exactly as any other credential from that provider would be. What changes is that it now also carries a statement about what the agent may safely do — something it did not carry before.
For anyone who has sat through an identity migration, the relevant sentence is short: this is an addition to the identity platform, not a move off it. No new login. No parallel directory. No eighteen-month programme with a steering committee.
When the agent is spending money
Agents that can transact are a category of their own, and the usual control does not fit them.
Per-transaction limits assume a human deciding one payment at a time. An agent works through a chain of actions in seconds, and ten payments of nine hundred is not meaningfully different from one payment of nine thousand — except that the first one passes a nine-hundred limit ten times.
The control that fits is a mandate with a ceiling that holds across the whole chain: no more than this much in pursuit of this task, whatever route the agent takes to get there. It can be issued when the agent forms an intention, or held back until the moment of confirmation, depending on how much you want to commit before you know the shape of the transaction.
Payments leaders tend to recognise this problem faster than anyone else in the room, because it is the same reasoning behind aggregate exposure limits on a trading desk. The novelty is only that the party being bounded is not a person.
Back to the bank
Take the same three requests, in the same order, with authority computed at issuance.
October, the third request
The workspace write capability is requested. The graph now contains a route from a restricted-classification source through to a sink shared with an external vendor. The credential is not issued as asked.
The minimum cut identifies that withholding write access to that one workspace removes the path — not the analytics read, not the other seven capabilities. The agent gets eight of nine and works normally. The one request that would have opened the route goes to a human with the reason attached, in the language of the finding rather than as a policy code.
January, a detection
A detector identifies a prompt-injection weakness in the summarisation service the agent calls, allowing an attacker to influence what it retrieves.
Under a second later the complaints agent's credential is contracted: summarisation gone, seven capabilities retained, current complaint completes without that step. The regulator-query agent holds the same capability and is contracted pre-emptively. The payments agent does not hold it and is not touched.
What the auditor gets
Every issuance, exercise, detection, contraction and immunisation lands in a hash-chained ledger anchored in a transparency log. The difference that matters at board level is not technical: in the first version the bank hears about the exposure from an auditor months later and cannot say what the agent did with the access in between. In the second, the route never opens — and had it opened, the record is verifiable rather than reconstructed from logs that might themselves have been edited.
The gap in every AI governance programme
Most organisations now have an AI governance function of some kind, and most of them have built the same thing: an inventory of models. Which models are in use, who owns them, what data they were trained on, what they are approved for, how they are monitored for drift and bias. That work is necessary and it is genuinely hard, and the regimes now arriving — the EU AI Act being the one with teeth — are largely satisfied by it.
It answers questions about the model. It answers almost nothing about the agent.
A model is a thing that produces output. An agent is a model wired to capabilities, and the risk moved with the wiring. Knowing that a model is accurate, unbiased and approved for customer correspondence tells you nothing about whether the agent built on it can read the customer database and write to a vendor's shared drive. Those are different questions, and only one of them is usually on the register.
The practical test. Ask your AI governance lead for the model inventory and you will get it, probably within the hour. Ask for the same list showing what each of those systems is permitted to do — not what it was approved for, what it can actually reach today — and the answer is usually that the question belongs to identity. Ask identity and the answer is that it belongs to whoever requested the access. It is nobody's list, and that is structural rather than anyone's failing.
This matters commercially and not only defensively. Governance regimes increasingly require organisations to demonstrate meaningful control over automated decision-making, and to keep records adequate to reconstruct what a system did and why. An inventory of models plus application logs is a weak answer to that. A verifiable record of what each agent was permitted to do, when that changed, and what it actually exercised is a strong one — and it happens to be a by-product of running the control rather than a separate compliance exercise.
What it is worth, and to whom
| Who | The question they cannot answer today |
|---|---|
| CISO | What can our agents do in combination, and who decided that? |
| Head of Data | Can anything automated reach customer data and also reach outside? |
| Compliance | Can we produce evidence a third party has reason to believe, rather than logs we assert are accurate? |
| Platform lead | When a capability is found weak, how long until every agent holding it is contained? |
| AI governance | We have an inventory of models. Where is the inventory of what those models are permitted to do? |
| CFO | Why did three agent projects stall in security review for two quarters? |
That last one is the quiet cost. The usual pattern is that agent projects reach the security gate and stop, and the compromise reached is to narrow the agent until it is no longer worth running. Computing the largest safe authority rather than the smallest defensible one changes the shape of that conversation, and graduated response changes it again — security teams will accept a control that degrades a process far sooner than one that halts it.
Four things it does not do
A control described only by what it prevents is being sold to you. These are the limits we would want to know about if we were buying it.
It will not classify your data
Source and sink labels have to be curated per capability. Uncurated means fail-closed, which is correct and also means an organisation with no data classification will find the system very restrictive until that work is done. That work is real, it is yours, and nobody can do it for you.
It does not detect threats
It responds to detections. The quality of the response is bounded entirely by the quality of the detector set feeding it. A weak detector set means late contraction; a noisy one means agents losing capabilities they should have kept.
It does not replace your identity provider
It issues standards-compliant credentials — OAuth, OpenID Connect, workload identity attestations — alongside your existing federation. What changes is that the credential now carries a verified property it did not carry before.
Contraction can interrupt legitimate work
An agent mid-task that loses a capability may not finish as intended. Graduated tiers make this survivable, but there is a genuine trade-off between containment speed and task completion, and where you set it is a business decision rather than a technical default.
The question you can ask this week
It costs nothing and needs no product: list every capability held by every agent you run, and look for a path from anything sensitive to anything shared outside.
Most organisations doing this for the first time find at least one. Not through carelessness — through structure. No approval decision was ever asked about the set, and the set is where the risk lives.