60% of Enterprise AI Agents Are Over-Permissioned — and Nobody Noticed Until Now

Enterprise AI agents are multiplying faster than anyone expected, and most of them have access to far more than they should. According to a new report from Opsin Labs, 60 percent of enterprise AI agents are over-permissioned — meaning they can access data, systems, and actions that go well beyond what their specific task requires. The finding comes at a moment when AI agent adoption is accelerating at a pace that has caught even the companies deploying them off guard.

The scale of the shift is staggering. Enterprise environments now average one AI agent, live or in draft mode, for every employee. Workforce interactions with AI agents grew 14x between January and June 2026 alone. Two-thirds of those agents are still in draft mode, which means they are being tested and iterated on but have not yet been formally deployed. The remaining third are live, operating across email, collaboration tools, business workflows, and internal systems with varying degrees of oversight.

To put the 14x growth in perspective, enterprise email usage grew roughly 3x over the same period. AI agent interactions are not just growing faster than other enterprise software categories. They are growing faster than the onboarding processes, security reviews, and governance frameworks that are supposed to keep them in check. The agents are being deployed faster than the rules can be written.

The problem is not that enterprises are deploying AI agents. That was inevitable. The problem is that the permissions governing those agents are being set hastily, often by the developers building them rather than by the security teams responsible for access control. The result is a growing population of AI agents with standing permissions that would make a security auditor uncomfortable if they were assigned to a human user.

Consider what over-permissioning actually means in practice. An AI agent tasked with summarizing meeting notes might have access to the entire shared drive, including financial projections, employee reviews, and acquisition plans. An agent designed to triage support tickets might be able to modify customer records, issue refunds, or access payment information. In each case, the agent can do far more than its stated purpose requires, and if the agent is compromised or behaves unexpectedly, the blast radius is much larger than it should be.

How Agent Sprawl Happened

The pattern is familiar to anyone who has watched enterprise technology adoption play out before. A new capability emerges. Early adopters build proofs of concept. Those proofs of concept work well enough to get executive attention. Budget gets allocated. Multiple teams start building their own versions. Governance, which was supposed to happen before deployment, ends up happening after — if it happens at all.

AI agents followed this playbook almost exactly. The initial wave in late 2025 and early 2026 was driven by developers who saw how much time they could save by giving an AI agent access to their codebase, their issue tracker, and their deployment pipeline. The agents worked. They found bugs, wrote tests, and resolved issues faster than the developers could do it manually. The success stories spread, and suddenly every department wanted its own agents.

What nobody accounted for was the permissions model. An AI agent that reads code and writes pull requests needs access to the repository, the CI/CD pipeline, and the issue tracker. It does not need access to the company’s financial systems, its customer database, or its human resources platform. But when developers build agents quickly, they tend to grant broad permissions to avoid the friction of figuring out exactly what the agent needs. The agent works better with more access, and nobody is asking whether it should have that access.

This is not a new problem. The same pattern played out with cloud permissions in the early 2010s, with SaaS integrations in the mid-2010s, and with API keys in the early 2020s. Each time, the technology moved faster than the governance, and enterprises spent years cleaning up the resulting permission sprawl. AI agents are the latest iteration of this cycle, but with higher stakes because agents can take actions autonomously, not just access data passively.

SAP’s security team has started calling this “agent sprawl,” and they argue it has become a board-level governance issue. The comparison to employee access management is instructive. When a new employee joins a company, their access is granted through a formal process: a manager approves, IT provisions specific permissions based on the role, and those permissions are reviewed periodically. AI agents bypassed all of that. They were given standing permissions by the people who built them, with no formal review process and no periodic recertification.

The Security Surface Nobody Is Watching

The risks are not theoretical. In 2025 and 2026, vulnerabilities affected some of the most popular AI coding tools. GitHub Copilot received a CVSS score of 9.6 for a security flaw. Claude Code, Cursor, and Amazon Q also had incidents that exposed the security gaps in how AI agents interact with development environments. These were not edge cases. They were the most widely used tools in the enterprise AI ecosystem.

The nature of the threats is evolving as well. Darktrace recently detected and quarantined a prompt injection email before it could be processed by an enterprise AI agent. The attack did not use traditional malware or exploit a software vulnerability. It used natural language — a carefully crafted email that would cause the AI agent to execute unintended actions if it processed the message. This kind of attack is difficult to detect with traditional security tools because there is no malicious code to flag. The payload is the instruction itself.

Mimecast launched its Agent Risk Center in early August specifically to address this gap. The tool gives security teams visibility into agent behavior, permissions, and data access across the enterprise. Before tools like this existed, security teams had limited ability to see what AI agents were doing, what data they could access, and whether their permissions matched their actual requirements.

The challenge is that most enterprises do not know how many agents they have, let alone what those agents can do. A survey of enterprise IT leaders found that the average organization underestimated its AI agent population by a factor of three. The agents were there, running in production, but nobody had counted them because they were deployed through developer tools rather than through the standard IT provisioning process.

What Good Governance Looks Like

The enterprises that are getting agent governance right share a few characteristics. They treat AI agents the same way they treat human employees when it comes to access control. That means formal permission requests, approval workflows, and periodic reviews. It also means the principle of least privilege: agents get only the access they need for their specific task, not broad standing permissions that cover every possible use case.

Some companies are implementing what Augment Code calls “six control planes” for agent governance. These cover identity and authentication, permission scoping, activity logging, behavioral monitoring, data access controls, and incident response. Each control plane addresses a different aspect of the agent lifecycle, from when it is created to when it is decommissioned.

The practical implementation varies by organization. Smaller companies might start with a simple permission review process: before an agent goes live, someone other than the builder reviews what it can access and approves or modifies the scope. Larger enterprises are building automated governance platforms that track agent permissions, flag anomalies, and enforce policies across the entire agent population. The sophistication of the approach depends on the number of agents and the sensitivity of the data they can access, but the principle is the same: agents need the same governance rigor as any other system with privileged access.

The emerging tools from Mimecast, Darktrace, and others are early attempts to fill this gap. They provide visibility into what agents are doing, which is the prerequisite for any governance program. You cannot govern what you cannot see, and most enterprises currently cannot see their agent population clearly enough to make informed decisions about permissions and risk.

The most important shift is cultural, not technical. Organizations need to stop treating AI agents as developer tools and start treating them as enterprise software that requires the same governance rigor as any other system with access to sensitive data. That means security reviews before deployment, not after. It means documented permission scopes, not ad hoc access grants. And it means monitoring and incident response capabilities that can detect when an agent behaves outside its intended parameters.

The organizations that make this shift earliest will have a structural advantage. They will be able to deploy agents faster because they have the governance infrastructure to do it safely. The ones that delay will face a choice between moving slowly with proper controls or moving quickly without them — and history suggests most will choose speed, creating the next wave of incidents that drives the governance conversation forward in the most expensive way possible.

The Window Is Closing

The 14x growth in agent interactions over six months is not going to slow down. If anything, the pace will accelerate as more departments discover what agents can do and deploy their own. The enterprises that establish governance frameworks now will be able to scale agent deployment safely. The ones that wait will find themselves trying to retrofit controls onto a population of agents that has already outgrown their ability to manage.

The Opsin Labs report is a warning shot. Sixty percent over-permissioned is not a rounding error. It is a systemic problem that reflects how quickly agent adoption outpaced the organizational structures needed to manage it. The good news is that the tools and frameworks for agent governance are emerging. The bad news is that they need to be deployed before the next major incident, not after it.

For enterprise leaders, the message is straightforward: your AI agent population is larger than you think, more of those agents have access than they should, and the window to fix that before something goes wrong is shrinking. The time to start treating agent governance as a priority is now, not after the first breach makes it one.