The AI Agent Governance Crisis: 79% of Enterprises Have Deployed Them, Only 2% Have Identity Security Controls

A 77-Point Gap Is Tearing Through Enterprise Security Defenses

According to an analysis published by Forbes this week, 79% of organizations are already running AI agents in production environments, but only 2% have deployed corresponding identity security governance tools. This 77-percentage-point gap isn't a planning failure—it's the current normal state of enterprise AI operations.

The vast majority of agents have no declared identity, no clear behavioral boundaries, and no path to revoke access when something goes wrong. They're already running on production systems—systems that were never formally registered as within their reach. Shadow IT has always existed, but a misconfigured server is static. An agent with real-time access to production data is not.

Why Discovery Is a Prerequisite for Governance

The starting point of the governance chain isn't crafting policy—it's knowing what's running. You can't scope, audit, or revoke permissions for objects that haven't been cataloged.

Security teams are already stretched thin dealing with conventional threats. Now they must additionally find agents that emerged without ever going through any approval process—a difficulty that rises exponentially. The key problem here is that these agents may have been created independently by business units, forgotten by developers after testing, or quietly introduced through third-party integrations—all without the security team's knowledge.

What's more challenging is that agents differ from traditional IT assets. They have no fixed hardware fingerprint, may exist as API calls, temporary containers, or service accounts, have short lifecycles, and exhibit dynamically changing behavior—making them easy to miss with traditional asset scanning methods.

Non-Human Identity (NHI) is the key concept for understanding this problem. Traditional identity management assumes identities belong to human employees, whereas NHI refers to digital identities held by systems, services, applications, or AI agents—including service accounts, API keys, certificates, bot accounts, and more. According to estimates from security vendors like CyberArk, the number of NHIs in enterprise environments is typically 10 to 50 times that of human identities, and most lack centralized management. AI agents further complicate the NHI problem: traditional service accounts have relatively fixed behavioral patterns, while AI agents possess autonomous decision-making capabilities, and their invocation paths and access scopes may change dynamically with tasks. This means that even if enterprises already have NHI management practices, they can't be directly applied to AI agents—the latter's permission requirements are emergent rather than predefined.

Security Practitioners' Real-World Approaches: IAM Logs, Traffic Detection, or Manual Investigation?

In a related discussion on Reddit, one practitioner directly asked peers: How do you actually discover those unapproved agents?

Several approaches that have emerged in the community include:

IAM Log Analysis—Reverse-tracking agent origins through anomalous service account creation, permission grants, or invocation patterns. This is the most promising direction, but it depends on the completeness and centralization of logs—and many enterprises' IAM logs are themselves scattered across multiple systems.

Network Traffic Detection—Identifying anomalous request patterns from non-human identities. The challenge is that agent traffic can be highly similar to normal automation scripts, making false positive rates difficult to control.

Developer Surveys—Directly asking teams whether they've created agents outside formal processes. This sounds primitive, but in the absence of technical means, it's often the only way to quickly get a handle on the situation.

Each method has blind spots. IAM logs may be tampered with or not enabled; traffic detection is insensitive to encrypted communications and low-frequency calls; developer surveys rely on honesty and memory—both of which are unreliable.

IAM (Identity and Access Management) is the collection of systems in enterprise IT infrastructure responsible for managing digital identity lifecycles and access policies. Its core functions include authentication, authorization, permission granting and revocation, and audit logging. Mainstream platforms like Okta, Azure AD, and AWS IAM typically record every authentication and permission-use event. In AI agent discovery scenarios, the value of IAM logs lies in this: any agent interacting with production systems will almost inevitably leave traces of identity credential usage at some point—whether through service account creation, API key generation, or AssumeRole calls. However, the effectiveness of IAM log analysis depends heavily on three prerequisites: centralized log collection, sufficiently long retention periods, and baseline behavior modeling capabilities. Most enterprises have shortcomings in all three areas, making it difficult to identify anomalous agents from logs even when they exist.

The Confidence Gap: No Method Inspires Real Confidence

What's most noteworthy in the discussion isn't the methods themselves, but the confidence level practitioners have in their own detection capabilities. When asked "How confident are you that you could discover agents created by bypassing normal configuration processes?" the community feedback generally revealed a high degree of uncertainty.

This lack of confidence is well-founded. The barrier to creating agents is dropping dramatically—a developer can spin up an agent with access to internal databases via API in minutes, while the security team may need weeks to discover it through log analysis. This speed differential determines who holds the upper hand.

The deeper problem is that most enterprises haven't yet established complete lifecycle management for "non-human identities." Human employees have onboarding, permission approval, and offboarding revocation processes—but agents don't. They don't need a ticket to be created, don't need oversight to run, and don't need deregistration when they expire.

The Principle of Least Privilege (PoLP) is the cornerstone of identity security governance, requiring that each identity be granted only the minimum access necessary to complete its tasks. In AI agent scenarios, this principle faces unique challenges: agent task scopes are often not clearly defined at creation time, and developers tend to grant broad permissions to avoid operational disruptions. More seriously, when multiple agents share the same service account, permissions are effectively cumulative—and the permission boundary of any single agent cannot be defined. This makes post-hoc auditing nearly impossible—you can't determine which agent initiated a database read, nor can you revoke only one agent's permissions without affecting others when it behaves anomalously. Least privilege is not just a security best practice—it's the technical prerequisite for achieving revocability and auditability.

From Discovery to Governance: The Infrastructure That Needs to Be Built

To close this 77-point gap, no single detection technique will suffice. Enterprises need to rethink several fundamental questions:

Who has the authority to create agents? In most organizations, the answer to this question is "no explicit policy"—which means anyone can.

What identity do agents run under? If they borrow human accounts or share service accounts, auditing becomes meaningless because humans and machines can't be distinguished.

How do you revoke an agent's access? Without a centralized registry, revocation means checking system by system—which is nearly impossible to complete in real time in production environments.

The solutions to these problems all point in the same direction: establishing an identity management system for AI agents similar to that for human employees—including complete processes for creation approval, permission minimization, behavior monitoring, and lifecycle termination. But before that, enterprises need to first know how many agents they actually have and where they are.

Discovery remains the prerequisite for all governance actions. And at present, most enterprises haven't even satisfied this prerequisite.