Should we deploy a prompt injection detector?

As defence in depth, yes — it raises attack cost and catches unsophisticated attempts. The condition is that it must not change your permission decisions. The real harm from detectors is not false negatives, it is the over-broad agent authorisation that gets approved because a detector is in place.

How do I convince leadership that egress restriction beats filtering?

Frame it as not depending on recognition. A filter has to identify the attack to work; removing outbound network access works against attacks nobody has invented yet. That argument tends to land better than a taxonomy of bypasses, and it is also simply true.

Is sandboxing sufficient on its own?

It bounds filesystem and network damage on the machine, which is genuinely valuable, and support differs sharply by surface. What it does not bound is what the agent does through its legitimately granted tools — a sandboxed agent with a production database credential can still be talked into using it.

Where does artefact review rank against runtime controls?

Higher than most teams place it, because of reach. A runtime injection affects one session; a poisoned artefact affects every session on every machine holding it until someone notices. It is also invisible to traffic inspection, so nothing else in your stack covers it.

For Security engineering

AI security engineering

You cannot fix prompt injection, and pretending otherwise leads directly to over-permissioned agents. The tractable work is bounding what an agent can do once it has been successfully persuaded.

What you are actually accountable for

You own the controls, which means you own the honest ranking of them. There is enormous pressure to deploy a detector or a guard prompt and declare the problem addressed, because that is legible to everyone above you. The engineering reality is that injection is a property of instruction-following models rather than a bug, so your leverage is almost entirely in authorisation, egress and reversibility — and your hardest job is defending that ordering against solutions that demo better.

What is landing on you right now

Pressure to ship a detector
Filters and guard prompts are visible, demoable and easy to fund. They raise attack cost and do not close the class, and the real damage is the permissions granted on the belief that they did.
Agents inheriting human credentials
Coding agents typically run as the developer: SSH keys, cloud profile, repository write. Every one of those is available to a successful injection, and nobody explicitly granted it.
An injection surface that includes your configuration
MCP tool descriptions load before any user input and persist for the session. Input filtering never sees them, so a poisoned description bypasses your entire runtime defence.
Detection that fundamentally lags
Most injections are found after the fact, if at all. That makes reconstructability — tool calls, retrieved content, artefact versions — a primary control rather than a nice-to-have.

Questions you are being asked and cannot answer

the gap

For each agent, does it hold private data access, untrusted content exposure and outbound network access simultaneously?
What identity does each agent actually run as, and what are that identity's real scopes today?
Which tool descriptions are currently loaded into agent contexts, and when were they last read by a human?
If an agent were subverted right now, which of its available actions would be irreversible?
Could we replay a session end to end — tool calls, arguments, retrieved content, artefact versions?

The analysis, from where you are standing

Start from the architecture rather than the attack. Everything in a context window is text, and the model has no trustworthy channel marking some of it as instruction and the rest as inert data. Delimiters, system-prompt warnings and classifier filters all operate inside that single channel, which is why each of them is bypassable in principle and why new bypasses keep appearing. This is not a maturity problem that better filters will close; it is the shape of the primitive.

Accepting that turns the work into something you already know how to do. If subversion is assumed, the question is blast radius — and blast radius is authorisation, egress and reversibility, all of which are conventional controls with conventional implementations. The lethal trifecta frame is the fastest triage: private data access, untrusted content exposure, external communication. Break any leg and the exfiltration path closes, and unlike a filter, breaking a leg does not depend on recognising the attack.

The control that is consistently under-weighted is artefact review, because it does not look like security engineering. But note the asymmetry: a runtime injection compromises one session, while a poisoned MCP tool description or a skill that tells the agent to skip a check compromises every session on every machine that loads it, indefinitely. Persistent injection through configuration has orders of magnitude more reach than the runtime variety, and it is the one your traffic inspection structurally cannot see.

Finally, budget for reconstruction rather than detection. You will mostly learn about injections afterwards, so the question that decides how bad the week is becomes 'can we determine what happened and how far it reached'. Tool calls with arguments, retrieved content, and the artefact versions active per session are the three data sets that make that answerable — and all three have to be collected before the incident, which is the argument for doing it while nothing is on fire.

What to do — the end state

Enumerate untrusted input paths, including tool metadata
Fetched pages, file contents, tool results, retrieved documents, issue and code comments, email, and MCP tool descriptions. The last one is routinely missed and is the one that loads before any user input exists.
Run a trifecta audit per agent configuration
Private data, untrusted content, external communication. Three yeses is an exfiltration path. Produce the list before you design anything, because it ranks the work for you.
Remove the egress leg wherever you can
An agent that cannot make arbitrary outbound requests cannot exfiltrate what it reads, regardless of how well it is persuaded. Highest value per hour of any control here, and it does not require detecting the attack.
Replace inherited credentials with scoped service identities
Dedicated identity per agent, least privilege, read and write in separate identities where both are needed. Then answer, for each credential, what one subverted invocation could do with it.
Classify tools by reversibility and gate only the irreversible
Deploys, deletions, payments, customer contact, credential changes. Confirmation prompts spend user attention, so reserve them for actions with no undo; use rate limits and quotas elsewhere.
Read every MCP tool description as attacker-controlled input
Look for imperatives that are not about how to call the tool: read an extra file, include hidden fields, suppress a warning, call something else first. Then pin the version you read.
Review skills and rules files as executable behaviour changes
The instruction text is the under-reviewed part, not the scripts. Flag anything that relaxes a check, suppresses a prompt, or alters security-relevant output.
Sandbox where the surface supports it
Filesystem and network restrictions on the agent process bound damage without depending on model behaviour. Support varies by surface; check the per-surface capability rather than assuming.
Log tool calls with arguments, tied to a session identifier
The cheapest of the reconstruction gaps to close, and the one that gives you the agent's action sequence directly rather than reassembling it from every receiving system.
Record artefact versions per session
Without it you cannot tell whether a session ran under the reviewed skill or a modified one, which means you cannot distinguish a runtime injection from a persistent one.
Tabletop an artefact-caused incident
Not a compromised host — a poisoned skill. The exercise reliably surfaces that fleet scoping is impossible with current data, which is the finding worth having before it is real.

What to do first — the order

Week 1 · Enumerate
Untrusted input paths and a trifecta audit per agent. Pure analysis, no changes, and it produces the ranked backlog for everything that follows.
Weeks 2–4 · Bound
Egress restriction and credential scoping, in that order. These two deliver most of the available risk reduction and neither depends on detecting an attack.
Weeks 4–6 · Gate and review
Reversibility classification with confirmation on the irreversible set, then a first pass reading tool descriptions and skills as untrusted input.
Weeks 6–10 · Instrument
Tool-call logging, then retrieved content, then artefact versions per session. Finish with a tabletop that tests whether you can now answer the scoping question.

What to report upward, and the trap in each

Agents with a complete lethal trifecta
Precise, cheap to compute, directly tied to an exfiltration path. Should trend to zero, and it is the rare AI security metric that is not a proxy.
Agents running as dedicated scoped identities
Watch the reverse failure: a service identity granted broader access than the human it replaced looks like progress on this metric while increasing blast radius.
Irreversible actions behind a confirmation gate
Track alongside total prompts per session. Rising gate coverage with rising prompt volume means you are training people to click through, which removes the control.
Tool descriptions reviewed and pinned
Coverage of the persistent injection surface. Unpinned means the reviewed description and the loaded description can differ with no event to notice.
Session reconstructability
Can you replay tool calls, retrieved content and artefact versions for an arbitrary session last month? Answer it by trying, not by checking whether logging is enabled.

Where we fit, in your order

Vincosha Assay
Scans the persistent injection surface — skills, rules, hooks, tool descriptions — before it reaches a machine, which is the control that covers what traffic inspection cannot see.
Vincosha Ledger
Supplies the artefact-versions-per-session data that makes a session reconstructable and distinguishes a runtime injection from a persistent one.
Vincosha Registry
Pins artefacts so a review stays valid, and provides the placement data that turns session-scoped containment into fleet-scoped containment.

Frequently asked

Should we deploy a prompt injection detector?: As defence in depth, yes — it raises attack cost and catches unsophisticated attempts. The condition is that it must not change your permission decisions. The real harm from detectors is not false negatives, it is the over-broad agent authorisation that gets approved because a detector is in place.
How do I convince leadership that egress restriction beats filtering?: Frame it as not depending on recognition. A filter has to identify the attack to work; removing outbound network access works against attacks nobody has invented yet. That argument tends to land better than a taxonomy of bypasses, and it is also simply true.
Is sandboxing sufficient on its own?: It bounds filesystem and network damage on the machine, which is genuinely valuable, and support differs sharply by surface. What it does not bound is what the agent does through its legitimately granted tools — a sandboxed agent with a production database credential can still be talked into using it.
Where does artefact review rank against runtime controls?: Higher than most teams place it, because of reach. A runtime injection affects one session; a poisoned artefact affects every session on every machine holding it until someone notices. It is also invisible to traffic inspection, so nothing else in your stack covers it.

Sources

Written 2026-07-25. Nothing on this page asserts a statistic we did not gather ourselves, and where a regulatory or standards obligation is mentioned it is described in prose and left to your counsel to confirm against the current text rather than paraphrased as fact.