Guide

Keeping AI agents safe: prompt injection, untrusted content & human approval

The moment an agent can read your inbox or browse the web and take actions, anything it reads becomes a possible instruction. This page covers what prompt injection is, why it matters for tool-using bots, and the practical guardrails that limit the damage.

1. What prompt injection is

OWASP lists prompt injection as the first risk (LLM01) in its Top 10 for LLM applications. It separates two kinds:

• Direct — someone types instructions into the prompt that change the model’s behavior.
• Indirect — the instructions arrive inside external content the model processes: a web page, a file, an email, a code comment, an issue description.

Indirect injection is the one that matters most for agents. OWASP notes the injected text doesn’t even have to be visible to a human — it only has to be parsed by the model. Examples from the OWASP cheat sheet include hidden text in web pages, documents, and emails, plus instructions in commit messages and merge request descriptions.

2. Why agents can’t just “ignore bad instructions”

Simon Willison, who coined the term, puts the core problem simply: LLMs follow instructions in content, and they can’t reliably tell your instructions apart from ones that arrived in an email or web page — everything ends up in the same stream of tokens. You can tell the model not to obey embedded instructions, and that may reduce the odds, but it isn’t a guarantee.

Security groups and vendors agree. OWASP writes that it is unclear whether there are fool-proof methods of prevention. Anthropic, describing its browser-agent defenses, says prompt injection is “far from a solved problem” and that no browser agent is immune. Treat every defense below as reducing risk, not removing it.

3. The lethal trifecta

Willison’s most useful rule for anyone wiring tools together: be very careful when one agent combines all three of these —

• Access to private data — your email, files, private repos.
• Exposure to untrusted content — anything an outsider can put in front of the model (web pages, incoming email, public issues).
• A way to communicate externally — sending email, making HTTP requests, even rendering an image URL or a link that could carry data out.

With all three, an attacker can try to trick the agent into reading your data and sending it to them. An email tool is a good example of the risk: anyone can email your agent. His advice for people mixing tools, including MCP connectors, is to avoid combining all three in one agent.

4. Guardrails that actually help

These come from the OWASP LLM01 mitigations and the MCP specification:

• Least privilege — give the agent only the tools and scopes its job needs. Read-only where possible. The MCP security guidance recommends starting with a minimal scope set and elevating only when a privileged operation is actually needed.
• Human approval for high-risk actions — OWASP recommends human-in-the-loop controls for privileged operations. The MCP spec says there SHOULD always be a human able to deny tool invocations, and that clients should ask for confirmation on sensitive operations.
• Mark untrusted content — OWASP recommends separating and clearly labeling external content so it has less influence. Tell the agent that fenced content is data to read, not orders to follow.
• Show tool inputs before they run — the MCP spec suggests showing the user tool inputs before calling a server, to catch accidental or malicious exfiltration.
• Keep code in charge of credentials — OWASP suggests handling API tokens and privileged functions in code rather than handing them to the model.
• Log tool use — the MCP spec recommends logging tool calls for audit; OWASP’s cheat sheet recommends logging LLM interactions too.
• Vet connectors before installing — the MCP security guidance warns that local MCP servers can run arbitrary code with the client’s privileges, so check the exact command before approving one.

5. What this looks like in agent tools

Cursor’s agent security docs describe defaults along these lines: terminal commands need approval unless you configure Run Modes, every MCP connection needs approval and each MCP tool call needs individual approval unless you allowlist it, and agents can’t make arbitrary network requests with default settings. Cursor describes its allowlists and Auto-review classifier as best-effort guardrails rather than a hard security boundary, and recommends keeping the defaults enabled.

For a small fleet, the practical pattern is: let agents read and draft freely, but keep a human approval step in front of anything that sends, posts, deletes, pays, or shares. A one-job bot helps here too — a narrow job needs fewer tools, which makes the trifecta easier to avoid.

6. A quick safety checklist

• Does this agent have private data, untrusted input, and a way to send data out? If so, can one of the three go?
• Does it have only the tools and scopes its one job needs?
• Do sends, posts, deletes, payments, and sharing require human approval?
• Is fetched web and email content clearly marked as untrusted data in the prompt?
• Would you see the tool inputs before an outbound action runs?
• Are tool calls logged so you can audit what happened?
• Did you check the source and startup command of every connector you installed?
• For scheduled runs, does the routine stop and wait rather than auto-approve? (See Scheduling AI agent routines.)

Useful public resources