What makes an AI agent dangerous: the tools, not the model?
The risk in an AI agent comes from its tools, not from the model: a chatbot that only talks can embarrass you, but an agent that updates records, sends emails, moves money or runs code can hurt you. Every prompt-injection story with real damage involves an agent with tools it did not need and no one checking what it did. So the controls below are about the tools — what the agent can reach, what it can do irreversibly, and who sees it. OWASP names this class of failure directly: "excessive agency" is a Top 10 entry in its own right, and prompt injection — the way an attacker gets the agent to misuse its tools — sits at number one (OWASP, 2025).
What are the seven controls?
The seven controls are least-privilege tools, authorisation enforced in the data layer, instructions separated from data, human approval for irreversible actions, sandboxed execution, budgets with loop detection, and full tracing with an attack suite. None is exotic; together they limit what a compromised or confused agent can achieve and make sure someone sees it when it tries. They are the same principles NIST's AI Risk Management Framework groups under "manage" — least privilege, human oversight and monitoring of deployed systems (NIST, 2023).
- 1. Least-privilege tools. Each tool does one narrow thing with a scoped credential: "read this customer's orders", not "SQL access to the orders DB". The agent never holds admin keys.
- 2. Authorisation at the data layer. The user's permissions are enforced inside the tool and the retrieval query — not by asking the model to be careful.
- 3. Instructions separated from data. Retrieved documents, tool outputs and user messages are labelled as data; the model is told, and the tests check, that instructions inside them are ignored.
- 4. Human approval for irreversible actions. Sending external email, payments, deletions, contract changes: the agent proposes, a person confirms — with the full context of what will happen.
- 5. Sandboxed execution. Code, shell and browsing tools run in an isolated environment with no network to internal systems, a time limit and a budget.
- 6. Budgets and loop detection. Tokens, tool calls and cost capped per run and per user; repeated identical calls stop the run and page someone.
- 7. Full tracing and an evaluation suite. Every prompt, tool call, output and cost is logged; an attack suite runs on every prompt, model or tool change, alongside the quality evals.
Which control stops which attack?
Each control answers a specific way an agent goes wrong, and the table maps them. Prompt injection is the entry point for most of the rows, which is why no single control is enough: the injection itself cannot be fully prevented, so the controls limit what a successful injection can achieve. The rightmost column is the OWASP LLM Top 10 entry each control addresses (OWASP, 2025).
| Control | Threat it limits | OWASP LLM Top 10 entry |
|---|---|---|
| Least-privilege tools | Agent reaches data or actions the task never needed | LLM06 Excessive agency |
| Authorisation in the data layer | One user sees another user's or tenant's records | LLM02 Sensitive information disclosure, LLM08 Vector weaknesses |
| Instructions separated from data | Poisoned document or email steers the agent | LLM01 Prompt injection |
| Human approval for irreversible actions | Wrong payment, deletion or outbound message | LLM06 Excessive agency |
| Sandboxed execution | Generated code reaches internal network or host | LLM05 Improper output handling |
| Budgets and loop detection | Runaway cost, recursive tool loops | LLM10 Unbounded consumption |
| Tracing and attack suite | Regressions nobody notices until a customer does | All: detection and evidence |
How do these controls fit into the agent architecture?
The controls map onto the six layers described in How AI agents work: perception and memory get the data controls, tools and orchestration get the permission and approval controls, reflection and monitoring get tracing and the attack suite. Put another way, security is not a layer bolted on at the end — each architectural layer owns one or two of the seven. All of it is skipped when a team ships a demo to production, and the cost of that gap is measurable: IBM found organisations with extensive use of security AI and automation identified and contained breaches faster and at lower cost than those without (IBM, 2024). MITRE ATLAS is a useful public catalogue of the adversarial techniques the attack suite should cover (MITRE, 2024).
Who should review an agent, and when?
Any agent with write access to a business system should be reviewed against these controls before launch and after every change to its tools, and an outside review is worth it once the agent touches customers, money or personal data. Internal teams reliably underestimate two things: how much an injected instruction can chain through the tools they granted, and how quietly a model update changes behaviour. Regulation is moving the same way — the EU AI Act (Regulation 2024/1689) requires risk management, logging and human oversight for high-risk AI systems (EU, 2024). When you want an outside pair of eyes on an agent before or after launch, that is our AI & LLM security assessment.