Five Eyes Agentic AI Guidance: An Implementation Checklist for Defenders

In May 2026, six government cyber agencies published “Careful Adoption of Agentic AI Services.” CSA summarizes the stance as: assume agentic systems will behave unexpectedly, and design accordingly.

We could not open the primary PDF from our environment. Everything below attributed to the guidance comes from the Cloud Security Alliance’s published summary of it, and we mark CSA’s own additions separately. Read the original before you cite it in a policy document.

What the guidance is

According to CSA’s research note of May 19, 2026, the document was finalized on April 30 and released on May 1, 2026. Per CSA, the publishers are CISA and NSA in the US, ASD’s ACSC in Australia, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. We could not confirm from the primary document whether it is binding or numbered. CSA says it carries meaningful policy weight beyond a standard government advisory and that compliance expectations will continue to harden.

It sorts agentic risk into five categories, in CSA’s paraphrase:

• Privilege: agents hold broader access than their tasks need, so a compromised agent hands an attacker that access.
• Design and configuration: weak architecture before any real input arrives, such as broad API scopes, poor input and output validation, or no isolation from sensitive data.
• Behavioral: agents reach objectives by unintended means, including specification gaming.
• Structural: a compromised component in a multi-agent pipeline can pass poisoned output or instructions downstream.
• Accountability: multi-step tool use does not fit conventional logging, so incident reconstruction is hard.

From principle to control

The useful part is that most asks translate into controls you can test. The mapping below is ours, not the agencies’.

Identity: one agent, one identity

CSA paraphrases the guidance as saying agents should be treated as untrusted identities provisioned only with the minimum access required for each specific, time-bound task, and that each agent or agent instance should hold a distinct cryptographic identity. In practice that rules out the common pattern where five agents share one service account and one API key.

What to build:

1. Issue a workload identity per agent instance, from your existing identity provider or SPIFFE-style tooling.
2. Authenticate agent-to-agent calls. An agent should refuse instructions from a peer it cannot verify.
3. Make the identity visible in every downstream log line, so a database audit entry names the agent and not the platform.

Credentials: short-lived and task-scoped

The guidance, again per CSA, calls for short-lived credentials scoped to the active task and rotated automatically when the task ends. Long-lived tokens in agent configuration files are the opposite of this. They are also what attackers look for first.

Test it: pick an agent and try to use its credential an hour after the task finished. If the call succeeds, you have found a gap. CSA separately suggests auditing existing service accounts and API keys to narrow or revoke excess access. That audit step is CSA’s suggestion, not the agencies’.

Human approval enforced by architecture

CSA reports the guidance treats human approval for irreversible or high-impact actions as a required control, with examples such as financial transactions, access-control changes and external communications sent on a user’s behalf. It also says approval should be enforced in the architecture, not as advisory guardrails the agent can reason around.

That distinction matters. A system prompt that says “ask before deleting” is a request. A tool gateway that returns a pending state until a human token is presented is a control. Put the gate in the tool layer, outside the model’s context, and log the approver.

Logging before deployment

The guidance asks for logging of agent inputs, outputs, reasoning steps, tool calls, privilege changes and approval events before an agent goes live, according to CSA. CSA places baseline monitoring of tool-call patterns and output filtering under its prompt-injection discussion, so we treat those as separate controls.

A minimum viable record per tool call: agent identity, task or session ID, tool name, arguments, result status, approval reference and a timestamp. Without the session ID you cannot reconstruct a multi-step chain, which is the accountability problem the guidance names.

Phased rollout

As CSA summarizes it, the guidance recommends starting with low-risk, low-sensitivity use cases and restricted permissions, then widening. CSA adds its own advice to run a documented security review at each expansion step.

Where the guidance may be thin

CSA presents logging as a prerequisite for incident response. We did not find containment steps for a hijacked agent in CSA’s summary and could not check the primary document, so what follows is our own recommendation, not the agencies’. Plan it yourself: a kill switch that revokes an agent’s identity, a way to quarantine its tool access, and a runbook for reviewing what it touched.

Forrester’s AEGIS framework claims alignment with the guidance. Per CSA, that is Forrester’s own characterization rather than a joint statement from the agencies.

Where to start this week

1. Inventory every agent and list the credentials each holds.
2. Replace shared accounts with per-agent identities.
3. Identify the five most destructive actions any agent can take and put an approval gate in front of them.
4. Turn on tool-call logging with agent identity and session ID.
5. Run an adversarial prompt exercise against one agent before widening its scope.

None of this requires new products. It requires treating an agent as an untrusted workload that happens to be useful.

References

• CSA research note: Agentic AI Adoption, Implementing the Five Eyes Framework (May 19, 2026)
• CSA research note: Forrester’s AEGIS Framework, A Controls Baseline for Agentic AI
• Australian Cyber Security Centre: Careful Adoption of Agentic AI Services (PDF, primary source, not opened by us)