AI agent governance breaks when runtime identity outgrows IAM

At a glance

What this is: The article argues that AI agents create an identity and access problem that conventional IAM cannot fully contain because runtime behaviour, not just initial authorization, determines risk.

Why it matters: IAM and NHI teams need continuous discovery, scoped access, and execution-time controls because autonomous agents can expand blast radius faster than manual oversight can react.

By the numbers:

• Enterprises now run roughly 144 non-human identities for every human user.

👉 Read Software Analyst Cyber Research's analysis of AI agent discovery and runtime governance

Context

AI agent governance is becoming a core NHI problem because agents are no longer static software objects. They are created across SaaS tools, browsers, endpoints, and development environments, then granted access to APIs, data stores, and other services at machine speed. That breaks the old assumption that access review alone can keep pace with identity growth.

For IAM leaders, the issue is not only agent volume. It is that the security model has to answer three questions continuously: where the agents are, what they can connect to, and what they can do at runtime. That is why the NHI governance conversation now includes discovery, authorization, and behavioural control as one operating model, not separate projects.

Key questions

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

A: Start with continuous discovery, then bind each agent to narrowly scoped access, execution-time policy checks, and monitoring that can detect behavioural drift. Autonomous agents should never be governed only at provisioning time. The control model has to answer where the agent exists, what it can reach, and whether the next action is still acceptable in context.

Q: What is the difference between agent identity and runtime authorization?

A: Agent identity proves which software entity is acting. Runtime authorization decides whether that entity should be allowed to perform a specific action at that moment. For AI agents, the second control is more important because identity alone does not capture prompt-driven behaviour, chained tool use, or context changes that can make a previously safe action risky.

Q: Why do AI agents create a larger NHI risk than service accounts?

A: Service accounts usually perform stable, predefined tasks. AI agents can adapt, chain decisions, and call multiple tools in sequence, which expands the possible blast radius of a single compromise. That makes them harder to contain with static permissions and more likely to require real-time policy enforcement and stronger telemetry.

Q: How can organisations reduce agent blast radius without blocking adoption?

A: Use least privilege at the connection level, short-lived credentials, and approval gates for sensitive actions. Then add logging and behavioural controls so teams can see when an agent starts moving beyond its intended role. The goal is not to stop agents, but to prevent one compromised identity from becoming a broad access path.

Technical breakdown

Why AI agents do not fit traditional identity models

Traditional IAM was built around humans and deterministic machine identities, where a login or service account has relatively stable behaviour. AI agents are different because their actions depend on prompts, context, tools, and model outputs, which means the same identity can behave safely in one moment and dangerously in the next. That makes the identity boundary only part of the control problem. The real issue is that authorization at creation time does not predict what the agent will do during execution. For NHI programs, this creates a gap between assigned access and actual operational risk.

Practical implication: Treat agent identity as dynamic and re-evaluate access at execution time, not only at provisioning.

How MCP expands the agent attack surface

Model Context Protocol, or MCP, turns tools and data sources into reachable execution paths for agents. Once an agent can call MCP servers, the risk is no longer limited to the agent itself. It inherits the reach of every connected tool, credential, and downstream system. If credentials are exposed in plaintext, OAuth grants are weakly governed, or the tool inventory is incomplete, an attacker can use the agent as a bridge into higher-value systems. In practice, MCP becomes a control surface, not just an integration standard, because it defines where an agent can act and what it can touch.

Practical implication: Inventory MCP servers and treat each connection path as a separate least-privilege decision.

Why runtime authorization matters more than static permission grants

Static access control assumes that once an entity is authorized, its future actions will remain within acceptable bounds. That assumption fails for non-deterministic systems. AI agents can chain actions, change sequence, and produce harmful outcomes without technically exceeding the permissions they were given. Runtime authorization adds context-aware checks at the moment of action, which is where unsafe intent, anomalous sequencing, or unexpected tool use becomes visible. This is the architectural shift practitioners need if they want to govern agent behaviour rather than just credential possession.

Practical implication: Add execution-time policy checks, human approval for sensitive actions, and kill switches for high-risk workflows.

Threat narrative

Attacker objective: The attacker wants to use the agent as a high-speed access bridge that amplifies privilege and accelerates lateral movement.

1. Entry occurs when an attacker reaches an agent through exposed tools, weak OAuth grants, or poorly governed MCP connections.
2. Escalation happens when the agent is used to call additional services, inherit broader access, or chain credentials into downstream systems.
3. Impact follows when the compromised agent moves at machine speed across SaaS apps, APIs, and data stores, expanding blast radius before manual response can intervene.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 identity governance is now a runtime problem, not an enrollment problem. Discovery still matters, but the decisive risk emerges after the agent is created and begins acting across tools, data, and services. That means IAM controls that stop at provisioning miss the point where harm actually occurs. Practitioners need continuous control over execution, not just a clean inventory.

Runtime authority must be narrower than identity authority. An agent can be authenticated correctly and still behave in ways the original policy did not anticipate. That is why least privilege has to be expressed per action path, per tool call, and per context, rather than as a broad entitlement on the identity itself. The practical conclusion is that static policy is necessary but insufficient.

Ephemeral access without runtime inspection creates trust debt. Short-lived credentials reduce exposure windows, but they do not solve behavioural uncertainty or delegated reach. If the agent can still chain decisions, a brief credential lifespan only shortens the time available to misuse authority. Teams should therefore pair short-lived access with execution-time policy and behavioural monitoring.

Model Context Protocol is becoming the identity perimeter for agents. As agents increasingly rely on MCP-connected tools, the security conversation shifts from securing the model to securing the call paths. That creates a new control plane for NHI governance, one that must be discovered, logged, and constrained like any other privileged integration. Practitioners should treat MCP as part of access governance, not a side channel.

Identity blast radius is the concept security teams should use to prioritize agent controls. The question is no longer how many agents exist, but how far a compromised agent can reach in a single action chain. That reframes NHI governance around containment, observability, and rapid intervention. Teams that cannot measure blast radius cannot defend it.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• For a deeper governance lens, review Top 10 NHI Issues for the operational failures that most often create NHI exposure.

What this signals

Identity blast radius is the metric most teams are not measuring yet, but it will determine whether AI agent adoption stays governable. If a single agent can reach multiple tools, services, and datasets, then the security programme needs containment controls that are broader than credential hygiene and narrower than generic zero trust.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the control failure is structural, not occasional. Security teams should expect that many agent workflows already exceed the access they truly need, which means privilege review and runtime enforcement have to move together.

As agent ecosystems mature, teams should prepare for continuous discovery, tool-path governance, and exception handling to become part of normal IAM operations. That is where OWASP NHI guidance and the OWASP NHI Top 10 become practical references for programme design.

For practitioners

• Build continuous agent discovery Aggregate signals from browser, endpoint, SaaS, gateway, and MCP layers so agents are registered as first-class identities as soon as they appear.
• Scope access by connection path Map every agent to the exact SaaS apps, APIs, databases, and MCP servers it can reach, then enforce least privilege on each path.
• Add execution-time policy checks Use runtime authorization for sensitive actions, including human approval, sequence analysis, and behavioural anomaly detection before tool calls are allowed.
• Separate developer agents from production agents Apply different controls to homegrown, SaaS-embedded, and local developer agents because their trust boundaries and credential handling differ materially.
• Treat MCP as a governed control surface Inventory MCP servers, log every tool call, and require scoped credentials so the protocol does not become an uncontrolled execution layer.

Key takeaways

• AI agents break the old IAM assumption that a correct login or service account grant is enough to establish safe use.
• The security problem is no longer just identity volume. It is the combination of tool reach, runtime behaviour, and delayed containment.
• Teams that pair discovery with execution-time controls will be better positioned to govern agentic systems without slowing adoption.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service, token, certificate, or software agent that authenticates and receives access in an environment. These identities often outnumber humans and require their own lifecycle controls, including discovery, rotation, offboarding, and privilege review.
• Runtime Authorization: Runtime authorization is the decision to allow or stop an action at the moment it is about to occur. For AI agents, this is different from initial access provisioning because the same identity can behave differently depending on prompt, tool, and context.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream system reach that a compromised identity can affect before containment occurs. In agentic environments, it is a practical measure of how quickly one identity mistake can become an enterprise incident.
• Model Context Protocol: Model Context Protocol is an open protocol for connecting AI agents to tools and data sources. In security terms, it becomes a governed execution layer because it defines which tools an agent can call and how far a compromised agent can move.

Deepen your knowledge

AI agent runtime governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is moving from inventory to enforcement, the course is a useful next step.

This post draws on content published by Software Analyst Cyber Research: analysis of AI agent discovery, runtime governance, and the Okta blueprint for the secure agentic enterprise. Read the original.