Securing Agentic AI: Prompt Injection and Real Trust Boundaries

An agent that can only read is a search feature. An agent that can act — send messages, write to systems, spend money, run code — is a new principal in your security model, and it is one that takes instructions from whatever text it happens to encounter.

That last clause is the entire problem, and it does not have a clean solution.

Why prompt injection has no patch

A language model receives one sequence of tokens. Your system prompt, the user’s message, a retrieved document, the output of a tool call — all of it arrives as text in the same context, and the model has no reliable mechanism for distinguishing instructions it should follow from data it should merely process.

So text placed anywhere the model will read it can attempt to redirect its behaviour. That includes a support ticket, a web page fetched during a search, the contents of a file, a code comment in a repository, an email in an inbox the agent can read, or the response from a third-party API.

The comparison to SQL injection is instructive precisely because of where it breaks down. SQL injection was solved by parameterised queries, which separate code from data at the protocol level. No such separation exists for language models. Instruction hierarchies and delimiters raise the difficulty; they do not close the hole, and treating them as though they do is how systems get built on a false assumption.

The lethal trifecta

The most useful framing for reasoning about agent risk identifies three capabilities that are individually manageable and dangerous in combination:

1. Access to private data — your database, internal documents, the user’s email.
2. Exposure to untrusted content — anything the agent reads that an attacker could have influenced.
3. An outbound channel — the ability to send data somewhere, whether by an HTTP request, an email, or a rendered image URL.

With all three, injected text can instruct the agent to read something sensitive and transmit it. Remove any one and the exfiltration path closes.

The subtle part is how easily an outbound channel appears without anyone deciding to add one. Rendering markdown that includes an image URL is an outbound channel. A tool that fetches a URL is an outbound channel. A logging system an attacker can read is an outbound channel. These get built for good reasons and each one completes the triangle.

Architectural defences that actually hold

Constrain the tools, not the prompt

The most effective control is limiting what the agent is capable of doing at all.

• Read-only by default. Anything that writes, sends or spends should be a deliberate, separately justified addition.
• Narrow tool scope. A tool that queries three specific tables is safer than one that runs arbitrary SQL, and it is usually sufficient for the actual use case.
• Parameter validation outside the model. Validate and constrain tool arguments in code. A model asked politely will produce a path traversal string.
• The agent’s own credentials, scoped to the minimum, never the calling user’s full permissions and never a service account with broad access.

Sandbox anything that executes

If the agent runs code, it runs in an isolated environment with no ambient credentials, an ephemeral filesystem, resource limits, and — most importantly — a network allowlist rather than a denylist.

Network egress is where sandboxes usually leak. A container with no filesystem access and unrestricted outbound HTTP is not contained; it has a perfectly good exfiltration channel. Default deny, and allowlist the specific hosts the task requires.

Put humans in front of consequences

Approval gates are the most reliable control available, and the design of them determines whether they work.

Gate on irreversibility rather than on a generic sense of risk: sending anything externally, deleting, spending, changing permissions, writing to production. And show the human the specific action with its actual parameters, not a summary of intent. “The agent would like to send an email” is not reviewable; the recipient, subject and body are.

The failure mode to design against is approval fatigue. A gate triggered forty times a day becomes a button people press without reading, which is worse than no gate because it manufactures the appearance of oversight.

Separate planning from privilege

A pattern that meaningfully reduces exposure: one model call reads the untrusted content and produces a structured summary; a separate call, which never sees the raw content, decides what to do based on that summary.

The component with access to attacker-controlled text has no tools. The component with tools never sees attacker-controlled text. This is more work and it is a real boundary rather than a hopeful one.

On MCP specifically

The Model Context Protocol standardised how agents connect to tools and data sources, and it is a genuine improvement over every integration being bespoke. It is also frequently misunderstood.

MCP is a transport and discovery protocol. It describes how a client and a server exchange tool definitions and calls. It does not decide whether a given call should be permitted, it does not authenticate the requesting user to the underlying system, and it does not sanitise anything.

Connecting a database through MCP does not make it safer than connecting it any other way. The security properties come from what the server exposes, what credentials it holds, and what authorisation runs before it acts. Those are your decisions, and the protocol is deliberately silent on them.

Three specific things to check on any MCP server you run or install:

• What credentials does it hold, and at what scope? A server with an admin API key gives every connected agent admin access.
• Where does authorisation happen? If the answer is nowhere, the model’s judgement is your access control.
• Do you trust the server itself? A third-party MCP server sees everything passed through it, and tool descriptions themselves are text the model reads — a malicious description is an injection vector.

What to log

Assume something will go wrong and make it reconstructable. Every prompt including retrieved content, every tool call with its parameters, every result, every approval and who granted it, and the model version and configuration in use.

Without this you cannot answer the question that follows any incident — what did the agent actually do, and what convinced it to. Retrofitting the logging after that question is asked is not an option.

Boolean Solutions experience with agent security

We build agent-based systems and we review them, and the finding we report most often is the same one: an agent given broad tool access because narrowing it was inconvenient, with the security argument resting on the system prompt telling it not to do bad things.

That is not a control. The work is in the boring parts — scoped credentials, narrow tools, validated parameters, egress allowlists, and approval gates on the small number of actions that cannot be undone. If you are building something in this space and want a review before it ships, talk to us, and our security services page describes how we approach it.

Further reading

• The Lethal Trifecta — Simon Willison; the clearest framing of agent exfiltration risk
• OWASP Top 10 for LLM Applications — the standard reference, with prompt injection at number one
• Model Context Protocol specification — worth reading to see exactly where its responsibilities end
• NIST AI Risk Management Framework — for the governance layer above the technical controls