Your AI agents have no identity, they have your keys

By stopping giving it one. A useful agent does not act in its own name, it acts on behalf of the person asking, with that person’s rights, and for that task only. Almost every deployment does the opposite, handing the agent a service account with broad rights, which amounts to creating a path that bypasses all of your permissions.

The scale of the subject is already measurable. Non-human identities outnumber human ones by roughly 45 to 1 in an average enterprise, that population having grown from around 50,000 in 2021 to 250,000 in 2025, and 92% of organisations say their access management tools cannot handle agent identities. The figure that should hold your attention is the last one, not the first.

Why a service account is the wrong answer

Because it expresses fixed rights, and an agent has no fixed rights.

A service account was invented for a program that always does the same thing: a nightly backup reaches the same folders, at the same hour, for the same reason. Its scope is known in advance, declared once, and depends on nobody. That shape fits perfectly what it describes.

An agent is the exact opposite. The same instance serves a salesperson in the morning and a director in the afternoon, on files those two people do not have equal access to, sometimes through chains where the agent calls another that calls a tool. The legitimate scope changes with every request, and it depends on who is speaking. No service account can express that, which explains why the chosen solution is almost always to take the maximum and rely on instructions to restrain the rest.

That is precisely the reasoning we refuse everywhere else. A restriction written in plain language is worked around by another sentence in plain language, and only a limit written into the product holds. An over-privileged agent politely asked not to overstep is still an over-privileged agent.

The two-user test

It takes five minutes and requires no technical access, which makes it the best verification tool I know on this subject.

Have exactly the same request made by two people whose rights differ sharply, a junior salesperson and a member of the executive committee for instance. Ask for something one is entitled to see and the other is not: the margins on an account, the compensation of a team, a sensitive client file.

If both get the same answer, the agent did not delegate. It read with its own rights, and you have just discovered that your permission model contains a back door nobody decided to open. If the answers differ, and especially if the person with restricted rights is told they lack access rather than receiving an empty reply, the agent is delegating correctly.

That test has a further virtue, which is that it can be run in front of the vendor during an evaluation. Unlike most security questions, this one is observable on screen and cannot be settled with a reassuring answer, which puts it on the short list of things a demo can actually establish.

What is new about this, and what is not

None of it is a discovery of 2026, and that deserves acknowledging before anyone declares a crisis. Over-broad service accounts, keys lying about in environment variables and secrets never revoked are twenty-year-old operational problems, documented, with known remedies.

What is new comes down to two points. The first is volume: a population of identities that quintuples in four years outruns any team’s capacity to keep it current, and a 2026 analysis finds that more than 16% of organisations do not even track the creation of AI-related identities. The second is the speed of exploitation, since measurements from the same period put about seventeen minutes between a key being exposed and its use by a third party, while close to a quarter of organisations take more than twenty-four hours to revoke one. A gap of that order turns negligence into a certain incident.

The third point, absent from the studies, is the one that worries me most. An agent reads content it did not produce, and that content can carry instructions, exactly as a CV can. An over-privileged agent therefore turns every text it ingests into potential leverage over all of your systems, which was never true of a service account running a backup.

What we chose, and what it cost us

We took the position that scope is resolved at the edge, on the way in, once, and that the question of whose behalf this is on gets answered in one place in the code rather than in every function that queries a database.

That choice carries a real cost I would rather describe, because it is the reason many teams take the other road. It forces you to propagate the requester’s context everywhere, including into asynchronous tasks and scheduled jobs where nobody is in front of a screen, and it slows the addition of any new data source. An integration that would take a day with a single key takes three.

What it buys in exchange amply justifies the difference. Revoking access in the source system immediately deprives the agent of it, with no action needed on our side. The log records whose behalf each action was taken on, which makes an investigation possible. And above all, no leak can exceed the rights of the person who made the request, which bounds the worst case to something known.

And when nobody asked for anything?

Here is the case the delegation model does not cover, and I have no fully satisfying answer to offer. A proactive agent wakes at eight on Monday to prepare a review, or notices that an assignment ends in three weeks. At that moment it is acting on nobody’s behalf, since nobody asked.

The lazy solution is to run those tasks under a technical account with broad rights, which reintroduces the exact problem through the back door, and at the worst moment since nobody is watching. The solution we settled on is to attach every scheduled run to the person who set it up, whose rights at execution time govern. A weekly review configured by a branch director runs with that director’s rights, and it stops working the day they leave the company.

That last consequence is unpleasant and I consider it a feature. An automated task that outlives its requester is a task nobody owns any more, and experience shows it keeps running for years producing output nobody reads. Letting it fall over forces somebody to pick it up explicitly, and therefore to know it exists.

One blind spot remains, and I own it: someone leaving with well-configured scheduled tasks takes service away with them, and the team finds out the following Monday rather than on their last day. We warn beforehand, which is a patch rather than a solution.

What to require from a vendor

Three requirements, all verifiable, and none of them asks you to trust a statement.

That the agent acts with the requester’s rights rather than its own, which the two-user test establishes in five minutes. That every action is logged with the name of the person it was performed on behalf of, and not merely a timestamp and the tool called. That revoking an access in the source system propagates immediately, which you check by cutting an access and asking the question again.

Those three points also form the right level of granularity for a governance policy, since they describe the scope of access rather than the ability to act, and it is the confusion between those two notions that Gartner names as the leading cause of agents being pulled from production.

Which leaves the case where the agent does not call your systems directly but goes through a third-party server, which then holds its own credentials and becomes one more link in the chain. That is a different discipline, and it belongs to procurement as much as to engineering: an MCP server is a supplier.