API Security When the Caller Is an AI Agent
Authentication was the part the industry solved. Agents break everything downstream of it — what the caller intends, how far its credential reaches, and how much it can destroy before anyone notices.
The agent calling your API at three in the morning is authenticated. It holds a valid credential you issued, and every check you have written passes. That is the problem, not the exception.
Authentication was the part the industry solved. What agents break is everything downstream of it: what the caller is trying to do, how far its credential reaches, and how much it can destroy before anyone notices. Identity, intent, scope, blast radius. You have probably closed the first one. The other three are where the work is now.
Two framings are doing the rounds and both are wrong. One says an agent is just another API client, so the existing controls carry over. The other says agents demand an entirely new security stack, which in practice means buying one. The useful position is narrower: agents do not introduce a new class of vulnerability. They industrialise the ones you already have. Broken object-level authorisation is API1 in both editions of the OWASP API Security Top 10 — (opens in a new tab) and (opens in a new tab) — the endpoint that hands back the wrong record if you ask for it directly. A person stumbles into that by accident. A goal-seeking system finds it by enumeration, at machine speed, because trying every reachable object is a perfectly reasonable way to get closer to an objective.
An agent identity is a key cut for one door and one hour
The most common failure is also the cheapest to fix: agents wearing a person’s credentials. Someone wires an assistant to act “as the user”, it inherits everything that user can reach, and the audit log records a human doing it. You now have an autonomous system holding the standing access of a senior employee, and no way to tell its actions from theirs after the fact.
What you want instead is a credential cut for one door and one hour: a scope naming the specific endpoints and objects the task needs, and an expiry measured against how long the task actually takes rather than how long the session lasts. Those two properties are what separate an agent identity from a borrowed one, and a token that outlives its task has quietly become a master key with a job title — it still passes every check, and it now opens things nobody scoped it for.
Which gives you the test I would put in front of a board: if that credential leaked tonight, what is the worst a single stolen token does before it expires? If the answer is “whatever the user could do, indefinitely”, you have not issued an agent identity. You have lent one.
Scope to the task, not the role
Human access is role-shaped — you are in finance, so you can see finance things. That is already blunt. For agents it is actively dangerous, because an agent does not need standing access at all. It needs to do one thing and then stop being able to.
An agent processing refunds gets a credential that reads order history and issues refunds below a set threshold. That is the entire universe it can touch. Not payroll, not deletes, not the three endpoints that happened to be on the same host. When the task ends, the scope ends.
Rate limits stop being a noisy-neighbour nicety here and become a control that does real work. A person clicks an endpoint a few times a minute. A loop calls it as fast as the network allows, and it does not get bored, get tired, or grow suspicious of itself.
Set that ceiling from what the task should need — the calls one completed run requires, plus headroom for retries — rather than from what you have already seen, because a limit derived from a runaway is a limit calibrated to the accident. Then review it against real traffic, and wait for enough of it to mean something: a few hundred completed runs, not a few. Below that you are tuning against noise, and the honest position is that the normal shape is task-specific enough that you have to measure your own rather than borrow a published one.
Sort actions by reversibility, then gate the ones you can’t undo
This is the control teams most want to skip, because a human checkpoint feels like it defeats the point of automation. It does not. It draws a line, and the line is reversibility.
Reading data, drafting a message, flagging a record for review — reversible, small blast radius, let it run. Issuing a payment, deleting customer data, changing a permission, sending something to a customer that cannot be unsent — irreversible, and every one of those is a call you would want a name against. The agent works right up to the gate, presents what it is about to do, and waits.
The threshold has to live in the system rather than in a policy document nobody opens. Below it, act. Above it, ask. Start the gate tight and widen the autonomous lane on measured behaviour, not on optimism. Designing for full autonomy on day one is not ambition. It is choosing to find out at scale that your agent will do the wrong thing with complete confidence.
You cannot reconstruct what you never tied together
Observability is the piece that quietly decides whether any of the above is real. When an agent makes a hundred calls to finish one task, you need to know what it did, in what order, with what data.
That means logging at the granularity of the agent’s decisions rather than the HTTP requests: which agent, which task, which credential, what it asked for, what came back, what it did next. Tie the calls into one trace per run.
The question you get asked during an incident is “what exactly did it touch?”, and the gap between answering in minutes and answering in days is whether those calls were correlated before anyone needed them to be. Anomaly detection matters too, and agent behaviour needs its own baseline — the traffic pattern that would page you for a human user is an ordinary Tuesday for an agent working through a queue.
Where to start
You do not need to re-secure the estate. Start where the surface is smallest and the stakes are highest: the irreversible actions. Payments, deletions, permission changes, anything customer-visible. Put explicit gates and per-agent scopes around those, give every agent its own short-lived identity, instrument the calls so a run reads as one trace, and tighten outward from there.
The full control map — identity, task scoping, reversibility gates, observability — is laid out in the Agentic API Security insight.
Authentication answers who is calling. It has never answered what the caller is about to do, and it is not going to start now that the caller is a program with an objective, a credential, and no reason to stop.