Five Eyes agencies say most agentic AI deployments are already too permissive
On May 1, 2026, CISA, the NSA, and their counterparts from the UK, Australia, Canada, and New Zealand published the first coordinated multigovernment security guidance for agentic AI: "Careful Adoption of Agentic AI Services." The core message is blunt — critical infrastructure and defense organizations are not evaluating a future risk, they are already running agents with more access than their own security teams can account for, and the guidance exists because that gap has stopped being theoretical.
What makes this document worth reading closely, even if you're not in critical infrastructure, is that it's the first attempt by security agencies to formally categorize what can go wrong with an AI agent — as opposed to a traditional application — and the categories map cleanly onto mistakes most teams deploying agents right now are already making.
Five risk categories, and why they don't reduce to "prompt injection"
The guidance splits agentic AI risk into five categories: privilege, design and configuration, behavior, structural, and accountability. That's a deliberately broader frame than the security industry's default focus on prompt injection and jailbreaks, and the reasoning is straightforward — an agent with narrow, correctly-scoped privileges is far less dangerous even when successfully manipulated, because the manipulation has nowhere to go.
Privilege risk is about agents holding standing access to systems, data, or actions well beyond what any single task requires — the AI equivalent of a service account with domain admin because nobody got around to scoping it down. Design and configuration risk covers agents wired into tool chains and external data sources without anyone mapping what that interconnection actually exposes. Behavior risk is the agent doing something unintended even without external manipulation — an emergent action nobody explicitly programmed. Structural risk concerns the layered dependencies agents introduce (a compromised tool or data source becomes a compromised agent). Accountability risk is the hardest to retrofit: when an agent takes a consequential action, can anyone reconstruct why, and who is responsible for it having happened.
The interconnected attack surface problem
The guidance is explicit that agentic AI's core security problem isn't the model — it's the number of components an agent typically touches. A single customer-support agent might call a CRM API, a knowledge base, a ticketing system, and an email tool, each with its own credentials and failure modes. The document warns that this creates "an interconnected attack surface that malicious actors can exploit," because compromising any one link in that chain can compromise the agent's effective permissions across all of them.
This is precisely the pattern behind the more severe AI-agent security incidents disclosed this year — attackers don't need to break the model itself when they can compromise one weakly-secured tool integration and inherit whatever access the agent has been granted.
What the guidance actually tells you to do
Strip away the framing and the operational core is five rules, all of which are enforceable today with existing identity and access tooling:
Never grant agents broad or unrestricted access. If an agent's service account can do more than its documented task list requires, that's the gap attackers will use — and it's usually a gap created by convenience during initial rollout, not a deliberate decision.
Restrict agents to low-risk, non-sensitive tasks by default, and require an explicit, reviewed exception to expand scope — inverting the common pattern of granting broad access up front and narrowing it later (which rarely actually happens).
Enforce least privilege with per-request authentication, not a single standing credential the agent holds for its lifetime. Every tool call should be independently authenticated and scoped, so a compromised session doesn't inherit blanket access.
Require human approval for high-impact actions — financial transactions, data deletion, access-control changes, anything that's expensive or hard to reverse. The guidance treats this as non-negotiable rather than a nice-to-have for early deployments.
Manage AI agent security inside existing cybersecurity frameworks, not as a parallel, bespoke program. Agents should show up in the same asset inventories, access reviews, and incident response playbooks as any other system component with credentials and network access.
The takeaway for teams shipping agents this quarter
If you're deploying an AI agent into production and you can't answer "what is the maximum blast radius if this agent's session is compromised right now," the Five Eyes guidance says you have a privilege problem, not a model problem. Run an access audit before your next agent rollout: list every tool, API, and data source the agent can reach, then ask whether each one is scoped to the narrowest task-specific permission rather than a broad service-level grant. That single exercise closes the gap most incident post-mortems this year have in common.