AI Agent Security: Assume the Prompt Will Be Injected, Then Limit the Damage

Most agent security conversations start in the wrong place. Teams ask how to stop the model being tricked. The better question is what happens when it is.

An agent reads emails, web pages, tickets and documents. Any of them can contain instructions. Because the model takes in instructions and data together, you can't count on it telling them apart every time. A better prompt helps, but it isn't a security boundary.

So treat the model like an untrusted user with a very persuasive manner, and put the controls around it.

The dangerous combination

An agent becomes seriously risky when it has all three of these:

Ingredient	Example
It reads untrusted content	Inbound email, web pages, uploaded files
It can reach sensitive data	Customer records, internal documents
It can act or send data out	Send an email, call an API, write to a system

Remove one and the risk drops sharply. This is the first design question I'd ask of any agent. Does this one really need all three?

The blast-radius review

Run these eight checks on any agent that can take real actions:

1. Its own identity. It shouldn't borrow a person's login or a shared admin key.
2. Least privilege per tool. Read-only by default, with narrow write access only where needed.
3. Arguments checked in code. Validate every tool call against a schema and policy before it runs.
4. Hard limits. Cap spending, volume, recipients and rate, outside the model.
5. Human approval for high-impact actions. Payments, deletions, external messages and permission changes.
6. Controlled outbound paths. Allowlist the destinations, so stolen data has nowhere to go.
7. A complete audit trail. Record each input, proposed action, decision and result.
8. A kill switch and a way back. You need to stop it quickly and reverse what you can.

Then test it. Plant malicious instructions in the content your agent reads and see how far they get. A successful attack that hits a limit is a good result. It shows the controls work.

Why this belongs in code

Each control above runs outside the model, so it behaves the same way however persuasive the attacker is. That's the idea behind the deterministic gatekeeper architecture: the model can propose anything, but only checked actions become real.

For a board or a security team, this is also an easier conversation. "The model is very unlikely to be fooled" is hard to defend. "If it's fooled, here is the most it can do" is something they can assess.

---

Vikas Goel is the founder of Thinkerwave AITech and a former enterprise CTO. He works with enterprises and founders as a fractional AI CTO and AI advisor.