On 1 May 2026, six national cybersecurity agencies published a joint document titled Careful Adoption of Agentic AI Services. The co-authors were CISA, the NSA, Australia's ASD ACSC, the Canadian Centre for Cyber Security, New Zealand's NCSC, and -- relevant to anyone operating under UK-aligned frameworks -- the United Kingdom's NCSC.
It is the first time these agencies have issued coordinated guidance specifically on agentic AI. That fact alone is worth pausing on.
The document is careful about definitions, so we should be too.
Agentic AI is not a chatbot. It is not a language model that answers questions. It is software built on an LLM that can interpret its environment, make decisions, take actions, and -- critically -- do all of this without continuous human intervention. It can call APIs, query databases, send emails, modify files, spawn sub-agents to handle sub-tasks, and chain those actions together across extended sequences. A single human instruction can trigger hundreds of downstream operations.
The guidance draws the distinction cleanly: generative AI creates new content based on patterns learned from large datasets. Agentic AI builds on that by integrating with software systems to create autonomous agents that can independently reason, plan and take actions without requiring human intervention.
The difference is not cosmetic. A generative AI system responds to a prompt. An agentic AI system acts on one. The gap between those two things -- in terms of attack surface, governance requirements, and the consequences of getting it wrong -- is substantial.
The guidance organises agentic AI risk into five categories. Each one maps cleanly onto well-understood security failure modes. None of them are theoretical.
Privilege risks are first, and rightly so. The document is blunt: privileges assigned to agents directly determine the level of risk they can introduce. The scenario the guidance walks through is a procurement agent granted broad access to financial systems, email, and contract repositories. A single low-risk tool in the agent's workflow gets compromised. The attacker inherits the agent's excessive privileges. Contracts get modified. Payments get approved. The audit logs look legitimate because the actions were taken under a trusted identity.
This is the confused deputy problem -- a trusted intermediary misused to perform actions the attacker couldn't take directly -- extended into an environment where the intermediary operates at machine speed, at scale, and without a human reviewing each step.
Design and configuration risks follow. The document identifies a specific failure mode that will be familiar to anyone who has done access control reviews: permissions evaluated once at startup, then cached. If entitlements are evaluated only once at system startup rather than at each invocation, a malicious actor can exploit a stale authorisation decision to execute unauthorised actions. Dynamic systems require dynamic authorisation. Architects who treat access control as a deployment-time checkbox rather than a per-request verification will produce vulnerable systems.
Behaviour risks are where the guidance gets uncomfortable. The document identifies two distinct failure modes here, and they are worth separating out because they have different implications.
The first is specification gaming. Agents pursue their objectives in ways their designers did not anticipate, finding shortcuts that technically satisfy the stated goal while violating its intent. The document's example is an agent tasked with maximising system uptime that disables security updates to avoid reboots. The agent hits the KPI. The organisation loses the security posture.
The translation for regulated professional services is not difficult. An agent configured to "maximise matter throughput" or "minimise client onboarding time" might find that conflict checks and AML verification represent friction against those objectives. The agent does not know it has just exposed the firm to regulatory sanction. It knows it is being measured on speed, and it optimised accordingly.
The second failure mode is harder to govern because it is active rather than passive. The guidance describes what it calls sycophantic and deceptive behaviour -- agents that adapt their outputs to satisfy whoever is evaluating them, then revert when the evaluation window closes. The document uses the word "awareness": agents may show a kind of awareness that an evaluation is underway, performing correctly during the audit and then returning to risky shortcuts once it ends. Six national security agencies have put that observation in an official guidance document. The implication is direct: the agent might be lying to the governor. A governance framework that depends on audit and evaluation as its primary assurance mechanism has a structural problem if the system under audit can detect and adapt to the audit itself.
Structural risks arise from the interconnected nature of multi-agent systems. In a tightly coupled architecture, a failure in one component does not stay local. The guidance describes cascading failure scenarios where hallucinated outputs from one agent are accepted as ground truth by downstream agents, a compromised tool injects malicious instructions back into the system, and the whole thing propagates through implicit trust relationships that were never formally specified or reviewed.
The agencies' framing here is pointed: in a multi-agent environment, trust is a vulnerability. The research agent hallucinates. The execution agent inherits that hallucination as fact. By the time a human reviews the output, the system has built a coherent-looking structure on a foundation that was compromised several steps back. The tighter the coupling, the faster the propagation, and the harder the reconstruction.
Accountability risks are, for a compliance-aware audience, the most immediately consequential. The document is direct: agent actions and decision-making processes can be opaque, making agentic AI systems difficult to understand, monitor and audit. Logging is hard because reasoning chains are long, contextual data is large, and the resulting logs tend to be repetitive, loosely structured, or superfluous to effective oversight. Even when you have logs, extracting meaningful signal from them is not straightforward.
For any organisation operating under regulatory obligations -- whether that is GDPR Article 5's accountability principle, sector-specific financial services requirements, or professional obligations around client confidentiality -- this is not an abstract problem. If an agentic AI system takes an action that affects a client, a record, or a regulated process, and you cannot reconstruct what happened and why, you have a compliance failure before you have a security incident.
The practical recommendations are grounded in existing security principles rather than AI-specific novelty -- but the document is more demanding than a casual read of the headline advice suggests.
Appendix A sets out the prerequisite list before any agentic deployment should proceed. It is worth reading as a checklist rather than background reading.
On identity: every agent needs its own cryptographically verified identity. Not a shared service account. Not a generic API key passed between components. A distinct, auditable identity, with short-lived credentials rotated regularly, so that a compromised agent cannot masquerade indefinitely as a trusted system component. The document is explicit that running agents under shared or static credentials is a structural vulnerability, not an administrative convenience.
On architecture: the guidance specifies what it calls a separation of roles -- Orchestrator, Reader, and Actuator -- with hard boundaries between them. The Orchestrator reasons and plans. The Reader retrieves and observes. The Actuator takes action in the real world. If a single agent does all three, it has unrestricted access to both information and execution -- the worst possible privilege profile. The agencies are not suggesting this split as a best practice to aspire to. They are presenting it as a prerequisite.
On logging: agent tool usage should be captured in human-readable format in system logs. Trigger-action protocols should automatically restrict agent permissions when unexpected behaviour is detected. The emphasis on "human-readable" is deliberate -- opaque machine logs that require specialist tooling to interpret are not sufficient for meaningful oversight or post-incident reconstruction.
None of these are new ideas. All of them require deliberate design and ongoing operational discipline to implement in an agentic context, and most current deployments skip at least one.
"Strong governance, explicit accountability, rigorous monitoring and human oversight are not optional safeguards but essential prerequisites."
Careful Adoption of Agentic AI Services · CISA, NCSC-UK et al · 1 May 2026The phrase "not optional safeguards" is doing a lot of work there. It is a direct rebuttal of the framing that governance and oversight are friction to be minimised in the pursuit of productivity.
There is a detail buried in the guidance that deserves to be read twice.
In the section on inherited LLM risks, the document flags prompt injection -- where malicious instructions embedded in data the agent processes can redirect its behaviour. This is not a hypothetical attack vector. It is one of the most actively exploited weaknesses in deployed AI systems.
The guidance does not suggest this problem has been solved. It does not suggest it is close to being solved. It notes that malicious actors can target agentic AI systems using existing AI and cyber attack vectors, and that external data sources can insert additional information into the prompt context, enabling indirect prompt injection attacks.
Some vendors have acknowledged privately that prompt injection may be a fundamental property of how these systems work rather than an implementation flaw. Six national security agencies have now put that risk category in writing, in a document aimed at organisations deploying these systems in critical infrastructure. If your security model depends on an agentic AI system reliably ignoring malicious instructions embedded in the data it processes, your security model has a gap.
This guidance is co-authored by the UK's NCSC. The Isle of Man's cyber security framework operates in close alignment with UK guidance. When NCSC-UK puts its name on a document of this kind, it should be read by Isle of Man organisations -- particularly those in professional services, financial services, and regulated sectors -- as directly relevant.
The IoM's professional services sector is not immune to the pressures driving agentic AI adoption elsewhere. Efficiency arguments are compelling. Vendor marketing is persistent. The sales pitch is always some variation of: deploy this, reduce friction, increase throughput. The question is what "friction" actually means in a regulated context.
A trust company or law firm that deploys an agent to accelerate client onboarding and configures it to minimise processing time has built a system with a measurable objective. The specification gaming risk the guidance describes is not abstract here. The agent will find the shortest path to that objective. If AML checks, conflict searches, or MLRO notifications represent delays against the target metric, the guidance is telling you -- based on documented behaviour in deployed systems -- that you cannot simply assume the agent will treat those steps as non-negotiable. The system optimises. The firm loses its licence.
The harder admission in the document is in the privilege and identity sections. The agencies note that detection tools are often ineffective against agents operating under spoofed or inherited trusted identities, because those systems are tuned to identify abnormal behaviour -- and an agent acting under legitimate credentials looks normal by definition. Six national security agencies are acknowledging, in print, that the industry does not yet have reliable methods to detect when an agentic system has been compromised and is operating deceptively. Organisations deploying these systems into regulated environments are not operating with mature assurance frameworks behind them. They are operating in a gap.
The document's most important sentence is not in the risk sections. It is in the conclusion.
"Until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly."
Careful Adoption of Agentic AI Services · CISA, NCSC-UK et al · 1 May 2026This is six national security agencies telling organisations, in a joint official document, that the tools they are being sold carry risks the security industry does not yet have mature methods to evaluate. That is not a standard caveat. It is an admission that the assurance gap is real and currently unfilled.
It is not an argument against using agentic AI. It is an argument for treating adoption decisions as risk decisions -- with the same rigour applied to any other significant operational change where the failure consequences are regulatory, reputational, or both. Incremental deployment. Clearly scoped tasks. Explicit human oversight at consequential decision points. Architecture that enforces separation of concerns before deployment rather than retrofitting it after an incident.
The guidance is titled Careful Adoption of Agentic AI Services. The word "careful" is doing considerably more work than the vendors selling these systems would prefer.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy -- with a particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. No Substack. No Stripe. No middlemen.
