According to the Cisco State of AI Security 2026 report, 83% of organisations plan to deploy agentic AI, while only 29% feel ready to do so securely. That gap is the most important number in enterprise security right now, because the thing being deployed has a known, unsolved vulnerability class.
Prompt injection is not a bug, it is a property
Prompt injection is ranked LLM01 by OWASP — the top risk in its category — with reported attack success rates between 50% and 84% depending on system configuration and the number of attempts. OWASP's 2026 LLM Security Report describes a 340% year-over-year surge, making it the fastest-growing category of attack it tracks.
The reason it resists a clean fix is architectural. A language model receives instructions and data in the same channel. There is no equivalent of a prepared statement that separates the two. When a model reads a web page, a document, an email or a database row, any text in that content is a candidate instruction. The model has no reliable mechanism to determine which text came from its principal and which came from an adversary.
On 13 February 2026, OpenAI launched Lockdown Mode for ChatGPT and publicly acknowledged that prompt injection in AI browsers "may never be fully patched." That is a vendor telling you the threat model.
Why agents change the severity
A chatbot that can be manipulated into saying something inappropriate is an embarrassment. An agent that browses the web, executes code, sends email and queries databases is something else entirely.
The blast radius scales with capability. Reported figures indicate AI agents move roughly 16 times more data than human users, which turns a single compromised agent into a high-magnitude data exposure event rather than a single-user problem.
Critical CVEs in Microsoft Copilot (CVSS 9.3), GitHub Copilot (CVSS 9.6) and Cursor IDE (CVSS 9.8) demonstrate active exploitation in production systems across 2025 and 2026. These are not research demonstrations against toy applications.
The attack shape
A representative indirect prompt injection against a coding agent:
- An attacker plants instructions in content the agent will eventually read — a GitHub issue, a dependency README, a code comment, a documentation page.
- A developer asks the agent to perform a legitimate task that involves reading that content.
- The agent processes the planted text as instruction rather than data.
- The agent uses its legitimate tool access — file read, shell execution, network request — to act on the attacker's objective.
- Credentials, source code or environment secrets are exfiltrated through a channel the agent is permitted to use.
Note what is absent: no software vulnerability, no privilege escalation, no malware. The agent did exactly what it was designed to do, on input it was designed to accept.
Designing for a threat you cannot eliminate
Since no complete fix exists — even frontier models from OpenAI, Google and Anthropic remain vulnerable after their best defences are applied — defence in depth is the only viable strategy. In practice that means designing agent systems on the assumption that the model will sometimes be successfully manipulated, and constraining what happens next.
Separate reasoning from action
The most robust architectural pattern is to prevent the component that processes untrusted content from being the component that takes consequential action. An agent can read, summarise and propose. A separate, deterministic layer — with its own validation rules, or a human — approves anything with side effects.
Scope tool permissions to the task
Agents are routinely granted broad access because it is easier than modelling what each workflow needs. Apply least privilege as you would to a service account:
- Read-only by default; write access granted only for specific, justified operations.
- Database access through parameterised, purpose-built functions rather than arbitrary query execution.
- Network egress restricted to an allowlist of required destinations.
- No access to secret stores, credential files or cloud metadata endpoints.
Require human approval for irreversible actions
Sending external communications, moving money, deleting data, modifying production configuration, granting access. The friction is the point. An agent that can autonomously email your customer list is one injection away from a serious incident.
Log everything the agent does
Tool invocations, inputs, outputs and the content that informed each decision. When something goes wrong, the investigation depends entirely on being able to reconstruct what the agent read and what it did about it. Most deployments log far less than this.
Constrain and label untrusted content
Where content from external sources enters the context, mark it explicitly as untrusted data. This is not a robust boundary — models can still be manipulated across it — but it raises the difficulty and enables detection of content that attempts to break out of the marked region.
Governance questions worth answering before deployment
- What is the complete list of tools this agent can invoke, and what is the worst outcome from each?
- What untrusted content will enter its context, and from where?
- Who is accountable for actions the agent takes autonomously?
- How would we detect that an agent had been manipulated, and how long would that take?
- What is the kill switch, and who can operate it at 2am?
The 54-point gap between intent to deploy and confidence in doing it securely is not going to close by waiting for the vulnerability class to be solved. It closes by building systems where a successful injection is survivable — which is an architecture problem, and therefore one that has to be settled before the agent ships, not after.
