Six national security agencies do not coordinate lightly. The list of co-authors on "Careful Adoption of Agentic AI Services" spans the United States (CISA and NSA jointly), Australia (ASD ACSC), Canada (Cyber Centre), New Zealand (NCSC-NZ), and the United Kingdom (NCSC-UK). The document was published on 1 May 2026 and represents the first time this coalition has issued guidance specifically on agentic AI systems.

The timing is deliberate. Agentic AI has moved from pilot into production in critical infrastructure and defence sectors. The guidance does not treat this as a future concern. It opens with the observation that these systems "increasingly operate across critical infrastructure and defence sectors and support mission-critical capabilities." The operative word is increasingly, not eventually.

Five Categories. One That Matters for This Argument.

The guidance organises agentic AI risk into five categories. Four of them (privilege, design and configuration, behavioural, and structural) address the security architecture of agentic systems. The fifth names something different.

Five Eyes Agentic AI Risk Categories | "Careful Adoption of Agentic AI Services," May 2026
1
Privilege
Agents granted excessive access amplify the blast radius of any compromise. A single misconfigured permission can cascade across systems the agent can reach.
2
Design and Configuration
Poor setup creates security gaps before a system goes live. Boundary conditions, tool access lists, and prompt constraints must be defined at design time.
3
Behavioural
An agent may pursue its goal in ways its designers never intended or predicted. Goal hijacking, prompt injection, and emergent behaviour all fall here.
4
Structural
Networks of interconnected agents can trigger failures that spread across an organisation's systems in ways no single-agent analysis predicts.
5
Accountability
Agentic systems make decisions through processes that are difficult to inspect and generate logs that are hard to parse, making it difficult to trace what went wrong and why. When these systems fail, the consequences are concrete: altered files, changed access controls, deleted audit trails.
The governance gap this series has been tracking
Figure 1. The five risk categories from the Five Eyes guidance. Category five names accountability as a distinct structural problem, not a logging configuration issue.

The accountability category is worth reading precisely. The agencies describe agentic systems as making decisions through processes that are "difficult to inspect" and generating logs that are "hard to parse," making it difficult to trace what went wrong and why. This is not a technology complaint. It is a governance observation: the evidentiary chain that a regulatory examination would require does not exist by default in agentic deployments.

What the Guidance Recommends, and Where It Stops

The guidance's recommendations are primarily security controls: least-privilege access, cryptographically secured agent identities, short-lived credentials, human approval gates for consequential actions, continuous monitoring, and audit logging. These are the right controls. They address the conditions under which a governed deployment is possible.

What the guidance does not address is the organisational question: who, inside a regulated product organisation, is accountable for ensuring those controls are implemented and maintained as an ongoing documented commitment? The guidance tells organisations what to build. It does not specify who carries the accountability for what the built system does.

The boundary of the Five Eyes guidance
What the guidance specifies
Never grant agents broad or unrestricted access to sensitive data or critical systems
Each agent should carry a verified, cryptographically secured identity with short-lived credentials
Require human approval before agents execute consequential or irreversible actions
Continuously monitor agent behaviour: inputs, tool calls, internal reasoning, decisions, outputs
Quarantine any agent request to delete logs until a human approves it
What the guidance leaves open
Which organisational function carries accountability for what the agent does at runtime
What the documented, ongoing commitment looks like as a governance artefact
How design-time decisions are connected to runtime monitoring as a continuous evidentiary chain
What a regulatory examination of an agentic deployment would ask to see, and from whom
Whether the product function has the structural conditions to exercise accountability it carries by default
The guidance defines what to build. The accountability question is who carries it.
Figure 2. The guidance addresses security architecture. The governance accountability question | who owns runtime behaviour as a documented commitment | remains outside its scope.

This boundary is not a criticism of the guidance. Security agencies do not govern internal organisational accountability structures. But the gap it leaves is exactly where regulated financial services organisations are most exposed. DORA, the EU AI Act, and ECB supervisory priorities all assume that someone inside the deploying organisation can demonstrate accountable oversight of what an AI agent does. The Five Eyes document confirms the technical conditions required. It does not create the accountability architecture.

Where the Three Conditions Map to the Guidance

The three structural conditions this series has argued for as the minimum requirements for exercised accountability map directly onto what the guidance's accountability category requires and does not supply.

The three conditions and where the guidance lands on each
4iGov | structural condition
Five Eyes guidance | position
Condition 1
Design-Time Authority
The product function documents what the agent is permitted to do before deployment, as a record that can be audited | not a policy sign-off.
→
Guidance position
Partially addressed
Guidance specifies least-privilege configuration and design-time boundary setting. Does not specify who documents it or how it becomes an auditable record.
Condition 2
Monitoring Mandate
A named owner continuously monitors the gap between documented parameters and runtime behaviour. This must be a person, not a team.
→
Guidance position
Technical layer specified
Guidance specifies continuous monitoring of inputs, tool calls, reasoning, decisions, and outputs. Does not specify who holds the mandate or how it is named.
Condition 3
Evidentiary Chain
A connected artefact links design intent, monitored behaviour, and actual runtime decisions | available under regulatory examination.
→
Guidance position
Named as the core gap
Accountability category explicitly describes the absence of this chain: decisions difficult to inspect, logs hard to parse, consequences hard to trace. The guidance names the problem. The artefact is not defined.
Figure 3. The guidance addresses the technical conditions under which an evidentiary chain could exist. It does not specify the chain itself, nor who is responsible for maintaining it.

The guidance is explicit that "security practices and standards are still maturing." For regulated financial services organisations, this is not a deferral. DORA and the EU AI Act do not wait for security practices to mature. They assume accountable oversight is already in place. The product function carries that accountability by default, not because it has been formally assigned, but because no other function holds the complete view of what the agent was built to do, what it is doing, and what the gap between those two looks like.

The question the Five Eyes guidance answers is: what does a governed agentic AI system look like from a security architecture perspective? The question it leaves for regulated product organisations is: who, specifically, is accountable for that architecture as an ongoing documented commitment, and what does that accountability look like under examination?

Download this article Save or share as a PDF. Free to use with attribution to 4iGov.