Six national cyber agencies say agentic AI belongs on low-risk, non-sensitive work
- Agentic AI
- AI Security
- Healthcare
- Audit & Assurance
On May 1, 2026, six national cyber agencies, CISA and NSA among them, published joint guidance on agentic AI: use agents only for low-risk, non-sensitive tasks, and never give them broad access.

What changed
On May 1, 2026, six agencies published "Careful adoption of agentic AI services" (ASD's ACSC): the Australian Signals Directorate's Australian Cyber Security Centre, the US Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA), the Canadian Centre for Cyber Security, New Zealand's National Cyber Security Centre and the UK's National Cyber Security Centre. CISA released it the same day. It is guidance, not regulation: nothing in it binds anyone.
It is written for "government, critical infrastructure and industry stakeholders" and for organizations that "design, develop, deploy and operate agentic AI systems," and it focuses on systems built on large language models. Its opening recommendation is blunt: adopt agentic AI "with security in mind, assessing its use and never granting it broad or unrestricted access, especially to sensitive data or critical systems." And: "organisations should only use agentic AI for low-risk and non-sensitive tasks."
What the guidance actually says
Read from the document, kept separate from what anyone makes of it:
- Five risk categories. Privilege risks (privilege compromise, scope creep, identity spoofing and agent impersonation), design and configuration risks, behavior risks (goal misalignment, deception, emergent behavior and malicious exploitation), structural risks (orchestration, tool use, third-party components, data, rogue agents and communication) and accountability risks (opaque actions, accuracy and visibility).
- AI security is cyber security. The agencies want agentic AI managed "within established cyber security frameworks rather than treating it as a separate or standalone discipline."
- One identity per agent. Developers "should construct each agent as a distinct principal," with its own keys or certificates, a trusted registry of agents, and access denied to any agent or key that is not in it.
- People decide where people approve. "Ensure decisions about when human approval is required are determined by system designers or operators, not delegated to the agentic AI system." High-impact actions need prior human approval, and requests to delete logs or audit records are quarantined until a human reviews them.
- Permissions checked per action, not per deployment. Entitlements "evaluated only once at system startup rather than at each invocation" let an attacker exploit a stale "allow" decision. The document recommends a centralized policy decision point for each request and just-in-time credentials for privileged actions.
- Tools are an attack surface. It recommends an allow list of tools and versions, human-readable logs of tool use, and tool descriptions written "using a consistent format that avoids persuasive language," because persuasive descriptions get chosen more often.
- Roll out in stages: phased deployment, "graduated autonomy," and rolling back autonomy and access when evaluation shows failures.
- The conclusion: "Until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly."
What it means for an engineering team
Healthcare is inside the scope. The guidance is framed around critical infrastructure, and in the US, Healthcare and Public Health is one of the 16 critical infrastructure sectors, with the Department of Health and Human Services as its Sector Risk Management Agency. "Non-sensitive" is a high bar in a setting where much of the data is protected health information.
Start with work that is low-risk by construction: tasks where the agent reads non-sensitive material and a person acts on what it produces. The guidance also asks organizations to consider "reducing or eliminating low-value processes" before handing them to an agent at all.
Give each agent its own identity and its own narrow permissions. A long-lived key shared by several agents is exactly what the document warns against. It notes that attackers can steal keys or tokens that organizations keep static, share across agents or protect poorly, and that actions taken under a spoofed identity "evade audit controls" and "undermine accountability."
Decide the approval points yourself and write them down. Which actions need a person is a design decision recorded in the system, not a judgment the agent makes at run time. For an auditor, that list, and the log showing it was enforced, is the evidence.
Log what a reviewer needs. The document admits that full agent logs get large and repetitive. Record decisions, tool calls, identities and privilege changes in a form a person can read, and keep agents from writing to their own logs.
What is still unsettled
What "low-risk and non-sensitive" means in practice. The guidance draws the line but does not define it, and a health system will not find many workflows that touch no sensitive data at all.
How to evaluate an agent. The agencies say current evaluation methods "may be sensitive to minor semantic changes, vary by scenario and only partially capture real-world deployment conditions," making "reliable validation of agent security and system architectures nearly impossible." Until that changes, there is no agreed test an agent can pass.
Whether it becomes an expectation. It binds no one, and it does not say how it maps onto sector rules such as HIPAA. Whether auditors, insurers and procurement teams start treating it as a baseline is open.
Sources
- Australian Signals Directorate's Australian Cyber Security Centre, with CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. Joint guidance, published May 1, 2026.
- Cybersecurity and Infrastructure Security Agency. Careful Adoption of Agentic AI Services. Publication page, May 1, 2026.
- Cybersecurity and Infrastructure Security Agency. Healthcare and Public Health Sector. Retrieved September 22, 2026.

