Securing agentic AI starts with identity governance assumptions

At a glance

What this is: This is a Keyfactor commentary on securing agentic AI, framed through the identity governance assumptions that break when software can act independently.

Why it matters: It matters because IAM, PAM, IGA, and NHI programmes must decide whether their current controls can govern runtime decision-making, not just static credentials.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Keyfactor's analysis of securing agentic AI and identity risk

Context

Agentic AI is software that can decide which tools to use, when to act, and how to sequence work without waiting for a human to approve each step. That changes the identity problem from access assignment to runtime control, because the governance model now has to cover independent action rather than predictable credential use.

Traditional IAM and NHI controls were built around identities that can be reviewed, certified, rotated, or revoked on a defined schedule. When the actor becomes autonomous, those assumptions become fragile, and the core question shifts to whether access governance can keep pace with self-directed execution.

For teams managing IAM, PAM, IGA, and workload identity, the practical issue is no longer whether agents exist in the estate. It is whether current governance can distinguish an approved workflow from an agent that has started to behave like an operator.

Key questions

Q: What breaks when agentic AI is governed like a normal workload identity?

A: What breaks is the assumption that permissions stay stable long enough to be reviewed, certified, and revoked on schedule. Agentic systems can select tools and chain actions in runtime, so the real governance boundary is not the account itself but the reachable actions. Without runtime controls, static governance will miss the point where behaviour changes into risk.

Q: Why do autonomous AI systems complicate least privilege?

A: They complicate least privilege because intent is not fixed at provisioning time. An autonomous actor can decide which tool to use next, so least privilege must be defined against dynamic behaviour and reachable outcomes, not just a role description. That makes static entitlement design incomplete unless the execution path is also constrained.

Q: How do security teams know whether AI agent governance is actually working?

A: Look for evidence that you can reconstruct what the agent accessed, when it acted, and which tools it used to complete the task. If you cannot audit those steps, governance is only declarative. Effective control should leave a verifiable trail across identity, tools, and action sequencing.

Q: Who is accountable when an AI agent causes an access or data incident?

A: Accountability is shared across the team that granted the identity, the platform that exposed the tools, and the controls that allowed the action path. The key question is whether governance assigned ownership before execution, not after the incident. If accountability appears only in the postmortem, the control model was too weak.

Technical breakdown

Why runtime decision-making changes the identity model

Agentic systems are different from ordinary automation because they can choose actions at runtime instead of following one fixed script. In identity terms, that means the subject is no longer just presenting a credential, it is continuously shaping the next access decision through tool choice, context, and execution timing. This is why agentic AI should be treated as a non-human identity with behavioural volatility, not as a normal workload or service account. The technical challenge is governance of decision authority, not merely authentication strength or secret storage.

Practical implication: model the agent as an identity with dynamic behaviour, then test whether current controls can govern its action sequence, not only its login.

Why MCP and tool access expand the attack surface

Model Context Protocol matters because it creates a standard way for agents to reach tools, data sources, and external actions. That is useful for integration, but it also makes tool access part of the identity threat surface. Once an agent can invoke multiple tools, privilege is no longer one static permission set. It becomes a chain of reachable actions, where misuse can come from a legitimate identity being allowed to do the wrong thing at the wrong time. The risk is compounded when tool permissions are broad and approval gates are weak.

Practical implication: inventory agent-to-tool paths and constrain which actions are reachable from each identity before deployment.

Why access review and rotation logic do not fully solve agent risk

Access review, secret rotation, and offboarding are still necessary, but they were designed for identities whose access is stable long enough to be observed and certified. Agentic behaviour can compress the useful review window because privileges are consumed, combined, and abandoned within the same task cycle. That makes governance a matter of runtime oversight and post-action accountability, not just periodic cleanup. For security architects, this means the main failure mode is not simply excessive access, but access that changes meaning while the session is still active.

Practical implication: pair lifecycle controls with runtime logging, session limits, and approval boundaries that reflect how agents actually operate.

Threat narrative

Attacker objective: The objective is to turn legitimate agent access into broad, hard-to-audit operational reach across systems and data.

1. Entry begins when an agent is granted legitimate access to tools, data, or downstream systems through approved identity controls.
2. Escalation occurs when the agent expands scope mid-session by selecting additional tools or chaining actions beyond the original intent.
3. Impact follows when those chained actions expose data, trigger unauthorized operations, or create audit gaps that undermine containment.

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

Autonomous identity collapses the assumption that privilege is stable enough to review. Access review cadences were designed for identities whose permissions persist long enough to be certified or remediated. That assumption fails when an agent can acquire, combine, and expend privilege inside a single runtime sequence. The implication is not simply tighter review, but a rethink of what governance is trying to observe in the first place.

Agentic AI turns tool reachability into the real privilege boundary. In traditional IAM, access can often be described by accounts, roles, or entitlements. For autonomous systems, the meaningful boundary is the set of actions reachable through connected tools, prompts, memory, and delegated permissions. That makes the problem structurally closer to identity blast radius than to classic account management. Practitioners need a governance model that maps actions, not just identities.

Runtime governance gap: agent behaviour can outpace static policy. The early internet comparison is apt only if teams notice the same pattern of rapid capability growth outstripping control maturity. The field should assume that policy written at provisioning time will miss the moment an agent starts to reinterpret its task in motion. The practical conclusion is that governance for agentic AI must be designed around live decision points, not annual certification cycles.

Autonomous behaviour makes accountability a chain problem, not a single-owner problem. Once an agent can delegate to tools and trigger downstream actions, ownership is no longer captured by the person who provisioned the credential. It is distributed across the delegator, the platform, and the controls around execution. That does not remove accountability, but it does mean current governance models often assign it too late. Practitioners should expect this to become a board-level audit issue.

AI agent governance is converging with NHI governance, but not becoming the same thing. The identity substrate is still non-human, yet the control expectations are higher because the actor can decide, not just authenticate. That places agentic AI at the intersection of NHI, PAM, and AI risk management, where lifecycle control alone is insufficient. The field needs shared language for identity behaviour, because the next wave of failures will come from treating autonomous systems like static workloads.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For a broader control baseline, see OWASP Agentic AI Top 10 and compare it with the governance gap identified here.

What this signals

Runtime governance is becoming the deciding control layer for agentic AI. If the programme still treats agent access as a one-time provisioning event, it will miss the moment when the agent starts selecting tools and sequencing actions on its own. Teams should expect identity reviews, logging, and policy enforcement to move closer to execution time, not remain buried in periodic certification cycles.

The governance model for autonomous systems now overlaps with NHI, PAM, and AI risk management, which means separate teams will need a shared control vocabulary. That is where the practical programme work begins: align access boundaries, audit evidence, and escalation paths before agent usage becomes normalised across business units.

Runtime governance gap: the next maturity jump is not more policy, it is policy that can be enforced at the point of action. As agent deployment expands, practitioners should prepare for more tool-path mapping, more session-level accountability, and more demand for evidence that the identity behaved within its intended scope.

For practitioners

• Map agent decision boundaries Define which actions an agent can initiate without human approval, then remove any tool path that exceeds that boundary. Treat the resulting map as part of identity governance, not just application design.
• Separate tool access from broad role assignment Break agent permissions into narrowly scoped tool entitlements so reachable actions are visible and reviewable. If a role bundles too many tools, it hides the true blast radius.
• Add runtime logging for agent actions Capture tool selection, execution timing, and downstream calls in a way that supports audit and incident response. A standard access log is not enough if it cannot reconstruct the agent’s decision path.
• Rework access reviews for autonomous behaviour Review whether current certification processes can evaluate identities that may change state inside one session. If not, add event-driven review triggers tied to task completion, anomaly signals, or policy violations.

Key takeaways

• Agentic AI changes the identity problem from credential control to runtime behaviour control.
• Policy adoption is lagging the risk signal, with governance gaps already visible in current deployments.
• Practitioners should move identity oversight closer to execution time or expect static IAM controls to miss autonomous behaviour.

Key terms

• Agentic AI: Software that can choose actions, tools, and timing during execution rather than simply following a fixed automation script. In identity governance, agentic AI behaves like a non-human actor with runtime decision authority, which makes static access models incomplete unless execution is also controlled.
• Runtime Governance: The set of controls that apply while an identity is actively making decisions and calling tools. For autonomous systems, runtime governance is where policy, logging, approval boundaries, and anomaly response have to meet the action itself, not just the account or credential that enabled it.
• Identity Blast Radius: The amount of damage an identity can cause if it is misused, over-scoped, or allowed to chain permissions. For agentic systems, blast radius is measured by reachable actions and downstream tool paths, not only by the role name or credential type assigned at provisioning.
• Assumption Collapse: A governance failure where a control model stops working because its original assumptions no longer match the actor’s behaviour. In autonomous identity, the collapse usually happens when controls assume access is stable, human-paced, or externally initiated, but the actor can decide and act on its own.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Keyfactor: Securing Agentic AI, Learning From the Early Days of the Internet. Read the original.