Securing AI agents
When AI can take actions, a successful attack becomes a real-world incident. This module shows how to give agents power safely.
Learning objectives
- Explain why agents increase security risk
- Identify the three causes of excessive agency
- Recognise the dangerous combination of data, untrusted content and external communication
- Apply controls for agents and tools
- Manage risks from MCP servers and browser agents
5.1 Why agents raise the stakes
An agent combines an LLM with tools (search, email, files, code execution, APIs, browsers) and the autonomy to decide which to use, in a loop. That's what makes agents useful — and why a successful prompt injection against an agent can lead to real actions: data exfiltration, unauthorised payments, deleted files or changed configurations.
5.2 Excessive agency (OWASP LLM06)
OWASP identifies three root causes:
| Cause | Example | Fix |
|---|---|---|
| Excessive functionality | An agent that only needs to read emails is given a tool that can also send and delete | Give only the tools the task needs |
| Excessive permissions | A tool connects to the database with an admin account | Least-privilege, scoped credentials — ideally acting with the user's own permissions |
| Excessive autonomy | High-impact actions run without confirmation | Human approval for consequential or irreversible actions |
5.3 The dangerous combination
Security practitioners warn about agents that combine three capabilities:
- access to private or sensitive data;
- exposure to untrusted content that could contain injected instructions; and
- the ability to communicate externally (send emails, make web requests, write to shared locations).
Together, these let an attacker's hidden instructions read your data and send it out. If an agent needs all three, add strong controls — or redesign so that no single agent has all of them at once.
5.4 Controls for agents
- Least privilege for every tool and credential; short-lived, scoped tokens
- Human-in-the-loop approval for sending, paying, deleting, sharing or changing permissions
- Sandboxing — run code and browsing in isolated environments
- Allow-lists for domains, recipients and actions
- Separation — split tasks across agents with different privileges; a "reader" agent that sees untrusted content shouldn't hold powerful tools
- Logging and audit of every tool call and decision
- Limits on steps, spend and time; kill switch
- Identity — agents act as identifiable principals, not anonymous super-users
5.5 Tools, plugins and the Model Context Protocol
Protocols such as the open Model Context Protocol (MCP) make it easy to connect AI models to tools and data. They also add supply-chain and injection risks:
- A malicious or compromised tool server can return injected instructions or steal data passed to it.
- Tool descriptions themselves are read by the model and can contain hidden instructions ("tool poisoning").
- A tool's behaviour can change after you've approved it.
Treat tool servers like any third-party software: use trusted sources, review permissions, pin versions, monitor behaviour and remove what you don't need.
5.6 Computer-use and browser agents
Agents that operate a browser or desktop face the largest attack surface — every web page, document and advert is potential input. Use dedicated, low-privilege browser profiles; restrict sites; require confirmation for purchases, form submissions and downloads; and watch what the agent does.
A team proposes one agent that reads all incoming customer emails (untrusted), has full access to the customer database (sensitive), and can send emails and issue refunds (external actions). Redesign it to reduce risk.
Show one possible design
Agent A (no database or send rights) classifies and summarises emails. Agent B looks up only the specific customer's record, with read-only, scoped access. Drafts go to a human queue; refunds over a small threshold need human approval; outbound email only to the original sender's verified address; all tool calls logged; rate and spend limits applied.
Key takeaways
- Agents turn manipulated outputs into actions.
- Excessive functionality, permissions and autonomy cause excessive agency.
- Avoid combining private data, untrusted content and external communication in one agent.
- Least privilege, approval, sandboxing, allow-lists, separation, logging and limits.
- Treat tool servers as third-party software.