The Model Is Not a Security Control: Vince Ovando at [un]prompted II

If a control lives inside the thing being attacked, it was never a control. That is the claim in the title of Vince Ovando's [un]prompted II talk, and it is worth disputing line by line. [un]prompted II (many people type "unprompted") is the AI security practitioner conference in San Francisco, 27-29 October 2026. Our conference guide covers the whole programme.

Vince Ovando is listed on the official agenda with no company. His talk, "The Model Is NOT a Security Control: Prompt Injection Dies at the Token Sampler", is on Day 1, Stage 2, at 13:55. This is a preview written from the published abstract, as published on 2026-10-12, before the talk. We are independent coverage, not the organiser, and we follow the conference remotely. An agenda can change, so check the source.

What the talk says it will show at [un]prompted II

The abstract describes the Tantalus indirect prompt-injection arena: about 6.1 million inference calls, on models from 1.7B to 119B parameters. Its headline result is that only one control provably blocked bad outputs at 100%. The abstract does not say which control that is. The title suggests it acts at the token sampler, which is the step that picks the next token from the model's output distribution. That is our reading of the title, not a published fact.

Why this is the hard part

Most prompt-injection defences ask the model to resist. A system prompt tells it to ignore instructions in documents. A classifier model screens the input. In every case the defender and the attacker share one channel, and the attacker writes in the same language the defender does. We covered this pattern in prompt injection in multi-agent pipelines, and we looked at the trade-offs of practical defences in Stripe, Snap and Sondera on stopping prompt injection.

The shared-channel argument is ours, and it is not new. The talk's contribution, if the abstract holds, is a large measurement that puts a number on it. A 6.1 million call arena is big enough to show a model-side defence failing at a rate that is hard to dismiss. It also shows that a defence can sit outside the model's judgement and still work. We have placed this in the argument list in the six arguments that we expect to see at the conference.

There is a counter-argument, and we should state it. A defence at the sampler is still software that someone must configure. If it works by restricting which tokens the model may emit, it constrains what the model can say, and that has a cost for useful output. A control that blocks every bad output but also blocks many good ones is easy to score at 100% and hard to deploy. So the 100% figure is the start of the analysis, not the end. We will read the talk for the false-positive side of the same result, and for the attack classes that the arena leaves out. This is our framing, and the abstract does not say that the trade-off exists.

What we will be watching for

• Whether the 100% control is named, and whether it is deterministic or itself a learned component.
• What the attack set in Tantalus covers, and whether the 100% result holds across all model sizes from 1.7B to 119B.
• Whether the control blocks bad outputs only, or also blocks good outputs, and how often.
• Whether the arena tests adaptive attackers who know the control exists.
• Whether the result depends on a closed output format, which would limit how far it generalises to free-form agents.

If this holds, what changes on Monday

These are our inferences, conditional on the result. Stop counting a system prompt, or a model-based guard, as a boundary in your threat model. List which of your controls run inside the model's own context, and mark them as best-effort. Move enforcement to a layer the attacker's text cannot reach, such as constrained output formats, allow-lists of tool calls, or checks on the output channel. Test any such control with an adaptive attacker. A control that blocked 100% in one arena has not been shown to block 100% in yours. Our pre-deployment checklist is a place to record the change.

Three questions for Vince Ovando

These are the questions we would ask. The page stands without any reply.

1. Which control blocked bad outputs at 100%, and at what layer of the stack does it act?
2. What does that control cost at the sampler, in latency and in blocked good outputs?
3. What does "provably" mean in an arena of about 6.1 million calls: a formal guarantee, or no observed failures in the attack set?