An AI agent is a language model that has been given tools and permission to use them without asking each time. Instead of only producing text, it can browse, query databases, call APIs, run code and act in sequence toward a goal. This is where the industry is heading, and it is also where the security problems stop being theoretical, because an agent that is fooled does not just say the wrong thing. It does the wrong thing.
Why Agents Concentrate Risk
Every weakness a plain model has, the agent inherits, and then adds consequence to it. Prompt injection in a chatbot leaks words; prompt injection in an agent triggers actions. The model’s inability to separate instructions from data now sits behind a set of real capabilities, so a sentence hidden in a document the agent reads can become an API call the agent makes. The gap between fooling the model and causing harm, which is wide for a text-only system, closes to nothing for an agent.
Worse, agents chain steps. An injected instruction early in a task can steer everything that follows, and because the agent is acting autonomously, there may be no human watching any individual step. The failure is not one bad action but a sequence of them, executed faster than anyone can intervene.
Design for the Assumption of Compromise
The productive way to secure an agent is to assume the model will, at some point, be successfully manipulated, and to arrange things so that this is survivable. You are not trying to build a model that cannot be fooled, because you cannot. You are building a system in which a fooled model cannot do much harm.
- Scope the tools tightly. An agent should hold the minimum set of capabilities its task genuinely requires, with credentials scoped to match. Most agents are given far broader access than their job needs, out of convenience.
- Put a human at the point of consequence. Reading is low risk; acting is not. Any action that spends money, sends a message, deletes data or changes a record should pause for human confirmation, however much that dents the demo.
- Enforce limits outside the model. Rate limits, spending caps and allowlists must live in the surrounding system, not in the prompt. A limit the model is merely asked to respect is not a limit, because the model can be talked out of it.
- Isolate execution. If the agent runs code or browses, do it in a sandbox with no access to secrets, internal networks or anything it does not need. Assume whatever it runs may be attacker-controlled.
- Log every action for review. You want a complete, human-readable trail of what the agent did and why, both to catch abuse and to reconstruct it afterwards.
The Confused Deputy, Again
Security has seen this shape before. An agent acting with its own broad privileges on behalf of a user who cannot be fully trusted, reading content that cannot be trusted at all, is a classic confused-deputy problem in new clothing. The old lesson applies: the deputy’s authority should be no greater than the least-trusted input it handles. An agent that reads the public internet should not also hold the keys to your production database in the same context.
Testing an Agent
When you assess one, trace every tool it can reach and every source of untrusted text, then ask what the worst chain of actions is that a single injected instruction could set off before a human or a hard limit stops it. That worst-case chain, not the model’s politeness, is the finding that matters.
The Short Version
Agents turn the model’s weaknesses into actions, and chain those actions faster than anyone can watch. Secure them by assuming the model will be fooled and making that survivable: minimal tools and credentials, a human at every point of real consequence, hard limits enforced outside the model, sandboxed execution and complete logging. The goal is not an unfoolable model but a system where a fooled one cannot do much.