You have probably been told that prompt injection is a filtering problem: scan what goes into the model, block the hostile strings, and the agent is safe. That belief is why agents ship with a protection nobody has tested, and it fails for a reason no better filter will repair.
A language model reads one stream of text. Your system prompt, the user's question, the web page the agent just fetched and the README it just opened all arrive as tokens in the same context. There is no type system separating instructions from data. SQL injection was fixable because a database lets you keep the query apart from its parameters. Nothing equivalent exists inside a model. A filter can lower the odds that an attack lands. Anyone who says a guardrail "stops prompt injection" is selling a probability.
So stop asking how to detect hostile text. Ask what a perfectly obedient reader could do from the desk you have put it at.
Picture a clerk who follows any sheet of paper that lands in the tray, whoever wrote it. Nobody sensible responds by training the clerk to spot forgeries and then handing over the company chequebook. You look at what the desk is connected to. That is the whole of agent security, and it moves the work from the prompt, where you cannot win, to the permissions, where you can.
The attacker does not need to be your user, which is the part the "ignore previous instructions" demonstrations hide. Typing into a chat box is the easy case. The dangerous one is indirect: someone plants text where your agent will eventually read it, in a web page, a support ticket, a calendar invite or a pull request description, and the agent fetches it as part of ordinary work. Nobody on your side clicks anything. Anthropic's own Git MCP server carried three vulnerabilities reachable by prompt injection, CVE-2025-68143, CVE-2025-68144 and CVE-2025-68145, where a poisoned README or issue description was enough to reach code execution. Tool descriptions are a surface as well. An agent reads a tool's name, description and schema to decide how to use it, so a third-party MCP server can carry instructions the moment it is connected. Wiring one in imports its trust boundary along with its features.
Scale turns a small success rate into a certainty. Zylos AI's 2026 research on agentic AI security cites a public red-teaming exercise that ran 1.8 million injection attempts and recorded more than 60,000 policy violations, a 3.3% success rate. Against a person, 3.3% sounds like a nuisance. An agent reads thousands of documents a day, and it will meet the one that works. The same research reports that 73% of production AI deployments were hit by prompt injection in 2025 and that only 29% of the organizations running them say they are prepared to secure agents. Treat that as a single secondary source and not a census.
Since the planted sentence cannot be stopped, the design question is what it can reach. Developer Simon Willison named the combination that turns a nuisance into a breach: an agent that can see private data, reads content from outside, and can communicate externally. Each capability is harmless alone. Together they are an exfiltration pipeline that needs only one planted sentence to run. The rule that follows is blunt: no single agent holds all three. The agent that reads inbound email cannot send requests to arbitrary addresses. The agent with database access does not browse the open web. Permissions are scoped to the task and not to the agent, so a support agent has no shell and a coding agent has no production credential belonging to an unrelated system.
Where an action cannot be undone, such as a payment, a deletion or a message to a new recipient, put a confirmation step in front of it that the model has no way to skip. That is worth more than any classifier, because it does not depend on the model noticing anything. Version-pin every MCP server, read its tool descriptions the way you would read a dependency, and look again when they change. Log what the agent read and why it acted, not only what it said, because an injection that yields a plausible answer is invisible to anyone who cannot see the inputs. We take that gap on in the agent observability problem. And assume some agents already exist that you never approved. Staff run tools on their own, which is the subject of our piece on shadow AI governance, and those are the agents with no controls at all.
Buyers are beginning to look for this. Google Ads data pulled through DataForSEO on 11 October 2026 (US, English) shows prompt injection at 5,400 searches a month, up from 3,600 in September 2025 after a spike to 9,900 in August 2026. It is one country and one search engine, and it cannot tell engineers from procurement teams. What it does show is unusual: of fifteen agent-related terms we measured, eleven returned no measurable volume at all, including ai agent observability, ai agent evaluation and mcp protocol. The industry writes about those. Almost nobody searches for them. Prompt injection is one of the few agent terms people actually look up, and it is the one about what goes wrong.
ThinqHub implements Odoo and ERPNext, so the AI work we do sits next to invoices, stock records and customer data. We think security belongs in the design of what we build and not in an audit afterwards, and the permission model above is where that starts. If you are putting agents near systems that matter and have not tried to fool them, our AI services begin with that test. Talk to us before someone else runs it for you.
