An AI agent that can browse, call APIs, run code and move data is enormously useful — and a brand-new attack surface. The moment it ingests attacker-controlled input, it can be turned against you. This guide gives seven practical rules for securing an AI agent, drawn from how we actually attack them.
Why agents are different
A chatbot answers questions; an agent takes actions. That autonomy means a single successful prompt injection no longer just produces bad text — it can trigger real operations: sending emails, calling internal APIs, deleting records. Security must assume the model will be manipulated and contain the blast radius.
Seven rules
- Never make the model the security boundary. Enforce authorisation in your own code, before any tool runs. The model decides what to attempt; your code decides what is allowed.
- Least-privilege tools. Give the agent the narrowest possible capabilities and scopes. If it only needs to read calendars, it must not be able to send email.
- Human-in-the-loop for sensitive actions. Require explicit approval for anything irreversible or high-impact — payments, deletions, external messages.
- Treat all ingested content as hostile. Web pages, documents and tool outputs can carry indirect injection. Label and isolate untrusted content; never let it silently become instructions.
- Sandbox code and tool execution. Run any code the agent produces in an isolated environment with no standing credentials or network access to sensitive internals.
- Constrain and validate outputs. Don’t pass model output straight into a shell, a database query or HTML. The same encoding and validation you’d apply to any untrusted input applies here.
- Log, monitor and rate-limit. Record every tool call and decision so you can detect abuse and reconstruct incidents, and cap how much damage a runaway loop can do.
The threat model to design against
Assume an attacker can plant text anywhere your agent reads, and can attempt to chain tools toward a goal you never intended — data exfiltration, privilege escalation, sandbox escape. Designing for that assumption is exactly what agentic AI threat modeling does at the architecture stage, before code is written.
How we test for it
We attack the agent the way a real adversary would: injecting instructions through every input channel, abusing tools, attempting goal-hijacking and sandbox escape, and probing where authorisation is (wrongly) delegated to the model. That is AI agent penetration testing, complemented by MCP server & tool-chain testing where agents use external tools.
Frequently asked questions
Isn’t a strong system prompt enough? No. Prompt instructions can be overridden; real containment is code-level authorisation and least-privilege tools.
Where do most agent breaches start? Indirect prompt injection through ingested content — see prompt injection explained.
Deploying an autonomous agent? Explore AI agent penetration testing or get a fixed-price quote.