You cannot patch a prompt injection

Your third-party risk framework rests on an assumption so basic that nobody writes it down: software behaves the same way twice.

You test it, you certify it, you deploy it, and its behaviour on Tuesday tells you something reliable about its behaviour on Thursday. Every control in the framework, from change management to penetration testing to vendor attestation, inherits that assumption.

Agents break it, and the security consequences are not the ones most organisations are preparing for.

Anything your agent reads can instruct it

A supplier invoice. A customer email. A support ticket. A web page the agent fetched to answer a question. A document in the knowledge base that someone uploaded three years ago.

Prompt injection is what happens when a system has no reliable way to distinguish data from instruction. You hand the model a document and say "summarise this," and somewhere in the document is a sentence addressed to the model rather than to the reader. The model has no separate channel through which it can tell that the first instruction came from you and the second came from the content.

This is not a defect awaiting a patch. It is a property of how these systems process input. There is no version number at which it gets fixed, and treating it as a vulnerability to be remediated leads organisations to wait for a fix that is not coming.

Expect someone to tell you their platform has guardrails. Guardrails reduce the risk and they are worth having. They do not remove it, because the classifier deciding whether something is an injection is itself a model with the same fundamental limitation.

The three ingredients, and why any two are fine

The useful framing here, and the one I ask security teams to adopt, is to stop thinking about injection as an unbounded threat and start thinking about it as a combination.

An agent becomes an exfiltration route when it has all three of:

1. Access to private data. Customer records, internal documents, anything worth taking.
2. Exposure to untrusted content. Anything from outside your control that the agent reads.
3. An outbound channel. The ability to send, post, call an external API, or write somewhere a third party can read.

Any two of those are survivable. An agent with private data and untrusted content but no way to communicate outward cannot leak. An agent with untrusted content and an outbound channel but no private data has nothing worth leaking.

All three together is a data exfiltration path, and here is the operational problem: most agent designs acquire all three by the second sprint without anyone deciding to. The data access arrives because the agent needs context. The untrusted content arrives because the agent needs to read tickets. The outbound channel arrives because someone wanted it to send a confirmation email.

Nobody approved an exfiltration route. Three reasonable decisions produced one.

This framing converts an unbounded fear into a containment rule your CISO can apply on Monday. Separate the three. That is an architectural control, which means it survives a model upgrade, unlike anything that depends on the model behaving well.

The credentials question that ends most conversations

Ask your team a single question: who does the agent log in as?

If the answer is a shared service account or a colleague's own credentials, then one bad instruction reaches everything that person or account can reach. In a bank, that is the customer book. In a government department, that is the citizen record. In a hospital, it is the patient file.

The blast radius is the permission set, and permission sets accumulate. The service account created for a proof of concept in March has, by September, been granted whatever it needed along the way, because each individual grant was the fastest way to unblock the sprint.

Three properties matter, and they are ordinary identity engineering rather than anything exotic:

Its own identity. Not a human's, not a shared one. An agent should be a first-class principal in your directory, distinguishable in every log.

Scoped to one task. Not to a role, not to a department. The permissions required for the specific job, and nothing inherited for convenience.

Short-lived. Access that expires by default, so the permission creep of a long-running proof of concept cannot silently become production entitlement.

The reverse gear nobody built

The security conversation usually stops at prevention. The harder question is what happens after.

On 1 August 2012, Knight Capital deployed new trading software. One server did not receive the update, and a dormant flag activated code that had been unused for years. The system began buying high and selling low, thousands of times a second, across 150 stocks. It took about forty-five minutes to stop. The loss was roughly 440 million dollars, more than the firm's market capitalisation. Knight was rescued within days and effectively ceased to exist as an independent company.

Not because nobody noticed. Because nobody could stop it fast enough, and because the system had permission to act.

Now ask what your agent has permission to do, and how long it would take you to reverse it. Most organisations discover the answer is that reversal was never designed, because the pilot never did anything consequential enough to need it, and production inherited the pilot's architecture.

Irreversible actions need compensating ones. Checkpoints need to exist before you widen autonomy, not after an incident. And there needs to be a kill switch that someone has actually tested, on a normal Tuesday, before it matters.

What to do

Map the trifecta for every agent in production. Which have all three ingredients? That list is your actual exposure, and it is usually shorter and more specific than the general anxiety it replaces.

Ask the login question in writing. Not in a workshop. In writing, to whoever owns the agent, with a date.

Design the reverse gear before you widen permissions. The order matters. Reversibility first, then autonomy, then scope. Every programme that does it in the other order is relying on the agent not making a mistake, which is not a control.

You cannot patch a prompt injection. You can only make sure the agent cannot reach anything worth stealing, and that you can undo whatever it does reach.