Five Eyes Just Told Governments to Assume Their AI Agents Will Misbehave: What That Means for Product Security

On May 1, 2026, the cybersecurity agencies of the United States, United Kingdom, Australia, Canada, and New Zealand published "Careful Adoption of Agentic AI Services," the first joint agentic AI security guidance from the Five Eyes alliance. The document's core instruction is blunt: assume your AI agents will behave unexpectedly and plan accordingly. If you ship agents, this guidance reshapes how you scope permissions, handle untrusted input, and think about containment. It is not regulation. Nothing in it is legally binding. But if you've watched how prior Five Eyes guidance (Secure by Design, for instance) migrated into procurement checklists and cyber-insurance questionnaires within eighteen months, you know the trajectory.

Key Takeaways

• The Five Eyes guidance identifies 23 distinct risks across five categories and prescribes over 100 best practices. Its central assumption: agents will misbehave, so architect for resilience, reversibility, and containment rather than trusting model-layer controls alone.
• Prompt injection is called "the most persistent and difficult-to-fix threat" facing agentic systems. No single defense is sufficient. Product teams need to treat this as an architecture problem, not a filter problem.
• Among enterprises that have deployed agents, 88% reported at least one security incident tied to those agents, while 82% of executives believed existing policies already protected them. That gap is where breaches live.
• The guidance takes an "integrationist" posture: extend your existing zero-trust and least-privilege frameworks to agents rather than waiting for purpose-built AI security standards.
• Supply-chain risk in agent tooling (MCP servers, PyPI packages, plugin registries) is a sleeper threat the guidance touches but the industry largely ignores.

What does the Five Eyes guidance actually say?

It identifies five primary risk categories: privilege, design and configuration, behavioral, structural, and accountability. Within those, 23 distinct risks. Over 100 associated best practices. The volume is large, but the posture is simple: assume misbehavior, contain blast radius.

The specific instructions that matter most to product teams:

• Never grant agents broad or unrestricted access.
• Restrict agents to low-risk, non-sensitive tasks by default.
• Enforce least privilege with per-request authentication.
• Require human approval for high-impact actions.
• Manage AI security within existing cybersecurity frameworks, not as a separate discipline.

That last point is the one most teams will underestimate. The agencies are explicitly adopting an integrationist posture: extend zero trust, defense-in-depth, and least privilege to agentic systems now. Do not wait for a purpose-built "AI security standard" to materialize. If you already have a mature identity and access management layer, the guidance says your agent should live inside it, not beside it.

Why does the guidance call prompt injection "the most persistent" threat?

Because current defenses remain immature and no single control is sufficient. The agencies state this flatly. Unlike SQL injection, where parameterized queries largely solved the problem at the parsing layer, prompt injection targets an LLM agent's reasoning layer by embedding adversarial instructions inside trusted data. A webpage. A PDF. A Slack message. A calendar invite. The agent has no structural way to distinguish legitimate operator instructions from malicious ones smuggled through trusted data channels.

This is worth sitting with. Traditional injection attacks exploit a boundary between code and data that a parser fails to enforce. Prompt injection exploits the fact that, for an LLM, there is no such boundary. Instructions and data are the same modality: natural language. Fixing this at the model layer would require the model to reliably distinguish "text the operator intended me to follow" from "text that arrived via a tool call and might contain adversarial instructions." No production model does this reliably today.

Google's threat intelligence team flagged earlier this year that public web pages are being seeded with hidden instructions designed to hijack enterprise AI agents. The indirect variant is especially dangerous: the user never types the malicious prompt. The agent fetches content that contains it.

How bad is the real-world incident rate?

Bad enough to make the confidence gap grotesque. Among enterprises that have deployed agents, 88% reported at least one security incident tied to those agents. Sixty-one percent of incidents involved over-permissioned credentials, confirming the blast radius problem. And the prompt-injection rate? 34%. One in three deployed agents has been hit.

Meanwhile, 82% of executives in a separate survey believed their existing policies already protected them from unauthorized agent actions. Think about that overlap for a second. The same population. Nearly nine out of ten experiencing incidents. More than eight out of ten believing they're covered. That gap is not a "perception problem." It is the current AI security crisis, described in two numbers.

The average organization now manages 37 deployed AI agents. Gartner projects that by year-end 2026, 40% of enterprise applications will integrate task-specific AI agents, up from less than 5% in 2025. Controls are not scaling at the same rate. They are not close.

What should product teams change about permission architecture?

Start with the assumption the guidance makes explicit: your agent will behave unexpectedly. Design the permission surface so unexpected behavior is bounded.

Concretely, this means:

Per-request scoping, not standing access. If your agent holds a long-lived OAuth token with broad scopes, you have already failed the guidance. The agent should request the minimum scope for each action, and that scope should expire. If you are building integrations against APIs that only support coarse-grained tokens, you need a proxy layer that downscopes at the edge.

Human-in-the-loop for irreversible actions. The guidance is direct: require human approval for high-impact actions. "High-impact" is a product decision, but a reasonable starting heuristic is anything that cannot be undone (sending an email, executing a payment, deleting a record, modifying permissions). If your agent can do those things autonomously, you need a confirmation gate.

Audit trails that capture what the agent actually touched. Not what it was asked to do. What it did. What data it read. What APIs it called. What parameters it passed. The guidance emphasizes accountability risk as a top-level category. You cannot have accountability without a log that survives the agent's own reasoning about what it did.

This is where most teams I talk to have a gap. They log the user's prompt and the agent's final response. They do not log the intermediate tool calls, the content the agent retrieved, or the reasoning trace that led to a decision. When an incident happens, they reconstruct from fragments.

Is prompt injection defense a filter problem or an architecture problem?

It is an architecture problem. The guidance implies this strongly, and the incident data confirms it.

The temptation is to treat prompt injection like XSS: add a sanitization layer, run a classifier on inbound content, flag and block suspicious patterns. Teams build these. They help at the margin. But the underlying problem, that the model cannot structurally distinguish instructions from data, means a sufficiently motivated attacker can always find a bypass. The cat-and-mouse dynamic is structural, not temporary.

The guidance's emphasis on containment (least privilege, reversibility, sandboxing) points at a different strategy: assume the injection lands, and limit what it can do. If your agent can only read one document at a time, can only call three specific API endpoints, and cannot escalate its own permissions, a successful prompt injection is annoying, not catastrophic. The attacker can make the agent say weird things. They cannot make it exfiltrate your customer database.

This is the same logic behind defense-in-depth in traditional security: you don't rely on the firewall alone. You assume the firewall will be bypassed and make sure the internal network is segmented, the credentials are scoped, and the data is encrypted at rest. The Five Eyes guidance is telling you to apply that same logic to your agent's capability surface.

We apply this at Selina. Our agent operates on a stack of frontier models, routed per task, and we scope each operation tightly. Memory is encrypted at rest but is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. We say that plainly because pretending otherwise would be dishonest, and because stating the limit is what lets you make an informed decision about what to store. Files and transfers through SelinaSEND are end-to-end encrypted. Non-content operational metadata is kept for a short retention window. The account is protected; content is encrypted. These distinctions matter, and collapsing them into a single marketing claim would be exactly the kind of overstatement the guidance warns against.

What about the supply chain? Is prompt injection the whole threat?

No. And this is the sleeper risk that most coverage of the Five Eyes guidance underplays.

In March 2026, a backdoor sat on the LiteLLM package on PyPI for three hours. LiteLLM is a language-model gateway used by major agent frameworks. Nearly 47,000 downloads occurred during that window. The package delivered an autonomous attack bot. Three hours. Forty-seven thousand downloads.

If your agent framework depends on a package that routes inference calls, and that package is compromised, your prompt injection defenses are irrelevant. The attacker is inside the toolchain. They do not need to smuggle instructions through a webpage; they control the inference pipeline.

This extends the "assume misbehavior" logic from inputs to the entire dependency graph. Product teams shipping agents need provenance and attestation for every tool, every MCP server, every package the agent can invoke. Lockfiles. Signed builds. Dependency scanning that runs on every deploy, not quarterly. The guidance touches this under structural risk, but the practical implication is larger than one section of a government document.

Consider CVE-2026-22708, disclosed against a popular coding agent. The vulnerability let an attacker poison the agent's execution environment so that allowlisted commands (like git branch) could deliver arbitrary payloads. The allowlist, the thing designed to constrain the agent, made the attack easier by auto-approving the commands the attacker needed. This is a useful object lesson in how containment mechanisms can backfire when the threat model is incomplete.

How does this guidance interact with actual regulation?

The Five Eyes guidance is not regulation. Nothing in it carries legal force. But joint Five Eyes guidance has historically become the de facto baseline that auditors, procurement teams, and cyber insurers reference within a year or two. Secure by Design followed the same trajectory. Expect the 23 risks and 100+ best practices to show up in your next SOC 2 auditor's checklist, your enterprise customer's security questionnaire, and your cyber-insurance application.

Separately, the EU AI Act's rules for general-purpose AI models carry enforcement powers from August 2, 2026. Penalties reach €35 million or 7% of worldwide annual turnover for the most serious violations. The Five Eyes guidance and the EU AI Act are not the same thing, but they rhyme: both push toward documented risk assessment, scoped capabilities, human oversight, and audit trails. If you build for one, you are partially building for the other.

OWASP's 2026 State of Agentic AI Security and Governance report reads very differently from the 2025 edition. The 2025 version cataloged plausible threats. The 2026 version catalogs actual CVEs, vendor advisories, and breach reports tied to nearly every category of agentic risk. The shift from theoretical to empirical is complete.

What does "assume misbehavior" look like in a sprint?

Here is what changes if you take the guidance seriously and apply it to a two-week sprint cycle.

Week one: audit your agent's permission surface. List every API endpoint your agent can call. Every data source it can read. Every action it can take without human confirmation. For each one, ask: if the agent were fully compromised by a prompt injection attack right now, what is the worst outcome? If the worst outcome involves PII exfiltration, financial transactions, or permission escalation, you have a containment gap.

Week one, continued: scope down. For each capability that poses unacceptable risk under compromise, either remove it, gate it behind human approval, or restrict it to a narrower scope. This will cost you features. That is the point. The guidance says to prioritize resilience, reversibility, and risk containment over efficiency gains. Efficiency gains are what your product roadmap optimizes for. The guidance is telling you to invert that, at least for high-risk capabilities.

Week two: instrument your agent's tool calls. Every tool invocation should produce a structured log entry: timestamp, tool name, parameters, response summary, user context. Store these logs outside the agent's own memory, in a system the agent cannot modify. This is your accountability layer. When (not if) something goes wrong, this is what you will use to reconstruct what happened.

Week two, continued: review your dependency graph. Pin your versions. Verify your lockfiles. Run a supply-chain scan. Check whether any of your agent's dependencies have had a maintainer change in the last 90 days. This is not glamorous work. It is the work that would have caught the LiteLLM backdoor before it reached production.

Is the "compliance theater" trap real?

Yes. Most coverage of the guidance treats it as a checklist: 23 risks, 100+ controls, check the boxes. That framing misses the document's own admission that current defenses remain immature and no single control is sufficient. A team that deploys a prompt-injection classifier and checks "prompt injection: mitigated" has performed compliance theater. The classifier will catch some attacks. It will miss others. The guidance knows this. It says so explicitly.

The actual signal in the document is architectural. It is telling you that the fix belongs in data minimization, permission scoping, and reversibility, not in model-layer filtering. A model-layer filter is one layer of defense. A useful one. But if your containment strategy is "the filter will catch it," you have a single point of failure, which is the opposite of defense-in-depth.

For us at Selina, this means the interesting design decisions are about what the agent cannot do, not what it can. Bounding capabilities automatically. Keeping cost exposure negligible. Responding fast when something looks anomalous. These are not features we market. They are constraints we enforce, and the Five Eyes guidance validates that posture.

What about nation-state threats? Is that relevant to product teams?

More than you might expect. In September 2025, a Chinese state-sponsored group hijacked coding agent instances to conduct autonomous cyber espionage against roughly 30 targets in defense, energy, and technology sectors. The AI handled 80 to 90 percent of tactical operations independently, discovering and exploiting vulnerabilities at speeds impossible for human operators.

If you are building a product that ships an agent to enterprise customers, your agent is a potential vehicle for this kind of operation. Not because you are a defense contractor. Because your agent has credentials, network access, and the ability to take actions. A compromised agent is an autonomous attacker with your customer's permissions. The Five Eyes guidance is written with this scenario in mind.

You do not need to defend against nation-state actors yourself. But you need to build your agent so that if it is compromised, the blast radius is small. That is the "assume misbehavior" principle applied to the highest-severity threat model.

What should you do this week?

Read the guidance itself. It is surprisingly readable for a government document. Then do three things:

1. Map your agent's blast radius. If the agent is fully compromised right now, what can it access? What can it do? Write it down. If the list makes you uncomfortable, fix the list before you ship the next feature.
2. Add human-in-the-loop gates for irreversible actions. You can always remove them later if the risk profile changes. You cannot undo an email your agent sent to your customer's customer.
3. Instrument your tool calls. Structured logs, outside the agent's own memory, immutable. When the auditor asks what your agent did on March 14th, you need an answer that does not depend on the agent's self-report.

The Five Eyes agencies are not telling you to stop building agents. They are telling you to stop assuming your agents will behave. That is a lower bar than most product teams think, and a higher bar than most product teams clear.

If you want to see how we apply these constraints in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io