Prompt injection sits at the top of the OWASP Top 10 for LLM Applications for a reason. Large language models do not reliably separate instructions from data. Any text that reaches the model, whether it comes from a person, a web page, an email, a PDF or a tool response, can try to change what the model does next.
With a chat assistant, a successful injection usually produces a bad answer. With an agent that can call tools, it can produce a bad action: data sent to the wrong place, a record changed, a payment queued, a configuration altered. The OWASP list names this second risk directly as excessive agency.
The honest position is that there is no complete technical fix for prompt injection today. Classifiers and prompt hardening reduce the rate of success, but they do not bring it to zero. The defensible strategy is defense in depth: assume some injected instructions will reach the model, and design the system so that when they do, the damage is small, visible and reversible.
Here is the checklist we use when we review an agentic system.
Layer 1: trust boundaries for input
- Classify every input source by trust level. Instructions from your own system prompt and configuration are trusted. Content from a person in your organization is partly trusted. Content from the internet, inbound email, uploaded files and third-party APIs is untrusted.
- Mark untrusted content as data. Wrap it in clear delimiters and tell the model it is material to analyze, not instructions to follow. This does not stop injection on its own, but it raises the bar.
- Watch for indirect injection. The most damaging attacks often arrive through retrieval: a poisoned document in a knowledge base, a hidden instruction in a web page, text in an image or a file's metadata.
- Screen inputs with a dedicated detector. Use a classifier or rules to flag likely injection attempts, and route flagged content to a lower-privilege path rather than silently dropping it.
Layer 2: least privilege for tools
- Give each agent the smallest tool set that does the job. An agent that summarizes tickets does not need to close them.
- Scope credentials per agent and per task. Use short-lived tokens tied to the agent's identity, never a shared service account with broad rights.
- Separate read from write. Many useful agents only need read access. Where write access is required, scope it to specific records or fields.
- Constrain tool parameters. If a tool sends email, restrict recipients to approved domains. If it queries a database, restrict it to named views. Enforce these limits in the tool, not in the prompt.
- Isolate privileged reasoning from untrusted content. One useful pattern is to let a low-privilege model read untrusted material and return structured data, while a separate step with tool access never sees the raw text.
Layer 3: validate before anything executes
- Check every tool call against a schema and a policy. Reject calls with unexpected parameters, out-of-scope targets or unusual volume.
- Treat model output as untrusted too. OWASP lists improper output handling as its own risk. Never pass model output directly to a shell, a SQL engine, a browser or a template without encoding and validation.
- Block data exfiltration paths. Watch for output that embeds sensitive data in URLs, image links or markdown that a client will render and fetch.
- Rate-limit actions. A sudden burst of tool calls is a signal worth stopping on, whether the cause is an attack or a loop.
Layer 4: people in the loop where it counts
- Define which actions are consequential. Moving money, deleting data, changing access, contacting customers and changing production systems are common examples.
- Require explicit approval for those actions. Show the approver what the agent intends to do, why, and which inputs drove the decision.
- Design approval screens to resist fatigue. If approvers see hundreds of routine requests a day, they will stop reading. Keep approvals for actions that deserve them.
- Prefer reversible actions. Drafts before sends, staged changes before commits, soft deletes before hard deletes.
Layer 5: observe, record and respond
- Log the full chain. Record the inputs the agent saw, the tool calls it proposed, the policy decisions made, the approvals given and the results returned.
- Make logs tamper-evident. An attacker who can influence an agent may also try to influence its records.
- Feed agent telemetry into your security operations. Agent actions should appear alongside other identity and access events, with alerts for unusual patterns.
- Write an incident playbook for agents. Know how to suspend an agent, revoke its credentials and review its recent actions within minutes.
Layer 6: test like an attacker
- Run red-team exercises before launch and after major changes. Include direct and indirect injection, tool misuse and data exfiltration attempts.
- Keep a regression suite of known attacks. Every new attack you discover becomes a test case that runs on every model, prompt or tool change.
- Use shared threat knowledge. MITRE ATLAS catalogs adversary tactics and techniques against AI systems, and is a useful map when planning test coverage.
A quick self-assessment
If you can answer yes to these five questions, your agent is in better shape than most:
- If the model followed an injected instruction, could the worst resulting action be undone?
- Are tool permissions enforced outside the model, in code or policy?
- Does every consequential action require a named person to approve it?
- Could you reconstruct, from logs alone, why the agent did what it did last Tuesday?
- Do known attacks run as automated tests before every release?
Where we can help
We design and review agentic systems with these layers built in, and our AI governance and security practice runs structured assessments and red-team exercises against existing deployments. If you are preparing an agent for production, talk to us before it gets write access to anything that matters.