Every security team I know has a plan for hostile traffic hitting its APIs. Rate limits, scoped tokens, anomaly detection, the works. The plan usually assumes the hostile caller is outside the building.
The caller I worry about is already inside, authenticated, and doing exactly what it was told. It is an AI agent, and from your API's point of view, a misbehaving agent and an abusive one look exactly the same.
I build back-end services and production AI agents at Amazon Advertising. The agents I run call tools and APIs to do real work: reading advertiser analytics, assembling answers, and acting on what they find. Running them taught me that tool-call abuse is not only an attacker's technique. It is also what a normal agent does on a bad day, at machine speed, with valid credentials.
The abuse patterns are built in
Start with retries. A tool call times out, and the agent cannot tell whether the action happened. So it calls again. A write that was merely slow becomes a write that happened twice. Attackers call that replay. Your agent calls it being helpful.
Then there is fan-out. One user question becomes a plan, the plan becomes dozens of tool calls, and each call retrieves generously, because a wider net feels safer to the model. Multiply that by every user asking at once and you have a load pattern no capacity review predicted, generated entirely by authorized callers.
Finally, there is scope creep in the literal sense. An agent with a broad token will use it. Give a tool permission to read every table and the agent will read tables its task never needed, because nothing in its instructions told it those tables were special. The credential was the control, and the credential said yes.
Defend the interface, not the intent
You cannot secure this by inspecting the agent's intentions. You secure it the way you secure any powerful client: at the interface.
Give each agent workflow its own identity and a token scoped to the tools and data that workflow needs. A summarizing workflow has no business holding a write token, and a workflow that writes has no business reading the whole warehouse.
Make write tools idempotent. Carry a key with each request, store the result, and when the same key arrives again, return the stored result instead of acting a second time. Properly implemented, this prevents repeated requests from triggering the same write more than once.
It also reduces the risk of duplicate actions caused by both legitimate retries and certain replay attempts.
Monitor agent activity and enforce limits
Log tool calls the way you log privileged user actions: which agent, which workflow, what it read, what it changed, and under whose request. When something goes wrong, and something will, the investigation should take hours, not archaeology.
Set budgets. A per-task ceiling on calls and on data volume converts runaway behavior from an incident into a stopped task with a clear error. Agents understand budgets about as well as junior engineers do, which is to say the budget has to be enforced by the system, not requested in a prompt.
Those limits should be enforced by the API gateway, tool execution layer, or another trusted service, rather than relying on the agent to stop itself.
None of this slows a well-behaved agent down. All of it draws a hard line between an agent doing its job and an agent, or someone steering it, doing damage with your own credentials. That line is exactly where API defense has always belonged.
Want to get better results from AI? eSecurity Planet readers can enjoy free seven-day access to The Neuron Academy, a practical learning platform packed with AI tips, tricks, and prompting techniques. Start with our free six-minute course, How to Talk to AI, to learn simple ways to write better prompts and get more useful responses, then explore more lessons to build your AI skills and confidence at work.