Ask a security team how many employees have access to production. They will give you a number, and it will be roughly right.
Ask how many agents, scripts, and service accounts do. The pause before the answer is the entire problem.
An agent is neither a user nor a service account
Identity systems were built around two assumptions, and agents break both.
A human identity has a person attached. There is a manager, a laptop, a joining date, and — critically — a leaving date that triggers deprovisioning. When someone changes role, an access review catches the permissions they no longer need. The whole apparatus depends on a human lifecycle.
A service account is the other model: a fixed credential doing a predictable thing on a schedule. It runs the same query every night. If it suddenly reads a different table, that is an anomaly worth investigating.
An agent is neither. It has no lifecycle event to hang deprovisioning off, and its behaviour is not predictable by design — the entire point is that it decides what to do. The anomaly detection that works for service accounts produces constant false positives against something whose normal state is doing something new.
Fig. — The two control models identity systems were built on. Agents fit neither.
The three failures showing up in practice
Over-scoped credentials, almost universally. An agent needs to read from six systems, so it gets a key with broad access to all six, because scoping it properly would mean six conversations with six owners. That key is now the most valuable credential in the estate, and it lives somewhere a prompt-injected agent could be persuaded to use it.
No revocation path. When a human leaves, HR triggers offboarding. When a team stops using an agent, nothing triggers anything. The credential stays valid indefinitely, attached to a workload nobody is monitoring, referenced in a config file whose author has moved on.
Attribution collapse. An agent acting on a user's behalf usually authenticates as itself, so the audit log records the agent — not the person whose request set it in motion. When something goes wrong, you can see what happened and not why or for whom. In a regulated environment that is not an inconvenience; it is a finding.
The injection problem underneath all of it
There is a failure mode with no clean equivalent in traditional security, and it is worth stating plainly.
An agent that reads untrusted content — an email, a support ticket, a web page, a document a customer uploaded — can be instructed by that content. The instruction arrives as data and gets treated as intent. An attacker does not need to compromise your agent's credentials; they need only put text somewhere the agent will read.
This is why permission scoping matters more here than in conventional systems. You cannot fully prevent an agent being manipulated. You can ensure that a manipulated agent has nothing valuable to reach.
The practical consequence: assume every agent that touches external content will eventually do something it was told to do by an attacker, and design the blast radius accordingly.
What good looks like
One identity per agent, per environment. Shared credentials across several agents destroy attribution the moment you need it, which is always during an incident.
Scopes narrow enough to be uncomfortable. If an agent reconciles invoices, it reads invoices and writes reconciliation records. It does not need customer PII, and the fact that granting it is easier is not a reason.
Short-lived credentials over static keys. An agent that fetches a token valid for fifteen minutes is a categorically smaller problem than one holding a key valid until somebody rotates it, which is to say for years.
An expiry on every agent identity. Not a review reminder — an actual expiry that stops it working. Renewal should require someone to confirm it is still needed. This single control eliminates the abandoned-agent problem, which is otherwise unsolvable because nobody notices absence.
And delegated identity where it exists: the agent acting for a specific user should carry that user's context into the audit trail, so the log answers who as well as what.
Why the tooling has not caught up
It is worth understanding why this is hard rather than assuming your vendors are simply behind.
Identity platforms are built around directories of people. The data model has a person at the centre, with attributes like department and manager, and the governance features — access reviews, certification campaigns, segregation of duties — all assume a human is answering a question about another human. Bolting agents into that model produces awkward results: an access review that asks a manager to certify whether a piece of software still needs a permission they do not understand.
Cloud providers have the machine-identity primitives — workload identity federation, short-lived tokens, per-workload roles — and they are genuinely good. The gap is that they operate at the infrastructure layer, while the agent's actual behaviour happens at the application layer. Your cloud provider can tell you a workload assumed a role. It cannot tell you the agent then read four hundred customer records because a support ticket told it to.
That gap is where the current generation of tooling sits, and it is early. In the meantime the controls that work are the unglamorous ones: narrow scopes, short credentials, hard expiries, and someone whose name is on it.
Where to start
Inventory first, and expect the number to be wrong. Most organisations discover agents and integrations nobody remembers commissioning, holding credentials nobody can justify. That discovery is uncomfortable and it is the point of the exercise.
For each one, ask three questions. What can this reach? What would it cost us if this were fully compromised tomorrow? Who owns it, by name?
The third question is the one that fails most often, and an agent without a named owner is the one that will still be running with production access in two years.
Then fix the worst blast radius first. Not the most agents, not the easiest — the single credential whose compromise would hurt most. Scope it down, put an expiry on it, and confirm the audit trail actually records what it does.
This is not a new discipline so much as an old one applied to a population that grew faster than anyone's process. The organisations handling it well are not the ones with the best tooling. They are the ones who started counting before they had a reason to.
