Every agent project eventually stalls on the same review meeting. Security asks what the agent is allowed to do, and nobody in the room can give a straight answer. The demo works, the model is impressive, and the permission model is a shrug.
That gap is worth closing early, because it is the thing that decides how bad a bad day gets.
Why Injection Is Not The Whole Story
Prompt injection deserves the attention it gets, but on its own an injected instruction is just text sitting in a context window. It becomes an incident when something downstream is willing to act on it.
That is the part worth designing. An agent that can only read a knowledge base and return a summary can be injected all day and the worst outcome is a wrong answer. The same injection against an agent holding a write capable database handle and a shell tool is a very different afternoon.
So the question is not only how to keep bad instructions out. It is what the agent is permitted to do once one gets in, because eventually one will.
Scope Permissions Per Tool, Not Per Agent
The most useful change I have seen teams make is moving the permission boundary from the agent down to the individual tool.
Agent level scoping tends to collapse into a single service account with everything the agent might ever need, because that is the path of least resistance during development. Tool level scoping forces a smaller question: this specific capability, what does it need, and what should it never touch?
It also unblocks reviews. Security can approve one narrow capability at a time instead of signing off on an entire autonomous system, which is a much easier yes.
The Boundaries Worth Validating
Input validation usually gets implemented at the chat box and stops there, which misses most of the real surface. An agent reads from many places, and each one carries instructions if an attacker wants it to.
Retrieved documents from your vector store. Scraped web pages. API responses. File contents. Messages from other agents in a multi agent setup. Its own earlier output when that gets stored and read back later.
Treat each of those as a boundary and the picture gets clearer. Validate what comes in, filter what goes out, and keep an append only audit trail the agent cannot rewrite, because after an incident that log is the only account of what really happened.
The full breakdown, including the five layer attack surface and the threat categories that map to each layer, is in this guide to AI agent security.
Takeaway
You do not need a finished threat model to make progress. You need one sentence per tool describing what it may touch, and an honest answer to what happens if the agent is talked into using it wrong. Write those down before the security review, not during it.
Which of your agent's tools would you be least comfortable defending in that meeting?
Top comments (0)