The Premise That Built Modern Identity Security Is Breaking
For the better part of a decade, enterprise security programs operated on a foundational truth: control the identities, control the risk. Human users authenticate. Service accounts connect systems. API keys facilitate machine-to-machine communication. The actors were predictable, and so the governance models that managed them could be methodical, deliberate, and largely effective.
That predictability is gone. And most security teams haven't fully reckoned with what replaced it.
AI agents entered the enterprise under the guise of productivity — meeting summarizers, email drafters, internal search assistants. Security teams gave them little scrutiny because they looked, and functioned, like software tools. The inflection point came quietly: organizations began connecting these agents to the systems that actually run the business. Salesforce. Snowflake. GitHub. Production databases. Cloud environments with administrative privileges.
What was a productivity tool became something categorically different. An actor that retrieves information, triggers workflows, updates records, writes and deploys code, and operates across multiple systems — sometimes on behalf of a human, sometimes autonomously, and sometimes in ways that make the distinction genuinely difficult to determine — is not a tool. It is an identity. And most enterprises have no meaningful security or governance model for it.
Shadow Agents and the Sprawl Problem
The pattern repeating itself across organizations is both familiar and alarming. A new identity layer gets quietly constructed on top of existing infrastructure, inheriting almost none of the access controls that identity teams spent years implementing. An agent might be created by one business unit, operationalized by another, integrated with five external applications, and running on credentials that were originally provisioned for an entirely different purpose.
The common thread: someone needed it to work fast and didn't want governance to slow things down. The result is a growing population of high-privilege, low-visibility actors that security teams can't inventory — much less govern.
82% of organizations discovered at least one AI agent created without the knowledge of security, IT, or governance teams in the past year. 41% found this happening multiple times.
That statistic should reframe how security leaders think about their current exposure. Shadow IT was already a persistent challenge. Shadow AI agents — with credentials, system access, and the ability to act autonomously — represent a materially more dangerous variation of the same problem.
Why Model Risk Gets the Attention, and Access Risk Gets Ignored
The dominant conversation around AI security has centered on model-level concerns: prompt injection attacks, jailbreaks, unsafe or biased outputs. These are legitimate risks that deserve attention. But they do not answer the question that should be at the center of every enterprise security discussion about agentic AI: what can this agent actually access?
An agent summarizing public-facing documentation has a limited blast radius. An agent with connections to customer records, source code repositories, financial systems, and cloud administrator credentials is an entirely different threat surface. A compromised session, a malicious plugin, a misconfigured integration, or even a poorly constructed prompt can transform an overprivileged agent into a vector for data exfiltration, destructive action, or lateral movement across systems that were never intended to be interconnected.
This is no longer a theoretical concern. Security incidents involving AI agents are already occurring at scale, with a significant proportion resulting in the exposure or mishandling of sensitive data. The breach doesn't require a sophisticated adversary — it just requires an overprivileged agent and an opportunity.
Rethinking the Exposure Surface
Effective AI agent governance begins with a different kind of visibility — one that extends well beyond knowing an agent's name or which platform it runs on. Security teams need to be able to answer the questions that actually define risk:
A security team may know a sales assistant agent exists within their AI platform without knowing it runs on a cloud service account with administrative database privileges. They may know a coding agent is installed on developer endpoints without knowing which repositories, secrets stores, and CI/CD pipelines it can reach. The agent itself is only one part of the exposure surface. Everything the agent's credentials can touch is the actual risk perimeter.
Governance Cannot Be Purely Permission-Based
Traditional access governance evaluates permissions. AI agent governance must also evaluate intent — what is this agent actually supposed to do, and do its current permissions match that purpose?
A sales preparation agent requires read access to CRM records. It has no legitimate need to delete database tables. A finance workflow agent should retrieve invoice data. It should never be able to create privileged user accounts. When access is evaluated against intended function, the gaps become visible — and in practice, those gaps are substantial. Privilege drift is nearly universal, and it widens over time as agents evolve, user bases shift, and integrations expand without corresponding access reviews.
Once intent is mapped, enforcement becomes actionable: trim permissions to match actual function, remediate overprivileged service accounts, rotate or remove unused credentials, and flag risky integrations before they produce incidents.
What You Should Do
Security leaders cannot treat AI agent governance as a project with a finish line. Point-in-time audits provide a false sense of progress. An agent that began as a narrow internal tool can quietly accumulate access to systems it was never designed to touch — not because of a deliberate bad decision, but because no one was watching when the scope crept. Governance must be continuous.
- Build an agent inventory now. Assume agents exist that your team doesn't know about. Establish discovery processes across business units, not just within IT.
- Map credentials to agents. Identify every service account, API key, and OAuth token being used by an agentic workload and assess the privilege level of each.
- Apply least privilege with intent as the benchmark. Permissions should match what the agent is designed to do — not what someone thought might be useful someday.
- Establish agent ownership. Every agent should have a designated owner accountable for its access posture and responsible for reviewing changes.
- Implement continuous monitoring. Static access reviews will not keep pace with how quickly agentic environments evolve. Automated, ongoing oversight is essential.
- Include agents in your identity security program. Treat them with the same rigor applied to privileged human users and critical service accounts.
The identity security frameworks enterprises have built are not broken — but they were designed for a world where the actors were predictable. AI agents are not predictable in the same way. They are multiplying, they are accumulating access, and they are operating at machine speed. The organizations that extend their identity governance programs to account for this new class of actor now will be meaningfully better positioned than those that wait for an incident to force the conversation.
