Agentic AI security policy now demands execution roadmaps

At a glance

What this is: This is an analysis of how the 2026 U.S. National Cybersecurity Strategy shifts agentic AI from policy discussion to enforceable security controls, with a key finding that governance must cover identities, runtime behaviour, tools, and multi-agent interactions.

Why it matters: It matters because IAM, PAM, and governance programmes built for human workflows or static machine identities will miss the control points where autonomous agents actually create risk.

By the numbers:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Zenity's analysis of the U.S. agentic AI security strategy

Context

Agentic AI security is the governance problem that emerges when software can choose actions, tools, and execution timing inside enterprise systems. The strategy discussed here matters because it treats those systems as a security domain in their own right, not as a side effect of model deployment or automation.

For IAM and identity teams, the important shift is that policy language is no longer enough. Discovery, permission scoping, runtime monitoring, and control enforcement all have to work together when the identity subject is an agent rather than a person or a fixed workload.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should treat tool choice as an access decision, not just an application behaviour. Define each agent’s owner, permission boundary, and allowed tool set before deployment, then monitor execution so the runtime path cannot expand beyond the approved scope. If a task requires broader access, that expansion should be explicit and reviewable.

Q: Why do existing IAM controls fall short for autonomous agents?

A: Existing IAM controls assume access can be reviewed, certified, or revoked on a human governance cadence. Autonomous agents can acquire and consume permissions inside a single session, which means the review window may not match the execution window. That makes static entitlement management necessary but insufficient for real control.

Q: What breaks when policy says one thing and the agent executes another?

A: The governance model breaks because approval and enforcement are no longer aligned. If the policy layer allows a constrained task but the runtime layer still lets the agent chain tools, widen data access, or propagate actions to other agents, then the control is declarative rather than operational. That creates a false sense of containment.

Q: Who is accountable when an AI agent causes damage through delegated access?

A: Accountability sits with the organisation that assigned the agent its authority, not with the model itself. The practical question is whether ownership, logging, and approval boundaries were defined tightly enough to explain what the agent was allowed to do and why it could do it. Without that, incident review becomes guesswork rather than governance.

Technical breakdown

Agent discovery and inventory for AI agents

Agent discovery is the prerequisite for any credible control model because agents now span SaaS, cloud, and endpoint environments at the same time. In practice, discovery must identify ownership, permissions, runtime behaviour, and the systems an agent can reach. Without that inventory, IAM teams cannot distinguish sanctioned agents from shadow AI, cannot assign accountability, and cannot set scope based on actual use. The article’s core point is that visibility must be tied to governance, not just observability. Practical implication: build a registry that maps each agent to owner, permissions, tool access, and approval boundary before policy enforcement starts.

Practical implication: build a registry that maps each agent to owner, permissions, tool access, and approval boundary before policy enforcement starts.

Agent identity and access management in multi-agent environments

Agent identity is not just authentication. It is the set of permissions, trust relationships, and tool boundaries that determine what an agent can do after it is authenticated. The article argues that least privilege has to be enforced before runtime and traced across multi-agent toolchains, because once execution begins, the risk comes from what the agent is allowed to invoke, combine, or pass onward. This is where traditional access governance often stops at provisioning and misses execution behaviour. Practical implication: scope agent permissions at configuration time and audit tool access as a first-class identity control.

Practical implication: scope agent permissions at configuration time and audit tool access as a first-class identity control.

Runtime monitoring and delegated authority for autonomous systems

Traditional authorisation assumes a human or fixed workflow approves each consequential action. Agentic systems break that assumption because they can decide and act inside the same session, sometimes across multiple agents and tools. That means security controls need to inspect intent, sequence, and behaviour as the task unfolds, not just record events after the fact. The article’s emphasis on runtime enforcement reflects a broader shift from policy declaration to policy execution. Practical implication: combine behavioural monitoring with enforceable runtime policy so approved intent and actual action remain aligned.

Practical implication: combine behavioural monitoring with enforceable runtime policy so approved intent and actual action remain aligned.

Threat narrative

Attacker objective: The objective is to turn approved agent access into broader, unreviewed execution that affects data, workflows, and downstream systems at scale.

1. Entry begins when an agent is granted legitimate access to data sources, tools, or workflows that were approved at design or procurement time.
2. Escalation occurs when the agent expands scope mid-session by chaining tools, reusing delegated authority, or triggering unintended follow-on actions without human review.
3. Impact follows when those chained actions alter data, execute transactions, or propagate into other agents and systems, turning a controlled task into compounded operational harm.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI security is now an identity governance problem, not just a model-security problem. The strategy’s own framing shows that risk is concentrated in identities, tools, and runtime behaviour, not only in what the model outputs. That is why discovery, IAM, monitoring, and development controls all sit in the same control plane. Practitioners should treat agentic systems as governed actors, not clever applications.

Policy-based authorisation was designed for human-paced approval loops. That assumption fails when the actor is autonomous because it can select tools, sequence actions, and trigger execution without waiting for a person to intervene. The implication is not merely that more controls are needed. It is that the control model itself has to account for runtime decision-making that outlives the moment policy was written.

Runtime governance gap: the article makes clear that declaration and enforcement are no longer the same thing. A policy can say an agent is constrained, while the actual runtime path still allows tool chaining, data access expansion, and multi-agent propagation. The practical conclusion is that governance must be measured at execution time, not only at approval time.

Shared agentic governance is emerging because individual-agent authorisation does not scale. The article’s proposal for centralised governance reflects a category-wide shift toward inheritable controls, standardised risk tiers, and machine-readable telemetry. That direction validates a broader identity lesson: when non-human actors proliferate, governance has to move from per-identity exceptions to systemic control patterns. Practitioners should expect auditability requirements to harden quickly.

Agentic AI is forcing convergence between IAM, secure development, and SOC operations. The article links discovery, pre-deployment scoping, runtime monitoring, and secure development into one execution roadmap. That convergence is the real signal for identity teams. Agent governance will not remain a niche capability if policy, architecture, and detection are all being pulled into the same operational model.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
• For a broader breach lens, review The 52 NHI breaches Report for recurring identity and credential failure patterns across real incidents.

What this signals

Agentic AI will force identity programmes to shift from entitlement stewardship to execution stewardship. The control question is no longer whether an agent has access, but whether its live behaviour stays inside the scope that access was meant to enable. In practice, that means identity teams need to align with runtime telemetry, SOC workflows, and secure development reviews rather than treating AI access as a provisioning-only issue.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the shadow problem is already familiar in non-human identity governance. Agentic systems compound it by making the runtime path itself dynamic, which is why discovery and accountability need to be designed as a single programme rather than separate projects.

Runtime governance gap: organisations that separate policy approval from execution monitoring will miss the point where agentic risk becomes operational. The implication is a tighter operating model built around enforceable policy, not just documented policy, with identity, development, and detection teams sharing one control narrative.

For practitioners

• Inventory every agent before granting broader access Create a registry for each AI agent that records owner, approval boundary, tool access, data reach, and runtime context. Treat missing ownership or unknown tool chains as an access governance defect, not an operational detail.
• Scope agent permissions at configuration time Move least-privilege decisions earlier in the lifecycle so the agent receives only the tools and data paths it needs before runtime. Include multi-agent tool chains and downstream delegation in the scoping review.
• Add runtime enforcement to policy approval Use behavioural monitoring and execution guards that can stop unsafe tool invocation, data expansion, or recursive delegation while the task is active. Policy should be enforceable in the session, not only documented in a review.
• Bridge secure development and identity governance Require agent design reviews to cover identity, tool invocation, runtime constraints, and failure modes before production release. Align engineering sign-off with access governance so the build-time intent matches the live execution path.

Key takeaways

• Agentic AI security is an identity governance problem because the risk sits in tools, permissions, and runtime behaviour, not only in model output.
• The strongest evidence in the article is that policy-only governance breaks when autonomous agents can execute, delegate, and expand scope inside a live session.
• Practitioners should respond by inventorying agents, scoping permissions before runtime, and enforcing controls that can stop unsafe actions as they occur.

Key terms

• Agentic AI: Software that can plan and execute multi-step tasks with some degree of independent action. In identity terms, it becomes a governed actor when it can choose tools, timing, or follow-on actions without a person approving each step. That changes access control from static entitlement to runtime supervision.
• Runtime Governance: Controls that enforce policy while a system is actively executing, rather than only at design time or approval time. For AI agents, runtime governance matters because the security issue is often the live sequence of actions, tool calls, and data access patterns, not just the original permission set.
• Shared Agentic Governance Layer: A central control pattern for overseeing many AI agents under one authorisation and monitoring model. It reduces fragmentation by applying common policies, telemetry, and risk tiers across agents, while still preserving accountability for each delegated action. The value is consistency, not delegation without oversight.
• Shadow AI: AI agents or AI-enabled workflows operating without central discovery, approval, or governance. Shadow AI creates identity risk because the organisation may not know what the system can access, who owns it, or whether its runtime behaviour matches policy. That makes discovery a prerequisite for control.

Deepen your knowledge

Agentic AI security, runtime governance, and AI agent identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems in a similar environment, it is worth exploring.

This post draws on content published by Zenity: From Policy Planning to Agentic Action, an execution roadmap for the President’s agentic AI security priorities. Read the original.