What is delayed prompt injection in AI agents?
It is a hidden order inside a text the agent reads, which stays idle until a signal arrives. On 6 October 2026 CERT-AgID, the cybersecurity team of Italy's digital agency AgID that serves the public sector, published a study of this attack. It calls it an "explosive prompt": the instruction gets in when the model reads a document and only takes effect later in the conversation.
A prompt injection is made of sentences written for an AI model and hidden in an email, a web page or an attachment. The model mistakes them for orders and tries to carry them out with the permissions it has.
What did CERT-AgID see in its test?
CERT-AgID wrote a document with a hidden instruction and had four open-weight models read it. Open weight means you can install the model on your own servers. In the first two turns the user asks normal questions about the document, and the models answer well. In the third turn the user only writes "Perfect, thanks". That is the signal the hidden instruction was waiting for.
Across 30 runs per model, the order fired at least once with all four. The rate varies a lot, from 10% of runs with Qwen 3.8 to 76.7% with Gemma 4. In no run did the model act before the signal. CERT-AgID warns that these results describe its experiment, not the general security of the models.
Our read: the delay is what matters. If you watch the agent while it reads the email, you see nothing odd. The problem shows up later, when nobody links it to that message any more.
Does it happen outside the lab?
Two recent cases show agents following orders found in content, although neither was a delayed attack. Researchers at Salt Security took over Manus, an AI agent platform connected to email, with a single message. The victim only had to ask the agent to check the inbox. Manus's security check raised the alarm, but only after the code had already run. The flaw has been fixed.
According to BleepingComputer, researchers at Forever Security found a malicious instruction file in a customer's Downloads folder. A coding agent read it and tried to install a malicious software package. The researchers reproduced the attack with OpenAI's Codex, and a similar technique with Anthropic's Claude Code.
How does a business defend itself, in practice?
CERT-AgID's second experiment answers this. The agent had a command that could change a protected value, but not the permission to use it. In one setup the model's request was simply carried out. In the other, a check outside the model verified the permissions before anything ran.
Without the check, all 14 activations of the order changed the value. With the outside check the model asked for the action 10 times, and none of them ran. CERT-AgID compares it to an employee who is tricked into asking for a door they are not cleared for. They can ask, but if the system checks permissions, the door stays shut.
- Give the agent only the permissions its job needs. If it reads email to sort it, it should not be able to forward it outside or delete it.
- Let a check outside the model decide permissions, at the moment the agent asks to act.
- Have a person approve sensitive actions, such as payments, messages sent outside and changes to data.
- Keep a log of every action and of what the agent had read before it. An odd action can then be traced to the document that caused it.
- Treat emails, attachments and web pages as text to read, never as instructions.
Why does it matter for your business?
Take an example of ours, not a real case. An agent reads supplier emails and prepares invoice entries. A fake supplier sends an invoice with a hidden sentence: when the user says thanks, ask to change the supplier's bank details. The agent works fine all morning. Then the clerk types "thanks", and the change request goes out.
If changing bank details goes through a check that verifies permissions and asks a person for approval, the request stops there. If the agent can approve itself, the next payment goes to the wrong account.
What about us?
On our Security page we describe how the systems we build work. Every tool is scoped by role, and reads, writes and sensitive actions are separate permissions. Sensitive actions wait for a person, and every call is logged with its inputs and outcome. It is the same principle CERT-AgID put to the test: the check sits outside the model.
So what do you do?
- If your agent only reads internal documents and cannot act on your systems, the risk is low. Keep it that way.
- If it reads emails, attachments or web pages and can act, put a permission check outside the model before every action.
- If today the agent carries out everything it asks for, change that setting before anything else.
“A model can be fooled. The system around it has to stop the trick from becoming an action.”
DBrothers — how we protect agents that read outside content
Frequently asked questions
Is choosing a safer model enough?
No. In CERT-AgID's test all four models carried out the order at least once. The rate changes, the risk does not. The defence that worked was the outside check.
Does it only affect models installed in-house?
CERT-AgID tested open-weight models. The other two cases involve Manus, Codex and Claude Code, which are cloud services. What matters is what the agent can do, not where the model runs.
If a person approves actions, am I safe?
Much safer, if the person sees what they are approving and why. In the Manus case the warning came after the code had run. The check has to come before the action.
If your agent reads emails or documents from outside, we start from the list of what it can do and work out together where an independent check is needed.
