Securing Agentic AI: What the Multi-Agency Guidance Actually Requires

On May 1, 2026, the U.S. Cybersecurity and Infrastructure Security Agency and the National Security Agency, together with counterpart agencies in Australia, Canada, New Zealand, and the United Kingdom, jointly published guidance titled Careful Adoption of Agentic AI Services.

It is currently one of the more useful practical references available for organizations deploying agentic systems, and comparatively few teams in financial services have worked through it. This article covers what the guidance addresses and how it translates into controls you can actually implement.

What Makes Agentic Systems Different

The guidance describes agentic AI systems as composed of one or more agents that rely on an underlying model, such as a large language model, to interpret and reason about the state of the world, make decisions, and take actions. They are intended to operate without continuous human intervention. Some are capable of autonomously creating, or spawning, sub-agents to accomplish specific subtasks.

That last capability deserves attention. A system that can create its own sub-agents can expand its own footprint. If your access model was designed around a fixed number of known identities, an architecture that generates new ones during operation breaks an assumption most access reviews are built on.

The guidance organizes its analysis around five categories of risk: privilege escalation, design and configuration failures, behavioral misalignment, structural or cascading failures, and accountability gaps. Each reflects a property of how these systems are built rather than a specific vulnerability class, which is why the mitigations differ rather than resolving into a single governance overlay.

Identity: Treat Every Agent as a User

Agents are frequently deployed using shared service accounts or credentials borrowed from a human operator, because that is the fastest path to a working pilot. It is also the fastest path to an environment where you cannot attribute an action to an actor.

Each agent should have its own identity. Not a shared key, not a human's credentials. The guidance goes further than most organizations can currently implement, calling for cryptographically anchored agent identities paired with short-lived credentials. That is among its more demanding technical requirements, and many enterprises have not yet built the identity infrastructure to support it at scale.

Even without that, distinct identity per agent is the floor. Without it, monitoring cannot distinguish one agent from another, access reviews cannot evaluate whether permissions remain appropriate, and an incident investigation cannot reconstruct what happened.

Authorization: Scope and Least Privilege

Agent permissions should be scoped to the specific task and no further. This is standard least privilege applied to a category of user that many organizations have not yet classified as a user.

The reason it matters more here than with a human employee is behavioral. An agent optimizes for completing its assigned task. If a broader path exists that accomplishes the objective, it may take that path, and from its own perspective nothing unusual occurred. It succeeded. Overly broad permissions with a human are a latent risk. With an agent they are closer to an instruction.

Human Approval for Consequential Actions

Certain categories of action warrant explicit human approval before execution regardless of how routine they become. Moving funds. Deleting or exporting data at volume. Changing access control policy. Modifying production configuration.

This functions as a circuit breaker. It does not require reviewing everything an agent does, which would defeat the purpose of automation. It requires identifying the small set of actions where the cost of being wrong is high enough that a human should be in the path.

Agent to Agent Communication

In multi-agent deployments, agents exchange information with each other. Those exchanges are often not logged in any form a security team can review, and they are frequently where unexpected behavior originates.

If your architecture includes multiple agents, define how they are permitted to communicate, log those exchanges, and monitor them. An orchestration agent that holds credentials for several downstream agents is a concentration of privilege, and it should be treated with the same care as any other highly privileged account.

The Supply Chain Underneath

Agentic systems depend on models, libraries, plugins, and external tools. Each is a third party or a fourth party in your environment, and each is a potential path in. Attacks targeting the components agents depend on, rather than the agents themselves, are a recognized pattern.

Your vendor due diligence assessment should cover the AI service provider directly, and should ask what the provider depends on in turn. If you cannot answer what your agent's toolchain includes, your vendor risk assessment for that system is incomplete.

Monitoring After Access Is Granted

This is the gap that appears most often in assessments, and it predates AI entirely. Access governance in many organizations ends at provisioning. Someone requests access, it is approved, it is granted, and nothing further is recorded.

Applied to agents, that means no one can answer what the agent did last month, whether its permissions are still appropriate, or whether it took an action outside its intended scope. A valid agent taking an unauthorized action is still an unauthorized action, and it will not look like an intrusion in your logs unless you built the logging to show it.

Containment as a Design Requirement

The guidance is direct on this point. Until security practices, evaluation methods, and standards mature, organizations are advised to assume agentic systems may behave unexpectedly and to plan deployments accordingly, prioritizing resilience, reversibility, and containment over efficiency gains.

In practice that means deciding in advance which connections can be severed, what your minimum viable operating environment looks like, and who has authority to make that call.

Given the speed at which these systems operate, a containment decision that waits for a scheduled meeting has generally been overtaken by events. The decision logic should be defined before it is needed.

Sources: Careful Adoption of Agentic AI Services, published May 1, 2026 by CISA, NSA, and partner agencies in Australia, Canada, New Zealand, and the United Kingdom. Available at cisa.gov.

This article is provided for general information and does not constitute legal advice. Regulatory requirements, compliance dates, examiner priorities, and enforcement posture change frequently. Verify current requirements against primary agency sources and your legal counsel before acting on anything described here.