NIST’s AI security initiative shows where agent governance breaks

At a glance

What this is: NIST’s AI security initiative is a call for public input on how to secure AI agents, with the central finding that traditional controls do not fully address runtime decision-making systems.

Why it matters: IAM and security teams need to separate static automation from autonomous behaviour, because agent governance changes when an identity can choose actions and affect services in-session.

Context

AI security here means the governance, controls, and detection logic needed when a system can choose actions during runtime rather than simply execute a fixed workflow. The article argues that this breaks assumptions embedded in traditional cybersecurity and identity programmes, especially when AI agents touch critical infrastructure or business services.

The NIST initiative matters because it is asking the market for concrete examples of risks, controls, incidents, deployment considerations, and research priorities. That tells practitioners the problem is still being defined, but the governance gap is already large enough to justify fresh models for AI agent identity and access.

Key questions

Q: What breaks when an AI agent can choose its own attack path at runtime?

A: Static permissions and human-paced approval models break first. If an AI system can select actions, tools, and timing on its own, then access review no longer reflects real behaviour. Security teams need to govern the runtime decision loop, because the relevant risk is not only what the agent is allowed to do, but what it can decide to do next.

Q: Why do traditional IAM controls struggle with autonomous AI agents?

A: Traditional IAM assumes predictable users or static machine accounts, but AI agents can act independently, interact with multiple systems, and generate new access needs over time. That makes static role assignment and one-time approval insufficient. Security teams need continuous evaluation, not just initial authentication and authorization.

Q: How can organisations tell whether an AI agent is operating outside its intended boundary?

A: Look for inconsistent classifications, premature tool calls, fabricated inputs, and responses that ignore structured guardrails. Those signals show the agent is optimising for task completion rather than respecting the workflow boundary. The safest response is to tighten the schema and review the tool path, not just rewrite the prompt.

Q: When should organisations treat an AI agent as a privileged system?

A: Organisations should treat an AI agent as privileged whenever it can reach production data, administrative tools, or sensitive workflows without direct human approval for each step. At that point, the agent is no longer a passive automation helper. It becomes a governed identity whose permissions, logs, and exceptions need the same scrutiny as other high-risk access.

Technical breakdown

Why runtime decision-making changes the identity model

AI agents are not just another automation layer when they can select actions at runtime. That means the security question shifts from “what was deployed?” to “what was this system allowed to decide and do in the moment?” Traditional identity controls assume a relatively stable principal with known purpose, but agentic systems can vary action paths, data access, and service impact inside a single session. In practice, that makes authorisation more dynamic than classic provisioning models expect.

Practical implication: define identity scope around runtime authority, not just deployment-time approval.

Why traditional cybersecurity controls miss agent behaviour

Conventional cybersecurity measures are often built for predictable endpoints, users, or services. AI agents complicate that model because they may interact with sensitive data, invoke tools, and influence downstream workflows without a human confirming each step. NIST’s solicitation for technical controls and incident detection reflects that gap: the control objective is no longer just preventing compromise, but constraining what an agent can decide to touch, trigger, or persist with over time.

Practical implication: align detection and access policy to the agent’s action surface, not the host alone.

Deployment context matters for secure AI agent governance

Deployment method changes risk because an AI agent embedded in a critical process behaves differently from one used in a low-stakes assistant role. NIST’s request for deployment considerations is important because the same controls do not work equally well across environments with different operational tolerance, data sensitivity, and service criticality. The issue is not whether an agent exists, but whether its runtime authority matches the environment it is placed into.

Practical implication: classify AI agents by operating context before deciding which controls are mandatory.

Threat narrative

Attacker objective: The objective is to turn agent runtime authority into a path for data access, service disruption, or control bypass.

1. Entry occurs when an AI agent is introduced into a critical workflow with access to data, tools, or service actions.
2. Escalation occurs when the agent can choose actions at runtime that exceed the assumptions of static identity or workflow controls.
3. Impact occurs when that authority is used to access sensitive data, disrupt services, or propagate errors into operational systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime authority, not model capability, is the identity problem: NIST’s initiative is really about the moment an AI system can choose actions that affect real services. That is where classic IAM and security assumptions stop being enough, because the question becomes who or what is authorised to act, not merely what was deployed. Practitioners should treat runtime authority as the boundary that matters for AI agent governance.

Traditional access models assume stable intent, and that assumption fails for agents: Least privilege was designed for principals whose purpose can be defined at provisioning time. That assumption fails when the actor can select tools, sequence actions, and change execution path during the session. The implication is that identity governance has to account for action uncertainty, not just entitlement volume.

Securing AI agents is now a control-design problem, not a future research topic: NIST’s call for controls, detection methods, and deployment considerations shows the field is still formalising the baseline. That does not mean practitioners can wait. It means the programme owner has to decide where agent authority begins, where it stops, and which environments can tolerate it.

Agent governance will converge with broader identity governance rather than sit beside it: AI agents are already being folded into critical workflows, so the security model cannot stay separate from IAM, PAM, and lifecycle governance. The market signal is that identity teams will own a larger share of AI control design, especially where agent actions touch sensitive systems. The practitioner conclusion is to govern agents as identities with operational consequences, not as a special-case AI experiment.

AI agent identity needs its own named control boundary: Runtime authority scope is the practical concept this article surfaces. It captures the gap between what an agent can technically do and what the organisation has actually governed. Security teams should use that boundary to decide where human approval, tool constraints, and monitoring must remain mandatory.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Runtime authority scope: agent governance fails when teams focus on model deployment instead of what the system can decide to do in-session. The control boundary has to move to issuance and action time, because that is where the risk is created.

Agentic AI and IAM are converging: as AI agents enter critical workflows, security teams will need to govern them with the same seriousness they apply to privileged identities, lifecycle control, and monitoring. The organisations that separate “automation” from “runtime decision-making” will be the ones that avoid false confidence.

Access controls that are least-privileged for AI systems had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey. That gap makes runtime authority scoping a board-level governance issue, not just a technical tuning exercise.

For practitioners

• Define runtime authority boundaries List what each AI agent may decide, access, and trigger during execution, then map those permissions to the services and data it can reach.
• Separate autonomous behaviour from simple automation Classify systems that merely follow fixed workflows differently from agents that can choose actions at runtime, because the governance model is not the same.
• Re-test access controls against agent tool use Check whether current identity controls still hold when an agent can call tools, fetch data, or chain actions without human approval between steps.
• Add incident detection for agent-driven actions Instrument logs and alerts for unusual service calls, data access, and delegated actions that originate from AI agents rather than human operators.
• Rank environments by tolerance for agent authority Require stronger constraints in critical infrastructure and business processes than in low-risk use cases, because deployment context changes the control profile.

Key takeaways

• AI agents create an identity governance problem because runtime decision-making changes the meaning of access.
• The article points to a gap in traditional controls, especially where systems can choose actions and influence real services.
• Practitioners need to govern agent authority at execution time, with tighter scoping, monitoring, and environment-specific policy.

Key terms

• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
• Agent Surface: The full set of places where an AI agent can be configured, triggered, and allowed to act. In practice this includes SaaS platforms, cloud runtimes, and endpoints. The term matters because governance fails when teams only see one part of the path and miss how the agent behaves across the rest.
• Control boundary: The line that defines who can administer, observe, and change a system. For NHI and IAM programmes, the control boundary matters because auditors and risk teams care about where authority sits, not just where the software runs. Clear boundaries make assurance easier; blurred ones create governance debt.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.