Short answer. Most prompt injection testing sends one request and grades one reply. That method finds injection that lives inside a single conversation. It does not find injection that writes itself into something the system reads on the next run: a model file, a stored memory, an agent's working file. Three separate disclosures in the past week describe that second kind. If your test starts a clean session every time, it will report a system as safe while the payload is already sitting in the artifact.
The distinction matters more than it sounds. It changes what you test, what "passing" means, and what you have to clean up after an incident.
Two kinds of injection
Prompt injection is usually described as one thing. In practice there are two, and they fail differently.
| Session-scoped | Persistent | |
|---|---|---|
| Where the payload lives | the context window | a file, a record, a config |
| Lifetime | one conversation | until someone removes it |
| Who it affects | the user who triggered it | every later user of that component |
| Cleanup | close the session | find and repair the artifact |
| A fresh-session test finds it | yes | no |
Session-scoped injection is the familiar one. Text arrives in the context window, the model cannot tell instructions from data, and it follows the wrong one. Close the conversation and the problem is gone.
Persistent injection uses the same trick to reach a write. Once the payload is written, the model does not need to be attacked again. It reads the poisoned artifact at the start of every run and behaves as instructed, to every user, until somebody notices.
Three shapes, all from the past week
I am describing these by category rather than by vendor. The pattern is what matters, and every one of them is now patched or has published mitigations.
The model artifact. A local model runner was found to bind its API to all interfaces with no authentication. A page in the browser could reach it through DNS rebinding and rewrite the model's chat template. The template is applied to every later conversation. Deleting the chat history does nothing, because the history was never where the instruction lived.
Stored memory. An assistant with connected accounts could be driven, through a single crafted link, to read from those accounts and write to its own saved memory rules. The next session starts with the attacker's rules already loaded.
Agent working files. Research reported this month on agents that write to their own instruction files reports payloads propagating from one agent to the next in a majority of trials, and surviving chains of about twenty hops even when the files were deleted between steps. In-the-wild propagation has not been demonstrated, and I would treat the specific rates as laboratory numbers rather than field measurements. The mechanism is the part to take seriously.
Different products, one architecture: the model can write to a location the model later reads. That is the whole class.
Why a normal scan misses it
A prompt injection test usually looks like this. Open a session. Send a probe. Grade the reply. Close the session. Repeat for the next probe.
That loop is correct, and we build our own scanning that way on purpose. A jailbreak that lands on probe three must not still be in effect on probe four, or every later finding becomes unattributable and you cannot tell the customer which probe caused what. Isolation buys you attribution.
Isolation also guarantees you will not see persistence. Every probe gets a clean room. The one thing persistent injection does, by definition, is carry across the boundary you just reset.
So this is not a bug in stateless probing. It is a second test that has to be designed deliberately, and most programmes have not designed it.
What the test looks like instead
Three changes. None of them require new tooling.
1. Test the configured system, not the model. The FDA's discussion paper on generative-AI-enabled medical devices, published 18 August, makes this point plainly for its own domain: fixed-input, fixed-output test methods do not transfer to generative systems, and benchmarking belongs on the deployed and configured device rather than on the bare model. The same holds outside medical devices. A model endpoint tested in isolation has no memory, no tools and no working files, so it cannot exhibit the failure at all.
2. Separate the write from the read. Persistence needs two steps, and you have to test them as two steps.
- Run the probe that attempts the write. Grade whether the write happened, not whether the reply looked bad. A refusal in the reply and a successful write in the artifact is a pass on the wrong axis.
- Start a new session. Send a plain, benign request. Grade that reply.
If the benign request in the clean session behaves differently from the same request before the probe, you have persistence. This is the whole test. It is unglamorous and most teams have never run it.
3. Diff the artifacts. Capture a hash of every artifact the system reads at start-up before the test window and after it: chat templates and model files, system prompt files, stored memory or profile records, agent instruction files, tool and connector configuration. A changed hash on a file nobody deployed is the finding. This also gives you your cleanup list, which you will want, because "close the session" is not remediation here.
Where it maps
For anyone who has to file this against a control:
- OWASP LLM Top 10: LLM01 for the injection itself, LLM04 for the poisoning of model or data, LLM02 where the payload exfiltrates, LLM06 where the agent has the permissions to perform the write.
- OWASP Agentic Top 10: memory poisoning and the trust boundary between agents.
- MITRE ATLAS: the backdoored-model technique for the artifact case, and LLM prompt injection for the delivery.
Filing it under LLM01 alone tends to hide it, because LLM01 remediation usually reads as input filtering, and input filtering does not remove a payload that is already stored.
The controls that actually reduce this
The UK NCSC published interim guidance on managing the cyber risk of agentic AI on 20 August. It is advisory and will be superseded, but the shape of the advice is right, and three of its points bear directly on persistence:
- Deny by default, then allowlist. Both directions. The model-artifact case above needed nothing more exotic than a service listening on a non-loopback interface with no authentication. That is a 2010 finding wearing new clothes.
- Least privilege per agent, not per deployment. The write is the whole attack. If an agent cannot write to its own instruction file, the persistent variant does not exist for that agent.
- An emergency stop you have actually tested. Including cutting the agent off from its inference infrastructure. If your only stop is stopping the worker, you will find out at the wrong moment that it takes the rest of the fleet with it.
To that I would add one more that is not in the guidance: treat the artifacts as configuration under change control. If a chat template or a memory record can change without a deployment, it is code that skipped review.
Why this is worth your week
Industry telemetry published on 18 August by the Cloud Security Alliance, covering more than 1,200 organisations running AI in production, puts 56 percent of them on agent frameworks without formal safety controls and 64 percent with vector databases wired into enterprise data. The same report puts the share of AI-package vulnerability alerts with a public exploit at just over half. The same measure sat at a fraction of a percent in the earlier edition.
I do not think the interesting number there is any of those three. It is that agent frameworks are in production at that rate while the class of failure they introduce, the one where the model writes to something the model later reads, is still being tested with a method designed for stateless chat.
The fix is not a product. It is a second test case and a hash list. Write them down before your next assessment, because the current one probably says you passed.
Where we can help
If you run an agent or an assistant that has memory, tools or writable configuration, a scoped review from our team covers the persistence case explicitly. Request a demo, or read how we approach prompt injection testing and agent security.