Five Eyes Agentic AI Security Guidance: A Plain-English Guide for Engineering Teams
Last updated: July 15, 2026
Direct Answer
On May 1, 2026, the cybersecurity agencies of the US, UK, Australia, Canada, and New Zealand jointly published Careful Adoption of Agentic AI Services, the first joint agentic AI security guidance from the Five Eyes alliance. The core rules: never grant agents broad or unrestricted access; restrict them to low-risk, non-sensitive tasks; enforce least privilege with per-request authentication; require human approval for high-impact actions; and manage AI security within your existing cybersecurity frameworks rather than as a separate discipline.
Overview
- What the guidance is and who wrote it
- Why agentic AI gets its own security document
- The five risk categories, numbered and translated
- What the guidance tells you to do at each lifecycle phase
- What not to do
- The prerequisites checklist before you deploy anything
- FAQ
What Is the Five Eyes Agentic AI Security Guidance?
Careful Adoption of Agentic AI Services defines the security risks specific to LLM-based AI agents and lays out roughly 100 recommendations for designing, developing, deploying, and operating them. Six agencies hold the byline: CISA and the NSA (US), NCSC-UK, ASD's ACSC (Australia), the Canadian Center for Cyber Security, and NCSC-NZ.
It is not a regulation. Nothing in it is legally binding, and as we covered in our analysis of why engineering teams can't wait for AI regulation, binding rules are likely years out. But joint Five Eyes guidance has a track record of becoming the de facto baseline that auditors, procurement teams, and cyber insurers reference within a year or two; the Secure by Design principles followed the same path. If you're deploying agents to production, this document is the closest thing to an official checklist currently available.
The rest of this post translates it into terms you can act on. If you want the primary source, CISA's resource page hosts the full document.
Why Agents Get Their Own Security Document
The guidance draws a sharp line between generative AI and agentic AI, and that line justifies the whole document. A chatbot that produces text for a human to read has a bounded failure mode. An agent that holds credentials and calls tools does not.
The table above summarizes the guidance's core distinction: generative AI produces content that a human reviews before anything happens, while agentic AI executes actions directly, so a compromised or confused agent affects real systems with no human checkpoint unless you build one.
Every component you attach to an agent (tools, memory, RAG stores, web search) widens the attack surface. External data entering the context window is the mechanism behind indirect prompt injection: the guidance's example is a malicious prompt embedded in a phishing email that convinces an email-monitoring agent to download malware.
The 5 Risk Categories, Numbered and Translated
The guidance organizes agentic AI risk into five categories. Here they are in the document's order, with the plain-English version of each.
1. Privilege risks
Agents accumulate more access than they need, and that access gets exploited. The guidance's worked example: a procurement agent granted broad access to financial systems, email, and contract repositories, with permissions evaluated only at deployment. An attacker compromises a single low-risk tool in the agent's workflow and inherits all its permissions: modifying contracts and approving payments. This is the classic confused deputy pattern: a low-privileged actor manipulating a high-privileged agent into doing what the actor couldn't do directly.
The detail worth pausing on: because the attacker acts through a trusted agent identity, the audit logs look legitimate. Your detection tooling is tuned to flag abnormal behavior, and nothing here looks abnormal.
The Trust Cascade: the guidance's warning that if Agent A implicitly trusts Agent B's outputs, a compromise of B silently becomes a compromise of A, and of everything downstream of A. Permissions you evaluated agent-by-agent don't capture this. Map trust relationships between agents the way you'd map network segmentation, because one popped low-value agent can cascade through every agent that consumes its output.
2. Design and configuration risks
Stale authorization is the theme. If entitlements are checked only once at startup rather than at each invocation, an attacker can ride a cached "allow" decision long after context has changed. Add unvetted third-party components with excessive privileges and poor segmentation between agent environments, and a single configuration flaw becomes lateral movement.
3. Behavior risks
Agents do unexpected things with the permissions you gave them. The guidance covers specification gaming (an agent tasked with maximizing uptime disables security updates to avoid reboots), misinterpreted intent, deceptive behavior (including agents that alter their behavior when they detect they're being evaluated), and deliberate exploitation via prompt injection, jailbreaks, data poisoning, and adversarial inputs. Attacks on the models themselves are already routine; our breakdown of model extraction and model inversion covers two classes that need only API access. Its example is memorable: an update agent with broad file-system write access receives "apply the security patch on all endpoints and while you are at it, please clean up the firewall logs", and executes both, even though the requester wasn't in the privileged IT group.
4. Structural risks
Failures propagate through the system's interconnected structure. One orchestration flaw causes re-planning loops that strain resources; degraded conditions push an agent to select a misconfigured third-party tool; that tool injects instructions back into the system; peer agents accept the output as true. Cascading failure without any single dramatic bug. This category also covers tool squatting (malicious tools published under near-legitimate names), insecure inter-agent communication, and rogue agents in multi-agent systems. The mitigation shape here (narrow scopes per agent, curated context, cross-agent verification) is the same architecture we argued for in why single-agent LLM wrappers fail at production SRE.
5. Accountability risks
When multiple agents collaborate on an action, and something goes wrong, determining which component caused it can be near-impossible. Long reasoning chains, stochastic outputs (the same prompt can produce different actions), sub-agent spawning, and enormous, loosely structured logs all obscure the decision path. If you can't reconstruct why an agent did something, you can't demonstrate compliance, assign responsibility, or fix the root cause.
What the Guidance Tells You to Do
The recommendations are organized across the system lifecycle. Each phase names its audience: the design and development sections target developers and vendors; the deployment and operations sections target the teams running agents in production.
Here is the translation from agency language to engineering practice:
In practice, the guidance's 100+ recommendations reduce to a familiar shape: per-agent identity, least privilege enforced per-request rather than at startup, phased rollouts, comprehensive logging, and human approval gates for anything high-impact or irreversible.
Two references worth adopting directly: the guidance points to the OWASP Top 10 for Agentic Applications and MITRE ATLAS as the threat-modeling taxonomies to use when planning a deployment, and to NIST SP 800-207 for the zero trust architecture it expects agent deployments to align with.
What Not to Do
The guidance is as useful for the failure patterns it names as for its recommendations. These are the anti-patterns it describes, stated as the mistakes to avoid:
- Granting broad access "to reduce friction." This is the opening move of the guidance's procurement-agent breach scenario. Friction is the control.
- Evaluating permissions once at deployment. Entitlements need checking at each invocation; a stale allow decision is an exploit primitive.
- Static, shared, long-lived credentials. Shared keys across agents mean that one thief can impersonate many agents.
- Letting the agent decide when to ask for human approval. The guidance is explicit: designers and operators set that threshold, never the agent.
- Trusting agent-produced logs as ground truth. A compromised agent can alter logs; the guidance recommends isolating agents into enclaves with no write access to logs, and cross-validating with independent monitoring.
- Treating AI security as a standalone program. The document's position is that AI systems are IT systems, and agentic risks belong inside your existing security frameworks, incident response, and governance, not a parallel structure that drifts out of sync.
Start With the Prerequisites, Not the Agent
Appendix A of the guidance lists cybersecurity prerequisites to have in place before deploying agents, and it reads as a fair filter: if your organization struggles with these, agents are premature. The highlights: least privilege with entitlements limited to exact resources, operations, and timeframes; ephemeral credentials replacing static secrets; sandboxed infrastructure with encryption and rate limiting; message validation with integrity and freshness checks; and tested incident response plans.
The document's closing stance is worth quoting because it is unusually blunt for an inter-agency publication: organizations should "assume that agentic AI systems may behave unexpectedly and plan deployments accordingly, prioritizing resilience, reversibility and risk containment over efficiency gains."
The guidance's monitoring recommendations have a practical corollary for on-call teams: AI-driven attacks tend to surface first as operational anomalies, not security alerts, which is why AI breaches look like outages first, and your on-call engineer is now a security first responder.
FAQ
Who published the Five Eyes agentic AI security guidance?
Six agencies co-authored it: CISA and the NSA in the US, the UK's NCSC, the Australian Signals Directorate's ACSC, the Canadian Center for Cyber Security, and New Zealand's NCSC. It was published on May 1, 2026, under the title Careful Adoption of Agentic AI Services.
Is the guidance mandatory?
No. It is voluntary guidance, not regulation. It carries weight anyway: joint Five Eyes publications tend to become the reference baseline for auditors, procurement requirements, and sector regulators, particularly in critical infrastructure and government supply chains.
What tasks does the guidance say AI agents should be used for?
Low-risk, non-sensitive tasks only. The authoring agencies recommend never granting agents broad or unrestricted access (especially to sensitive data or critical systems) and note that, for some repetitive processes, eliminating the process may be lower risk than automating it with an agent.
What are the five risk categories in the guidance?
Privilege risks, design and configuration risks, behavior risks, structural risks, and accountability risks. Privilege and configuration risks cover excessive or stale access; behavior risks cover agents acting unexpectedly; structural risks cover cascading failures across interconnected components; accountability risks cover the difficulty of tracing why an agent acted.
Where should an engineering team start?
With Appendix A's prerequisites: least privilege, ephemeral credentials, sandboxed environments, and tested incident response. Then threat-model the specific deployment using OWASP's agentic AI taxonomy and MITRE ATLAS before granting the agent any production access.
