NIST’s AI security initiative shows where agent governance breaks

At a glance

What this is: NIST is soliciting public input on AI security risks and control needs, with a focus on how AI agents change governance, detection, and deployment assumptions.

Why it matters: It matters because AI agents sit at the intersection of IAM, NHI, and emerging autonomous behaviour, forcing security teams to rethink how access, accountability, and control boundaries are defined.

By the numbers:

• NIST has allocated a 60-day window for public input, emphasizing the value of stakeholder engagement in shaping effective cybersecurity practices.

👉 Read ZioSec’s analysis of NIST’s AI security initiative for agents

Context

AI security becomes an identity problem the moment an AI system can act on its own. The article focuses on AI agents, which it describes as autonomous systems that can perform tasks without direct human intervention, and on the gap between that behaviour and traditional cybersecurity controls.

For IAM, PAM, and NHI teams, the core issue is not just technical hardening. It is governance: how to define access, oversight, incident detection, and accountability when the actor can choose actions at runtime and may influence real operational systems.

Key questions

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

A: Treat AI agents as governed identity subjects with a defined owner, purpose, tool boundary, and data scope. Fixed approvals are not enough when the actor can change action sequence during execution. Security teams should combine inventory, context-aware policy, and runtime monitoring so access decisions reflect what the agent is doing, not just what it was allowed to do at provisioning time.

Q: Why do AI agents create problems for traditional access reviews?

A: Access reviews assume the actor’s access is stable long enough to be observed and recertified. AI agents can change behaviour during execution, which means a review may miss the relevant risk window entirely. Teams need governance that captures runtime use, not only standing entitlement, especially when agents can interact with multiple tools in one session.

Q: What breaks when AI security is treated only as model safety?

A: Model safety alone does not cover identity, access, or incident detection. An AI agent can be technically safe in isolation and still present governance risk if it has broad credentials, weak oversight, or unclear ownership. Security teams need to manage the full operational context, including privileges, telemetry, and response ownership.

Q: Which frameworks should teams use for AI agent governance?

A: Use identity and zero trust frameworks alongside AI risk guidance so controls cover ownership, access scope, and continuous verification. NIST CSF helps structure governance and response, while NIST AI risk guidance and the OWASP Agentic AI Top 10 help teams think about runtime behaviour and tool misuse in agentic systems.

Technical breakdown

AI agent identity and runtime decision-making

AI agents differ from ordinary automation because they can select actions at runtime rather than only following fixed, predefined paths. That creates an identity problem as much as a security problem: the system may need access to tools, data, and services while its exact behaviour changes with context. In governance terms, the access subject is not a static workload, but an actor whose decision path may vary during execution. That makes conventional provisioning, fixed approval chains, and one-time review logic less reliable as control anchors.

Practical implication: model AI agents as dynamic identity subjects, not static workloads, when defining trust and access boundaries.

AI security guidelines, incident detection, and control coverage

The article highlights three control gaps that AI-specific guidance must address: security risks unique to AI agents, technical controls, and incident detection. This matters because many enterprise controls assume a known system boundary and a predictable event model. AI agents can blur both, especially when they interact with multiple tools or services in a single session. Detection therefore has to account for behaviour that is valid in isolation but harmful in sequence, such as unusual tool chaining or unexpected service interaction.

Practical implication: extend detection logic to cover sequence-based behaviour and cross-tool interaction, not just isolated alerts.

Deployment context and zero trust for AI systems

The article also points to deployment considerations, which is where identity governance becomes practical. An AI agent embedded in critical infrastructure or business operations may inherit trust from its environment, even when its decision scope is wider than the hosting system suggests. That is why zero trust thinking is relevant here: trust should not be inferred from deployment location or platform familiarity alone. The control question becomes whether the agent’s privileges, data access, and action scope are continuously justified in context.

Practical implication: tie AI agent access to explicit trust checks and context-aware policy, not deployment convenience.

Threat narrative

Attacker objective: The attacker aims to exploit AI agent access paths and runtime behaviour to reach sensitive systems or disrupt critical services.

1. Entry occurs when an AI agent is given legitimate access to tools, data, or operational systems as part of its deployment.
2. Escalation happens when the agent’s runtime decisions allow it to move beyond the original task boundary into higher-impact actions or broader service interactions.
3. Impact follows when those actions expose sensitive data, disrupt services, or create security blind spots that traditional controls do not detect in time.

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

AI agent security is now an identity governance problem, not just a model safety problem. The article’s framing makes clear that agents are being deployed into critical operations, which means access, detection, and accountability all sit inside the identity plane. That shifts the discipline from model oversight to runtime governance. Practitioners should treat agent identity as part of the access model, not an adjacent concern.

The control gap here is not missing policy alone, but unpredictable runtime behaviour. Traditional cybersecurity assumptions work best when the actor is predictable, the workflow is fixed, and review happens after access is granted. AI agents break that pattern by selecting actions in context, which means the governance model has to account for behaviour that is only knowable at execution time. The implication is that static access thinking no longer fully describes risk.

Named concept: runtime governance gap. This article exposes the gap between how identity controls are usually defined and how AI agents actually operate during live execution. The gap appears when the access subject can change its action path, tool use, and service interaction without a new governance event. Practitioners should recognise that the issue is not simply more access, but a different control model.

Zero trust for AI agents must start with context, not with deployment trust. The article’s emphasis on deployment considerations shows why inherited trust from the hosting environment is too weak for agentic systems. If an AI agent can interact across services, then the source of trust cannot be the platform alone. Identity teams should treat context as the deciding factor for access scope and monitoring.

Cross-domain governance is becoming the only workable posture. The security questions in this initiative cut across IAM, NHI, incident detection, and critical-infrastructure resilience. That means separate teams can no longer solve the problem in isolation, because the control failure spans provisioning, monitoring, and response. Practitioners should align AI security discussions with identity governance, not leave them inside a model-risk silo.

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.
• In the same research, 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access becomes a governance blind spot.
• That visibility gap is exactly why practitioners should also review OWASP NHI Top 10 for runtime trust and tool-access failure modes.

What this signals

Runtime governance gap: AI agents force identity programmes to move from entitlement review to live-activity oversight, because the relevant risk may appear only while the actor is executing. That changes how teams think about monitoring, ownership, and response. The governance question is no longer whether the agent has access, but whether the organisation can explain and constrain what it did with that access.

NHI and AI security are converging around the same operational question: how much trust can be inferred from access alone. The answer is increasingly, very little. Teams that already struggle with service account visibility will find agentic systems harder to govern unless identity, telemetry, and response are designed together, not sequenced as separate programmes.

Organisations that treat agent deployment as a simple application rollout will miss the control boundary shift. AI agents behave more like dynamic non-human identities than static software, which means lifecycle thinking, logging discipline, and policy scope all need to be revisited. For practitioners, the near-term task is to build a control model that survives runtime change, not one that only works at onboarding.

For practitioners

• Classify AI agents as governed identity subjects Document each agent’s owner, purpose, tool set, data access, and operational boundary in the same inventory used for other non-human identities. That makes reviews, incident response, and accountability possible when behaviour changes at runtime.
• Review controls that assume fixed execution paths Identify approval flows, access reviews, and monitoring rules that only work when the actor follows a predictable workflow. Replace those assumptions with controls that can evaluate runtime context and sequence-based behaviour.
• Extend detection to cross-tool activity Tune alerting for unusual chains of tool calls, service interactions, and data movement that may be individually permitted but collectively risky. Use the 52 NHI breaches Report to compare recurring identity failure patterns.
• Align AI governance with identity governance Bring IAM, PAM, NHI, security engineering, and model-risk stakeholders into one control discussion so ownership does not fragment across teams. Use the OWASP NHI Top 10 as a cross-check for identity failure modes that appear in agent deployments.

Key takeaways

• AI agents are becoming identity subjects with runtime behaviour that traditional access models do not fully capture.
• The article reinforces a governance gap between static provisioning and dynamic execution, which is where agent risk starts.
• Practitioners should align IAM, NHI, and AI risk controls so identity decisions reflect live behaviour, not just setup-time approval.

Key terms

• AI Agent Identity: An AI agent identity is the access and accountability layer assigned to a system that can choose actions at runtime. Unlike a fixed automation job, it may interact with tools, services, and data based on current context, which makes ownership, scope, and monitoring part of identity governance.
• Runtime Governance Gap: A runtime governance gap is the mismatch between controls designed for predictable access and actors that change behaviour during execution. It shows up when provisioning, review, and approval processes cannot fully describe or constrain what the system does once it starts operating.
• Context-Aware Policy: Context-aware policy is a control model that decides access based on current conditions, not just preassigned entitlement. For AI agents and other non-human identities, this means privileges, tool use, and monitoring expectations can change as the task, environment, or risk signal changes.
• Sequence-Based Detection: Sequence-based detection looks for suspicious patterns across multiple actions rather than treating each event in isolation. It is especially useful for AI agents and service identities because harm often emerges from a chain of permitted steps that only becomes risky when viewed together.

Deepen your knowledge

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

This post draws on content published by ZioSec: NIST’s Initiative for AI Security and public engagement on AI agents. Read the original.