Careful Adoption of Agentic AI Services: Five Eyes Guidance Guide

Organisations are connecting LLM-based agents to email, code, payments and infrastructure faster than they can govern them, and the Five Eyes cyber agencies have now said plainly that this should be done carefully, narrowly and reversibly. Careful Adoption of Agentic AI Services was published on 1 May 2026 by CISA, NSA, the Australian Signals Directorate's ACSC, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. It is joint guidance, not law, but it is co-sealed by cyber agencies of all five countries and it will shape procurement questions, assessor expectations and supplier contracts. This guide sets out what the guidance says, turns its five risk categories and four lifecycle phases into controls you can test, and maps them to frameworks you already use. It is for CISOs, security architects, IAM teams and anyone approving an agent deployment.

Source note: guidance content comes from the Canadian Centre for Cyber Security web edition, with publication details from CISA and NCSC-NZ, checked 11 November 2026. Mappings are NHI Mgmt Group analysis. Confirm against the official text before relying on it.

Key takeaways

• Adopt slowly and start small. The agencies advise limiting agentic AI to low-risk, non-sensitive tasks, never granting it broad or unrestricted access to sensitive data or critical systems, and considering simpler non-AI automation for repetitive work.
• Every agent is its own principal. The guidance asks for each agent to be a distinct, cryptographically anchored identity, with mutual TLS between agents and services, a trusted registry, and denial of unregistered agents or keys.
• Five risk categories frame the problem. Privilege, design and configuration, behavioural, structural and accountability risks, each illustrated with a scenario such as an update agent manipulated into deleting firewall logs.
• Humans decide where approval is needed, not the agent. High-impact actions such as system resets, network egress and deletion of critical records need prior human approval, and requests to delete logs or audit records should be quarantined for review.
• Resilience over efficiency. The conclusion asks organisations to assume agents may behave unexpectedly and to prioritise resilience, reversibility and risk containment over efficiency gains.

What the guidance is and who wrote it

The guidance defines agentic AI as systems of one or more agents that rely on an LLM to interpret their environment, make decisions and take actions, often without continuous human input, and notes that agents may spawn sub-agents. It contrasts this with generative AI, which produces content for a human to use. Its central position is that AI security is part of cyber security: agents should be governed inside existing frameworks using secure by design, defence in depth, identity and access management, continuous monitoring and incident response, not in a parallel programme. See the AI Agents vs Agentic AI explainer.

The five risk categories

Before the risk categories, the guidance lists broader considerations: agents inherit LLM weaknesses such as prompt injection, every tool, data source and memory store widens the attack surface, failures cascade across steps, and agents may behave differently under evaluation while standards and tooling remain immature.

The behavioural scenario of an agent deleting firewall logs and the guidance's checkpoint on deletion of critical records have a real counterpart in the PocketOS database deletion, where a coding agent used an over-privileged token to wipe production. See the Agent Threats and Attacks Guide.

Best practices across the lifecycle

Design (developers)

• Controlled context: a clear instruction hierarchy, grounding through retrieval, and weighting of data sources by trust level.
• Oversight built in: low-risk agents must not escalate themselves into higher-risk activity; provide live monitoring and interruption, mandatory approval points, auditing and reversibility, with explicit control flows.
• Identity: each agent a distinct principal, mutual TLS for agent-to-agent and agent-to-service calls, a trusted registry reconciled periodically, role-based minimum permissions.
• Defence in depth: secure every entry and exit point (user input, tool calls, pre-processing, inference) and separate agents by function with strict hand-off boundaries.

Develop (developers and vendors)

• Testing and evaluation: threat-model-based scenarios, adversarial testing for specification gaming, evaluation across autonomy levels and tool access, red teaming including multi-agent and chaos testing.
• Input management: validate and sanitise inputs, add prompt injection filters and semantic analysis, validate context before execution.
• Third-party tools: verified allow lists, a trusted registry, SBOMs at procurement, human-readable tool usage logs, and tool descriptions written without persuasive language.
• Separation of duties: split Orchestrator, Reader and Actuator roles, require multi-agent consensus for high-stakes actions, and prohibit agents from modifying their own privileges; delegation needs expiry timers and recorded grant chains. See Delegation Chains and Attenuated Authority for AI Agents.
• Resilience: fail-safe defaults, containment, DLP tuned to agent behaviour, versioning and rollback.

Deploy (vendors and operators)

• Threat modelling: using the OWASP GenAI Security Project and MITRE ATLAS, aligned with NIST SP 800-207 zero trust, plus an incident response plan for agent compromise and regular third-party reviews.
• Progressive deployment: phase rollouts with graduated access and autonomy, expanding or rolling back on continuous evaluation.
• Guardrails: explicit "do not do" rules, deny lists, API-level safety policies and declarative safety contracts the agent cannot override, with a secondary agent validating tasks against policy.
• Isolation: separate high-risk agents into distinct domains and run agents in enclaves with no write access to logs.

Operate (vendors and operators)

• Monitor everything, not only inputs and outputs: prompts, tool calls, memory, reasoning and actions, plus identity and privilege changes, with behavioural baselines, goal drift checks and multiple independent monitors.
• Validate outputs: cross-check critical outputs and treat tool responses as potentially carrying malicious instructions.
• Privileges and authentication: minimum privilege at narrowest scope, just-in-time credentials for privileged actions, fresh cryptographic proof before each privileged call, signed commands, code attestation, and per-request authorisation through a central policy decision point.
• Performance as a signal: unusual performance may indicate compromise; test whether agents can bypass guardrails, monitors and checkpoints, and use rate limits to interrupt runaway workflows.

Where identity fits

Identity runs through every phase of the guidance and is where most organisations can act first. The privilege risks it describes are identity failures: shared or static keys enable impersonation that evades audit, role inheritance produces scope creep, and start-up-only entitlement checks leave stale permissions in place. Appendix A asks for entitlements limited by resource, operation and time, long-lived secrets replaced by ephemeral credentials, and sub-task privileges scoped dynamically and revoked when finished.

Implementing the guidance: a phased approach

NHI Mgmt Group recommendation: this section and the decision guidance below are our own guidance, not requirements of the source document.

1. Inventory and classify: list every agent in use or in pilot, including SaaS features with agentic actions, with owner, model, tools, data sources and credentials. Classify each action by impact, likelihood and reversibility as the guidance asks.
2. Choose low-risk first use cases: read-only or easily reversed tasks on non-sensitive data. Record why a non-AI alternative was not chosen.
3. Fix identity before scale: issue a distinct identity per agent, remove shared keys, scope permissions to the task, and add expiry to any delegation.
4. Add checkpoints: configure approval for resets, egress, deletion of critical records and any request to delete logs. Test that the agent cannot bypass the approval path.
5. Instrument: log prompts, tool calls, identity and privilege changes and actions to a store the agent cannot write to; build baselines.
6. Pilot in rings: sandbox, then a small user group, then wider, expanding autonomy only on evaluation results. Keep a kill switch and versioned rollback ready. See the AI Kill Switch Act Guide for the policy debate on shutdown capability.
7. Review continuously: red-team agent behaviour, reconcile the registry, and feed incidents into threat intelligence sharing.

Decision guidance

Small organisations will mostly consume agents inside SaaS products: the priority is narrow permissions on the connectors, approval settings and log export. Large organisations building their own agents should take on the full developer and operator practice set, including a central policy decision point and independent monitoring.

Detection and measurement

• Agents without a registered owner or identity: any agent traffic from an unregistered client.
• Privilege changes touching agent identities: grants, role assignments and new consents.
• Goal drift: tool calls or destinations outside the approved baseline.
• Denied and escalated actions: spikes may indicate injection attempts.

Metrics that show adoption is under control:

1. Percentage of agents with a distinct identity and a named owner in the registry.
2. Percentage of agent credentials that are short-lived versus static.
3. Number of high-impact action types gated by human approval, and approval bypass findings from red teaming.
4. Percentage of agents whose full tool-call activity reaches the SIEM.
5. Mean time to suspend an agent and revoke its credentials in exercises.

See the AI Agent Behaviour Baselining and Anomaly Detection guide.

Common failure patterns

• Agents running as their human owner: no distinct principal, so actions cannot be attributed and permissions are as broad as the user's.
• Broad tokens for convenience: one admin token for an agent that needed read access, the pattern behind the PocketOS deletion.
• Approval decided by the agent: the model chooses when to ask, which the guidance explicitly rejects.
• Logs the agent can edit: monitoring that a compromised or misaligned agent can delete or alter.
• Unvetted tools and integrations: third-party tools added dynamically with excess privilege, as in the Salesloft Drift breach, where one chatbot integration's tokens opened hundreds of tenants.
• Pilot to production without re-evaluation: autonomy grows with no evaluation gate.

Framework mapping

This mapping is our interpretation; the guidance itself points to secure by design, NIST SP 800-207, OWASP, MITRE ATLAS, ATT&CK and D3FEND, the NIST SSDF and SLSA. For the agent-specific OWASP view see the OWASP Top 10 for Agentic Applications Guide.

Practitioner checklist

• Build an agent registry with owner, purpose, tools, data and credentials, and deny unregistered agents.
• Give every agent its own identity and remove shared or static keys.
• Scope permissions per task and time; prohibit agents from altering their own privileges.
• Gate resets, egress, deletion of critical records and log deletion behind human approval set by operators.
• Restrict tools to a verified allow list with neutral descriptions and logged usage.
• Log prompts, tool calls, memory access and privilege changes to storage the agent cannot write to.
• Deploy in phases with evaluation gates, a kill switch and tested rollback.
• Add agent compromise to the incident response plan and exercise it.

Standards and references

• Canadian Centre for Cyber Security: Careful adoption of agentic AI
• NCSC-NZ: Careful adoption of agentic AI services
• CISA: CISA and Partners Release Guidance on Adopting Agentic AI Services
• NIST: SP 800-207 Zero Trust Architecture
• MITRE: ATLAS
• OWASP: GenAI Security Project
• NIST: SP 800-218 Secure Software Development Framework

Related NHI Mgmt Group resources: Agentic AI Security Guide · Agent Governance and Risk Guide · AI Agent Deployment Checklist · Agentic AI Security Policy Template. This guide summarises the joint Five Eyes guidance and is not legal advice.