An agent calling your API is a client like any other, and the mistake teams make is giving it a credential that sees everything because the agent might need anything. That converts a prompt injection or a logic error into access to all your customer data. Broken function level authorisation is already in the OWASP API Security Top 10, and agent integrations are an efficient way of introducing it.
Delegate the user’s permissions, not a service account
The agent should act with the permissions of the person it is helping, not with a service identity that spans every customer. That means passing a token scoped to the user through to your API and enforcing authorisation there, exactly as you would for a browser session. Where the agent performs background work with no user present, give it a narrow identity for that specific task rather than reusing the interactive one. This single decision determines how bad an agent compromise becomes.
Tool definitions are an attack surface
The functions you expose to an agent describe your system in machine-readable form, including parameter names and behaviour. Assume anything reachable will be called with unexpected arguments, since the agent generates those arguments from text a user controls. Validate every parameter as untrusted input, apply the same authorisation checks you would for a public endpoint, and be careful with tools that accept a free-form query or a file path. A tool that runs a search across all records is a data exfiltration channel with a friendly name.
“Put the write operations behind a confirmation step. Reading data with the wrong scope is a bad day, and an agent that can issue refunds, change bank details or delete records without a human approving the action is a genuinely bad quarter. Start read-only, add write operations one at a time, and log every one with the identity that requested it.”
William Fieldhouse, Director, Aardwolf Security Ltd
Cost, rate limits and abuse
Agents retry. A loop that a person would abandon after two attempts can run hundreds of times in a minute, which turns a rate limiting weakness into an availability incident or a bill. Apply limits per user rather than per agent identity, since the agent is a single caller acting for many people, and put a ceiling on the work any one request can trigger. Watch for patterns that indicate an agent has been talked into enumerating data, such as many sequential record requests from one session.
Testing the integration
Test the API as an agent would call it, and then as an attacker who controls what the agent is told. That means checking whether the caller can reach functions outside its scope, whether authorisation is enforced at the endpoint rather than in the prompt, and whether the audit trail attributes actions to the right person. API penetration testing for AI integrations covers both angles, and if you are adding agent access to a system that already holds customer data, talk to us about testing an AI integration before it goes live rather than after the first support ticket.
Frequently asked questions about agent access
These questions come up when an assistant is connected to a production system.
Should agents have their own accounts?
Yes, distinct from any human account, so actions are attributable and access can be revoked without affecting a person. Treat each agent as a machine identity with an owner, a scope and a review date.
Is prompt filtering a security control?
It reduces noise and it is not a boundary. Anything you rely on must be enforced in the API, because the prompt is influenced by input you do not control and the model is not an access control system.
