AI agents are outnumbering technical staff and bypassing IAM

At a glance

What this is: This is a short-form research post on enterprise AI agent sprawl, credential accumulation, and the failure of human-style identity processes to keep pace with agent behaviour.

Why it matters: It matters because AI agents are already operating inside production environments with credentials and access paths that were not provisioned through normal IAM, IGA, or PAM workflows.

By the numbers:

• In 84% of the environments we measured, agents outnumber the technical staff they work alongside.
• The population grows 29% a month, doubling roughly every ten weeks.

👉 Read Clutch Security's full report on one laptop, four agents, and 88 credentials

Context

AI agent identity is becoming a governance problem because these systems arrive already connected to real credentials, real tools, and real production paths. In this article, Clutch Security argues that the enterprise has a growing population of working agents that is not being brought under the same identity lifecycle used for humans and service accounts.

The core issue is not whether agents exist, but whether organisations can account for what they can reach, what they hold, and when they should lose access. When agents are installed from a command line and begin operating with ambient credentials, the joiner-mover-leaver model stops matching reality, especially in production environments.

The starting position described here is typical of many modern enterprises, not an edge case. The article’s own numbers suggest that agent sprawl is already embedded in day-to-day operations, which means identity teams need to treat agent access as a first-class governance domain rather than a tooling afterthought.

Key questions

Q: How should security teams govern AI agents that rely on shared runtime credentials?

A: Security teams should treat every AI agent as a workload identity with a defined task boundary, then issue only the minimum access required for that task. Shared credentials should be retired where possible because they obscure accountability, widen blast radius, and make revocation harder after the task completes.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when joiner-mover-leaver processes are applied to AI agents?

A: The human assumption behind JML breaks down. AI agents can be created, modified, and retired inside workflows that do not match employment-based lifecycle events, which leads to stale permissions, unclear ownership, and missed offboarding unless the process is redesigned for non-human identities.

Q: Who should own AI governance when agents connect to production systems?

A: Ownership should sit with the team responsible for the data, tools, and transactions the agent can touch, with IAM and security architecture enforcing the boundaries. If nobody can explain who approved the access, who can revoke it, and who reviews the actions, the agent is over-scoped by default.

Technical breakdown

How AI agents aggregate credentials across tools and sessions

The article shows a common pattern in agent deployments: one agent inherits whatever the endpoint already holds, then uses a mix of cloud, source control, database, and SaaS credentials to act quickly. That makes the agent a credential aggregator rather than a single-purpose workload. The security problem is not just possession of one secret, but the way one runtime can consolidate many identities into a single operational blast radius. This is why the distinction between the human operator and the agent runtime matters. Practical implication: map every credential an agent can touch to the process that granted it, then classify that access as privileged.

Practical implication: map every credential an agent can touch to the process that granted it, then classify that access as privileged.

Why production-classified access changes the identity risk model

Clutch Security reports that agents are already touching production-classified resources in most environments it measured. That matters because production access is not just another environment label. It implies that the agent can influence live data, infrastructure control planes, and business systems with credentials that may never have passed through a normal approval or certification flow. In identity terms, production access turns an otherwise useful automation layer into an active privilege-bearing actor. Practical implication: separate agent runtime permissions from developer workstation permissions and subject both to explicit production controls.

Practical implication: separate agent runtime permissions from developer workstation permissions and subject both to explicit production controls.

What happens when approval prompts are bypassed by design

The article notes that many agents run with approval prompts disabled, which removes the human checkpoint that many organisations still assume exists. Once that gate is gone, a prompt-injection payload or model error can act directly on live systems without interruption. This is an autonomy-adjacent risk, even if the system is not fully autonomous, because the operational effect is the same: action can proceed faster than review. The identity issue is not just authentication, but delegated execution authority. Practical implication: treat approval-free agent execution as a privileged path that requires explicit runtime guardrails and logging.

Practical implication: treat approval-free agent execution as a privileged path that requires explicit runtime guardrails and logging.

Threat narrative

Attacker objective: The attacker aims to turn one compromised agent runtime into broad access across the organisation’s production and data estate.

1. Entry occurs when an attacker reaches a developer machine or other endpoint where working agents already hold usable credentials and tool access.
2. Escalation follows when the agent’s aggregated secrets let the attacker pivot into cloud IAM, source control, databases, or SaaS systems from a single compromised runtime.
3. Impact is the ability to inherit the combined reach of the agent chain, exposing production systems, data stores, and downstream services at once.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 identity is becoming a separate governance class, not a variant of workload identity. The article’s central finding is that working agents are already behaving like identity-bearing actors with real production reach, not like passive automation. That means traditional workload controls are no longer enough on their own. Identity teams need to classify agents as governable identities with their own lifecycle, entitlement, and monitoring expectations.

Joiner-mover-leaver processes were designed for identities that arrive through formal provisioning, not through installed software that starts with inherited credentials. That assumption fails when the actor is an AI agent because access can exist before any governance record does, and it can begin touching systems in minutes. The implication is that lifecycle governance must be rethought around runtime presence and credential inheritance, not just onboarding forms.

Credential aggregation creates an identity blast radius that many current access review processes do not capture. The article shows an agent can hold dozens of credentials across multiple services, which collapses multiple permissions into one operational failure domain. If one runtime can reach cloud IAM, source control, and production data together, recertification at the individual credential level misses the combined risk. Practitioners should treat the agent as the certification unit, not just the secret.

Runtime governance gap: the real problem is not agent existence, but the absence of runtime controls that decide what an agent may touch once it is already operating. The article highlights approval-free execution, direct tool use, and rapid credential access as the operational reality. That means policy has to follow the agent at runtime, because static approval lists and wiki-based rules do not constrain live execution. Security programmes should assume the gap is in enforcement, not awareness.

Enterprise consolidation around AI agents will force identity teams to unify human, service account, and agent governance under one control model. The article’s numbers show the agent population is scaling fast enough to rival the human workforce. That makes separate governance lanes increasingly brittle. Practitioners should prepare for a single identity operating model that distinguishes actor type, but applies consistent lifecycle and privilege logic across all three.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• Use Ultimate Guide to NHIs , Static vs Dynamic Secrets to evaluate where long-lived credentials are still creating avoidable exposure.

What this signals

With agent populations growing 29% a month, identity teams should assume that today’s approved inventory will understate tomorrow’s real access picture. That makes continuous discovery and runtime classification more important than annual recertification cycles.

Credential aggregation becomes the control problem: one agent that can use fifteen credentials, or in some environments far more, creates a combined trust boundary that standard secret-by-secret reviews do not capture. Programmes should shift toward actor-level ownership and access scoping.

The NHI lifecycle model now needs to absorb AI agents alongside service accounts and workloads. If the same operational controls do not cover all three, organisations will keep discovering access only after the agent has already used it.

For practitioners

• Run an agent census before the planning cycle ends. Inventory every working agent, the machine it runs on, the credentials it holds, and the production systems it can reach. Use observed behaviour, not approved lists, because installed binaries that never execute do not represent actual risk.
• Treat agent production access as privileged access. Define a policy for what agents may touch in production and enforce it in the agent runtime, not in documentation. Separate test, development, and live access paths so production-classified resources require explicit control.
• Bring agents into your identity lifecycle. Extend provisioning, recertification, monitoring, and offboarding to agents that use credentials in production. Lifecycle governance should include when access starts, how it is reviewed, and how it is revoked when the agent is no longer needed.
• Measure credential aggregation per agent. Track how many distinct secrets, tokens, roles, and service credentials each agent can use. A high count means one compromise can produce a much wider blast radius than your current access reviews may show.

Key takeaways

• AI agents are already functioning as identity-bearing actors, which means IAM and IGA teams must govern them as a distinct population.
• The article’s data shows that agent sprawl is scaling faster than many review cycles can track, making visibility the first control problem.
• The most effective response is to classify agent access as privileged, then bring it into lifecycle, runtime, and offboarding governance.

Key terms

• Working Agent: An AI agent that actually executed actions in a real environment during the observation window, held credentials, or touched systems. In governance terms, working status matters more than installation status because only active behaviour creates identity and access risk that must be inventoried and controlled.
• 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.
• AI Agent Lifecycle Governance: The set of controls that assigns, constrains, monitors, and retires autonomous agents across their full operating life. It extends IAM practice to software that can act on its own, making ownership, scope, auditability, and revocation mandatory rather than optional.

What's in the full report

Clutch Security's full report covers the operational detail this post intentionally leaves for the source:

• Per-environment census methodology showing how working agents were counted across live enterprise estates
• The one-laptop case study that breaks down the 88 credentials and 29 credentialed tools involved
• Observed production access patterns across databases, cloud IAM roles, source control, and SaaS platforms
• The full guidance on how Clutch suggests teams build an honest agent inventory from real behaviour rather than approved lists

👉 Clutch Security's full post covers the agent census method, the laptop case study, and the production access patterns behind the findings.

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 building or maturing an IAM or identity security programme, it is worth exploring.