AI agents are outnumbering technical staff and bypassing IAM

At a glance

What this is: Clutch Security’s short-form research says AI agents are already larger than the technical staff they work beside in most measured environments, with 3.6 agents per technical employee and rapid monthly growth.

Why it matters: IAM and NHI teams need to treat agent access as a governed identity problem because these systems can inherit credentials, reach production, and bypass human joiner-mover-leaver assumptions.

By the numbers:

• In 84% of the environments measured, AI agents outnumber the technical staff they work alongside.
• Agent populations are growing 29% a month, doubling roughly every ten weeks.

Context

AI agent identity sprawl is now a governance issue, not just an adoption trend. Clutch Security’s measurements show that agents are already operating inside live enterprise environments with credentials and system access, while identity programmes still assume a human-centred lifecycle.

The problem is not that agents exist. The problem is that they are entering environments through install-time access inheritance, then touching production systems before any meaningful identity lifecycle process can be applied. That creates a mismatch between how access is granted and how access is governed.

Key questions

Q: What breaks when AI agents keep standing credentials?

A: The access model breaks because the agent can continue acting after the human has moved on, the workflow has shifted, or the original approval is no longer relevant. Standing credentials turn delegated authority into unattended authority, which is especially risky when agents can retry, chain tools, and move quickly across systems.

Q: Why do AI agents create a larger blast radius than traditional automation?

A: AI agents can chain tools, reuse context, and expand their effective reach during execution, which means one over-permissioned identity can affect multiple systems quickly. Traditional automation is usually narrower and more deterministic. The practical response is to limit each agent’s scope and validate its behaviour continuously.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: What is the difference between governing the agent gateway and governing the underlying credentials?

A: The gateway governs one path, but the underlying credentials govern every path the agent can reach. If most tool use bypasses the gateway, then the real control plane is the credential itself, along with its scope, lifecycle, and offboarding. One is interface control, the other is identity control.

Technical breakdown

How agent identity sprawl bypasses joiner-mover-leaver controls

A joiner-mover-leaver model assumes identities are created, changed, and removed through an explicit governance process. AI agents often skip that sequence entirely: they are installed, inherit whatever credentials already exist on the endpoint, and start operating immediately. That means the identity record is not the source of access, the local environment is. Once an agent begins using an AWS profile, GitHub token, or other stored credential, the access path is already active before any review or certification occurs. Practical implication: governance must move from post-provisioning review to issuance-time control for agent-held credentials.

Practical implication: Treat agent onboarding as an access-issuance event, not a software installation event.

Why production access and credential aggregation matter for AI agents

The report’s operational finding is that agents are not confined to sandboxes. They touch databases, cloud control planes, warehouses, and SaaS platforms, often while holding multiple credentials at once. That turns the agent into a credential aggregator, where compromise of the agent can expose the union of all accessible systems. The technical risk is multiplicative, not additive, because each additional credential expands the reachable blast radius. Practical implication: inventory the systems each agent can reach and map the combined access set, not just the individual tools it uses.

Practical implication: Map each agent to its full reachable access set and treat that union as the control boundary.

Why direct tool use outside MCP changes the control surface

MCP can be useful, but it is not the full story. The article says most agent tool use bypasses MCP and goes straight to tools such as git, aws, psql, and kubectl using credentials configured beforehand. That matters because a control plane focused only on gateways leaves direct command-line and API use outside the governed path. In practice, the agent’s real security boundary is wherever the credential is valid, not where the orchestration layer sits. Practical implication: govern the underlying credentials and tool permissions, not only the protocol wrapper around them.

Practical implication: Extend controls to the underlying credentials and tool permissions, not only the agent gateway.

Threat narrative

Attacker objective: To inherit an agent’s combined credential set and use that reach to access production systems and enterprise data at scale.

1. Entry occurs when an AI agent is installed on an endpoint and inherits local credentials already present on the machine.
2. Credential access follows as the agent uses stored tokens, cloud profiles, and service credentials to interact with live systems.
3. Escalation occurs when the agent’s aggregate access includes production databases, cloud IAM, source control, and other privileged services.
4. Impact is realised when compromise of the host or agent exposes the combined access of every credential the agent can reach.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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 sprawl is now an identity governance problem, not a tooling curiosity. When the median enterprise has more agents than technical employees, the control question stops being whether agents are useful and becomes whether the identity model can even see them. Human-centred onboarding, review, and offboarding were never designed for software that arrives by install command and starts with inherited access. The practical conclusion is that agent identity must be governed as a first-class population, not folded into endpoint hygiene.

The access review model breaks when access exists before governance starts. Access certification assumes an identity remains stable long enough to be reviewed, attested, and remediated. Agents violate that assumption because they begin working immediately, often with credentials the organisation did not deliberately assign to them. That is not a missing control so much as a broken premise: the review cycle is too slow for the access lifecycle the article describes. Practitioners should recognise that the problem is the governance interval itself.

Credential aggregation is the real blast-radius multiplier. The article’s example of 88 credentials across 29 tools is not just a scale story, it is a concentration story. Once an agent becomes the execution point for many credentials, compromise of one host or one agent session becomes a multi-system event. That is the failure mode OWASP-NHI describes in practice: the more access a non-human identity accumulates, the more aggressively its lifecycle and scope must be controlled. The conclusion is straightforward: access concentration, not agent count alone, defines the risk boundary.

Agentic access is being granted outside the intended control plane. The report’s claim that most tool use bypasses MCP means the meaningful governance surface is broader than the orchestration layer. Teams that focus only on the visible gateway will miss the direct credentialed paths to git, cloud, and database tooling. This shifts the field toward runtime authorisation, inventory, and continuous visibility across the actual command paths. Practitioners should govern the credential path, not the interface layer.

AI agent identity governance now sits at the intersection of NHI lifecycle and privilege management. The article shows why a separate agent policy silo is unnecessary and risky. These identities should be brought under the same lifecycle discipline used for other non-human accounts, but with tighter attention to production access and credential inheritance. The implication for the field is that NHI governance must expand from static account control to behaviour-aware runtime oversight for agents.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

AI agent identity sprawl: the phrase usefully captures the shift from isolated experimentation to unmanaged population growth, where agents can outnumber the staff they serve and inherit access faster than IAM teams can classify it. Programmes that still treat agents as tooling rather than identities will miss the governance point entirely.

Clutch Security’s measurements suggest the practical issue is not future scale but present control mismatch. Identity teams need to assume agent access already exists in production, then work backwards from the credentials and privileges those agents can actually exercise.

For practitioners

• Build a live agent census Enumerate every working AI agent, the machine it runs on, and the credentials it can actually use. Do not rely on approved lists or software inventory alone, because installed-but-idle binaries do not reveal active identity exposure.
• Classify agent access as privileged access Treat production-classified resources, cloud IAM roles, and secrets-bearing tokens used by agents as privileged paths. Apply stricter approval and monitoring than you would for ordinary developer tooling.
• Move governance to the credential boundary Control the AWS profiles, GitHub tokens, database credentials, and SaaS secrets that agents inherit before they ever execute. If the credential is already present on the host, the governance decision happened too late.
• Constrain direct tool use outside orchestration layers Review direct calls to git, aws, psql, kubectl, and similar tools so access is governed where execution happens, not only where the agent is orchestrated. Gatekeeping the wrapper does not govern the underlying credential path.
• Fold agents into NHI lifecycle controls Apply provisioning, least privilege, monitoring, and offboarding to AI agents alongside service accounts and other non-human identities. The lifecycle process should follow the access holder, not the identity label.

Key takeaways

• AI agents are already large enough in many environments to distort identity governance assumptions, especially where human lifecycle controls were the default design point.
• The main risk is not agent count alone but credential aggregation, because one agent can concentrate access to multiple systems and magnify blast radius.
• The control that matters most is runtime governance over inherited credentials, production access, and direct tool paths rather than a narrow focus on orchestration gateways.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Credential Aggregation: The concentration of multiple tokens, keys, roles, and secrets inside one runtime identity. This raises blast radius because compromise of the agent can expose every system those credentials can reach, making actor-level governance more useful than secret-by-secret review alone.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.