Prompt injection: when your AI agent obeys an attacker

AI agents increasingly do more than suggest. They act: they send emails, run code, and reach into company systems. That changes the nature of the risk. A single planted instruction, hidden in an email, a document, or a web page, can push an agent into an action nobody authorized. On 1 September 2026 Anthropic published the system card for its Claude Fable 5.1 and Claude Mythos 5.1 models, reporting resistance to indirect prompt injection as a measurable metric. For boards and managers, that marks a plain shift: agent security stops being an abstract topic and becomes a number you can ask a vendor for, and a decision about what the agent can do at all.

What happened

On 1 September 2026 Anthropic released the system card for Claude Fable 5.1 and Claude Mythos 5.1. What matters is how it describes security. Resistance to prompt injection is given as a number, broken out by attack surface, by the number of attempts an attacker makes, and by whether safeguards are enabled. Mythos 5.1 is described as Anthropic's most robust model to date on the external indirect prompt injection benchmark.

The significance goes beyond a single model. Until now, the question "how hard is it to hijack this agent" had no common answer. Anthropic shows it can be stated in a form you can compare across models and configurations. The data also carries a sober lesson: a single attempt rarely succeeds, but success climbs as an attacker keeps trying, and enabling safeguards sharply lowers the risk without removing it.

This is not an isolated signal. Back in December 2025, describing how it hardens its Atlas browser agent, OpenAI stated that prompt injection is unlikely to ever be fully solved, that agent mode expands the attack surface, and that even sophisticated defenses cannot offer deterministic guarantees. In other words, the model vendors themselves say this risk cannot be removed, only contained.

Why it matters for business

Prompt injection stops being a technical curiosity the moment an agent gains the right to act. As long as a model only replies with text, a planted instruction is at worst a bad answer. Once an agent can send an email, issue an invoice, pull data, or change a record, that same instruction becomes an action with real consequences.

The scale is rising too. Gartner predicts that by the end of 2026, up to 40% of enterprise applications will include task-specific AI agents, up from less than 5% in 2025. Every one of those agents with the right to act enlarges the surface that has to be watched.

What matters most is where the decision sits. Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous agents due to governance gaps identified only after production incidents. Gartner analyst Shiva Varma notes that companies treat agent governance as binary, either locked down or fully trusted, and that this is the root cause of failure. Controls that are too loose raise the risk, controls that are too rigid slow the work and push people toward tools outside the company's reach. Agent security is therefore a management decision about the scope of permissions, not just a task for IT.

Business use cases

The examples below show where prompt injection risk maps onto a concrete process and what decision it forces.

A customer-service agent reading external messages

Business problem: The agent handles email queries and tickets by reading content the customer sends. A message with a planted instruction can slip in among them.

AI solution: The agent reads the ticket, classifies it, and drafts a reply, but does not carry out actions with external consequences, such as changing customer data or issuing a refund, on its own.

Data and processes to put in place: Separating customer content, treated as untrusted, from system instructions. A list of actions allowed without human sign-off. An escalation path for sensitive actions.

Potential effect: Faster handling of routine tickets while keeping control over what the agent may do unattended.

Risk and limitation: Indirect prompt injection hidden in the ticket body or an attachment. An agent with the right to modify a customer account is the most exposed point here.

A coding and DevOps agent that runs code

Business problem: The agent generates and runs code and has access to repositories, keys, and infrastructure. A planted instruction can push it to leak secrets or change a production environment.

AI solution: Running code in an isolated environment that enforces which files and network resources the agent may reach, regardless of what the generated instruction tells it to do.

Data and processes to put in place: An OS-level execution container, for example Microsoft MXC, whose process isolation GitHub Copilot CLI has already adopted. Separating secrets from the context the agent can see. Reviewing changes before they reach production.

Potential effect: Keeping the team's pace while limiting the damage if the agent is hijacked.

Risk and limitation: Over-broad agent permissions and secrets available in the same context in which the agent reads untrusted data.

A web-browsing agent doing research

Business problem: The agent gathers information from the internet for analysis, proposals, or market monitoring. A visited page can carry a hidden instruction.

AI solution: The agent reads and summarizes content but does not take actions in company systems based on it without confirmation. Choosing a model with higher, documented resistance to indirect prompt injection.

Data and processes to put in place: Separating the content-gathering phase from the acting phase. An allow-list of domains. A model's resistance metric as a vendor-selection criterion.

Potential effect: Cheaper, faster research without opening a door to company systems through an external page.

Risk and limitation: Resistance without safeguards can be weak and only improves once they are enabled. A vendor's default configuration is not always the most secure one.

A finance and procurement agent with system access

Business problem: The agent supports invoice, payment, or order flows and reaches into accounting systems and inboxes. A planted document can try to redirect a payment or a data export.

AI solution: The agent prepares the transaction and fills in the data, but approving a payment or a send requires a human. Amount limits and thresholds above which an action is held.

Data and processes to put in place: A rule requiring confirmation for high-impact actions. Limits and alerts. Logging of every action, with a record of who ordered what.

Potential effect: A shorter document cycle while keeping control over money and data movements.

Risk and limitation: An invoice or email carrying a hidden instruction. Without an approval threshold and logs, a hijacked agent acts without a trace until the effect surfaces.

What companies can do now

The starting point is the same for a large and a small organization: agent security is not a matter of a better incantation in the prompt, but of what the agent can do at all.

1. Grant permissions on a least-privilege basis. The agent gets access only to the systems and actions its task requires. Everything else is closed by default.
2. Name the actions that require a human. A payment, an outbound send, a change to a production system, and a data export are thresholds where the agent proposes and a person decides.
3. Treat external content as untrusted. An email, a document, a page, and a knowledge-base entry are not an instruction, even when they read like one. Keep them separate from system instructions.
4. Run the agent in an environment that enforces boundaries. An execution container like Microsoft MXC imposes limits regardless of what the generated instruction says.
5. Turn on logging and a kill switch. Every agent action should leave a trace, and the company should have a way to stop the agent mid-task.
6. Make resistance a purchasing criterion. Ask the vendor for prompt injection success rates broken out by surface, number of attempts, and safeguards, and choose what is measurable.
7. Name an owner. A specific person, not a team, must be accountable for the scope of permissions and for the incident response.

Measurability is a condition here, not an extra. If a company does not log the agent's actions and does not know its permissions, it cannot judge whether a deployment is safe, nor reconstruct what happened after an incident.

Risks

Data security. The most common outcome of a hijacked agent is a leak. An agent with broad access and no separation of secrets from context is a ready-made exfiltration channel.

Shadow AI. Controls that are too rigid push teams toward tools outside the company's reach. Then agents run on company data with no limits and the organization does not even know. Gartner directly links over-restriction to fueling this.

Cost. Safeguards, isolation, and human review cost time and money. Skipping them is cheaper until the first incident, whose cost is often many times higher.

A flawed deployment. An agent bolted onto a process without permission limits looks like a success until the day it carries out someone else's instruction. A working agent is not proof that it is a safe one.

No process owner. If nobody is accountable for the agent's permissions and for incident response, decisions about its scope of action are made by accident or not at all.

No quality control of outputs. An agent that nobody checks can run wrong, or under the direction of planted content, for a long time before the effect becomes visible. Logging and approval thresholds are the only safety net here.

Key takeaways

Prompt injection is not a passing bug that the next update will patch. The model vendors themselves say the risk cannot be removed, only contained.

The shift on 1 September 2026 is practical: an agent's resistance to being hijacked becomes a number you can ask for and compare. That moves the conversation from claims to data.

For a company, that means three decisions. Limit the agent's permissions to what is strictly needed. Put a human on high-impact actions. Choose vendors who report measurable resistance rather than reassurance. Agent security starts with the question "what can this agent do", not "what do we tell it to do".