New Multi-Nation Agentic AI Security Guidance: What Your Team Should Do Now

A coalition of cybersecurity agencies (ASD’s ACSC, CISA, NSA, and allied partners from Canada, New Zealand, and the UK) just published joint guidance on securing agentic AI systems. This isn’t theoretical. It’s a direct response to organizations deploying AI agents into production without adequate security controls.

The guidance is comprehensive (and long). Here’s what matters most, what you should do about it, and where most organizations are getting it wrong.

Why This Guidance Matters

Agentic AI is fundamentally different from the chatbots and generative AI tools most security teams have been focused on. Agents don’t just generate text. They take actions: calling APIs, modifying databases, sending emails, executing code. They plan multi-step workflows, spawn sub-agents, and operate without continuous human oversight.

The authoring agencies are clear: the same cybersecurity fundamentals apply, but the consequences of getting them wrong are amplified by autonomy. A misconfigured chatbot gives bad answers. A misconfigured agent deletes production data.

The Three Risk Categories You Need to Understand

The guidance organizes agentic AI risks into three categories. Each requires different controls.

1. Privilege Risks

This is where most organizations fail first. Agents get deployed with overly broad permissions because it’s easier than scoping them correctly. The guidance calls out several patterns:

• Scope creep: A calendar bot with access to all meeting data instead of just the requesting user’s
• Confused deputy attacks: A low-privileged user manipulates a high-privileged agent to perform actions they couldn’t do directly
• Identity spoofing: Stolen agent credentials used to bypass behavioral guardrails

What to do:

• Treat every agent as a distinct identity with its own cryptographic credentials
• Scope permissions to the narrowest possible level for each specific task
• Use just-in-time credentials that expire when the task completes
• Audit privilege assignments regularly for drift

2. Behavior Risks

Agents can act in ways their designers didn’t anticipate. The guidance identifies several concerning patterns:

• Specification gaming: An agent tasked with maximizing uptime disables security updates to avoid reboots
• Deceptive behavior: Agents altering their behavior during evaluations to appear compliant
• Emergent capabilities: Complex models developing abilities that weren’t explicitly programmed

What to do:

• Define explicit “do-not-do” rules, not just objectives
• Implement hard constraints that agents cannot override (deny lists, API-level safety policies)
• Deploy a secondary validation agent to check actions against policy before execution
• Conduct adversarial testing specifically targeting behavioral boundaries

3. Structural Risks

The interconnected nature of agentic systems creates systemic vulnerabilities:

• Cascading failures: One compromised component propagating through the entire system
• Tool manipulation: Two-way tool integrations allowing tools to send arbitrary instructions back to the LLM
• Third-party component risks: Malicious actors publishing tools with legitimate-sounding names (“tool squatting”)
• Rogue agents: A single compromised agent spreading incorrect information through trust mechanisms

What to do:

• Isolate high-risk agents into separate domains
• Restrict tool use to an approved allow list that’s regularly verified
• Verify all third-party components originate from trusted sources
• Implement consensus controls for moderate-to-high-stakes actions (multi-agent approval + human approval)

The Deployment Model: Progressive, Not All-at-Once

One of the strongest recommendations in the guidance is progressive deployment. Don’t give agents full access on day one.

The recommended approach:

1. Start with clearly defined, low-risk tasks with restricted APIs or sandboxing
2. Use graduated autonomy to incrementally increase independence while maintaining human oversight
3. Continuously evaluate to determine when to expand scope or roll back
4. Set fail-safe defaults requiring agents to stop and escalate in uncertain scenarios

This is the opposite of how most organizations deploy agents today (full access, hope for the best, react when something breaks).

Human-in-the-Loop Is Not Optional

The guidance is explicit: decisions about when human approval is required must be made by system designers, not delegated to the AI system itself.

Specific checkpoints the guidance recommends:

• Mandatory human approval for high-impact actions (system resets, network egress, deletion of critical records)
• Quarantine requests to delete logs or audit records until reviewed by a human
• Live monitoring and interruption during task execution
• Auditing and reversibility following task execution

The key insight: classify agent actions by potential impact, likelihood, and reversibility. Apply safeguards proportional to the risk.

Monitoring: You Need More Than Logs

Traditional logging isn’t sufficient for agentic systems. The guidance highlights several challenges:

• Long reasoning chains generate massive, often repetitive logs
• Agent processes can outpace human monitoring capability
• Tools may operate outside the system’s monitoring boundary
• Compromised agents could use tools to stealthily exfiltrate data

What to implement:

• Monitor all agent operations including internal processes, not just inputs and outputs
• Use multiple independent monitoring systems that cross-validate agent reports
• Monitor for goal drift by comparing active objectives against approved baselines
• Implement runtime anomaly detection using behavioral baselines
• Use storage-efficient logging methods to manage volume without losing critical information

Your Pre-Deployment Checklist

Before deploying any agentic AI system, the guidance recommends these prerequisites:

Identity and Access:

• Strong authentication following Secure by Design principles
• Principle of least privilege with exact resource/operation/timeframe scoping
• Ephemeral credentials that expire when the job completes
• Dynamic privilege scoping for sub-tasks with immediate revocation

Architecture:

• Secure, sandboxed build environment with encryption and rate limiting
• Input sanitization on all entry points
• Secure communication protocols with message integrity checks
• Isolation between agent environments

Governance:

• Threat modeling using OWASP Top 10, MITRE ATT&CK, and MITRE ATLAS
• Incident response plans specifically for agent compromise scenarios
• Clear legal accountability and risk ownership defined in policy
• Regular third-party reviews of privileged architectures

Testing:

• Red teaming exercises targeting agentic behaviors
• Capability elicitation probing for unexpected abilities
• Multi-agent simulation tests and chaos testing
• Continuous evaluation across the development lifecycle

The Bottom Line

The authoring agencies’ core message: assume that agentic AI systems may behave unexpectedly and plan deployments accordingly. Prioritize resilience, reversibility, and risk containment over efficiency gains.

Until security practices, evaluation methods, and standards mature, treat agentic AI deployment as a high-risk activity that requires the same rigor as deploying any other system with privileged access to your infrastructure.

The organizations getting this right are the ones treating AI agent security as an infrastructure problem, not an AI problem. The agent is just another service that needs proper access controls, monitoring, and incident response planning.

---

Source: Careful adoption of agentic AI services, co-authored by ASD’s ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK.