If you build with autonomous agents — tool-calling LLMs, multi-agent workflows, agents that read memory and act on it — you have probably been improvising the security model. The threat lists are young, the standards are unsettled, and most teams are stitching together their own playbook. So it is worth noticing when six national cyber agencies converge on the same set of risks.
On May 1, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) published Careful Adoption of Agentic AI Services, co-authored with five partner agencies: Australia's Signals Directorate (ASD's ACSC), the Canadian Centre for Cyber Security, New Zealand's National Cyber Security Centre, and the UK's National Cyber Security Centre. It is the first joint cybersecurity guidance the Five Eyes nations have issued specifically about agentic AI — systems where one or more LLM-powered agents interpret information, make decisions, and take actions on their own.
What it actually is
The document is guidance, not a binding standard. It carries over 100 recommendations for organizations that design, develop, deploy, and operate agentic systems, with extra attention to critical infrastructure and defense. The framing is deliberately cautious. Until evaluation methods and standards mature, the agencies argue, organizations should assume agentic systems may behave unexpectedly and plan accordingly — "prioritising resilience, reversibility and risk containment over efficiency gains."
Translation for practitioners: design for the agent doing the wrong thing, and make sure you can undo it.
The five risk categories, in plain language
The guidance organizes agentic-AI risk into five broad categories.
- Privilege. An agent granted more access than it needs. When a single agent is compromised, broad permissions multiply the blast radius fast.
- Design and configuration flaws. Poor setup that opens security gaps before the system ever goes live — the agentic equivalent of a misconfigured bucket.
- Behavioral risk. The agent pursues its goal in ways its designers never intended or predicted. The model is steerable by its own inputs, so "what it was told to do" and "what it actually does" can diverge.
- Structural risk. Interconnected networks of agents where a single fault propagates and cascades across an organization's systems.
- Accountability. The complexity and opacity of agentic systems makes it hard to trace decisions, audit actions, or assign responsibility — especially when things happen autonomously and at scale.
The throughline is that none of this requires a brand-new security discipline. The agencies are explicit that established principles — zero trust, defense-in-depth, and least-privilege access — apply directly. Agents get verified cryptographic identities, short-lived credentials, and scoped permissions, the same way any other actor in a zero-trust architecture would.
Why it matters
Two things stand out beyond the recommendations themselves.
First, independent corroboration of how to decompose the problem. Six agencies, working separately, landed on roughly the same way to slice agentic risk: privilege, design and configuration, behavior, structure, accountability. When several groups reach the same decomposition without coordinating on a single vendor's model, that is a signal the decomposition is capturing something real rather than reflecting one team's house style.
Second, it folds agents into existing practice rather than declaring them exceptional. The message is not "throw out your security program and start over." It is "your zero-trust and least-privilege muscles already apply — now point them at a non-deterministic actor." That is a far more actionable posture than treating agents as a category that defies your existing controls.
The practitioner takeaway
Use the five categories as a threat-modeling lens, then translate each into a control you already know how to build. Walk your architecture once per category and ask the same question each time: where does this show up, and what contains it?
- Privilege becomes scoped, short-lived credentials and per-tool permission grants — not a shared service account the agent inherits.
- Design and configuration becomes config review and secure defaults applied to agent setup, not just to the surrounding infrastructure.
- Behavioral becomes guardrails on tool calls, output validation, and human-in-the-loop on irreversible actions.
- Structural becomes blast-radius limits and circuit breakers between agents so one bad output does not cascade.
- Accountability becomes logging and traceability that can reconstruct why an agent did what it did, after the fact.
What the guidance deliberately does not do is hand you those controls. It names the risk and points you at established principles; the engineering judgment of turning "apply least privilege" into a working permission boundary for your specific agent is yours. That gap between "here is the risk" and "here is the fix" is exactly where the work lives — and it is worth being deliberate about.
This guidance is one of the sources behind *BRACE*, an open, vendor-neutral framework for securing autonomous AI agents — its privilege / design-config / behavioral / structural / accountability categories line up closely with BRACE's five concerns (Build-time, Configuration, Run-time, Ecosystem, Agent). BRACE is built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?
Top comments (0)