Agent sprawl is the new shadow IT: governing a fleet before it governs you

Your first Agentforce agent took a quarter to ship. You scoped it, argued about its topics, tested it against adversarial utterances, wired its running user to exactly the right permissions, and put it in front of customers with a name on the accountability line. It was a project.

Your tenth agent took an afternoon. Someone spun up a self-service Help Agent in six clicks, a developer stood one up in Vibes to prototype a workflow, a business unit cloned an existing one and tweaked it, and a multi-agent orchestration build quietly added three specialists behind a primary. None of those had a quarter of scrutiny. Some have no named owner at all. And the honest question nobody in the room can answer is: how many agents do we have running right now, what can each of them touch, and who turns them off when they go wrong?

That gap has a name now — agent sprawl — and it’s the same shape as the shadow-IT problem enterprises spent the 2010s cleaning up, except the unauthorized things spinning up aren’t SaaS subscriptions. They’re autonomous systems with credentials, data access, and the ability to take actions on their own. The industry numbers are stark: surveys in 2026 put the share of enterprises reporting that AI sprawl is raising security and operational risk at around 94%, active deployers running dozens to a hundred agents and roughly doubling each quarter, mean monitoring coverage near 52% — meaning close to half of production agents run unobserved — and only about 7.2% of organizations with a named individual formally accountable for agent behavior. This post is about closing that gap before it closes on you, grounded in what Agentforce actually gives you to do it.

Why agents sprawl faster than anything before them

Three properties make agents proliferate faster than apps, integrations, or even the SaaS tools shadow IT was made of.

They’re cheap to create. The whole point of the platform push over the past year was to make standing up an agent a low-code, few-clicks act. That’s a genuine good — and it’s exactly why the count explodes. Every friction you remove from creation is a friction removed from ungoverned creation too.

They spawn other agents. A multi-agent orchestrator delegates to specialists; a coding agent spins up sub-agents; an agent granted a tool can call a service that is itself an agent. The org chart of your digital workforce isn’t a list — it’s a graph that grows edges you didn’t draw. Conventional access management was built for humans and service accounts that sit still; it wasn’t built for identities that create more identities at runtime.

They accumulate access and outlive their purpose. An agent built for a Q1 campaign is still running in Q3 with its Q1 permissions, because deactivating it was nobody’s job. The permissions it was granted for one task persist across every task after. Retiring an agent is unglamorous work that never makes it onto a sprint, so agents don’t get retired — they get forgotten, which is worse, because a forgotten agent still has its credentials.

Shadow IT was unauthorized software. Agent sprawl is unauthorized actors — each with an identity, a data scope, and the authority to act. You can’t govern actors with a software inventory, and you can’t govern a graph that grows itself with a static list.

The reflex is to slow down creation. That’s the wrong lever — the value of agents is that they’re cheap to create, and clamping that down forfeits the upside to avoid the risk. The right lever is to make governance a property every agent has from birth, so that a fast-created agent is still a governed one. Which means being precise about what “governed” decomposes into.

The three primitives: identity, scope, lifecycle

Strip the frameworks and fleet governance is three things. Every agent needs a distinct identity, a bounded access scope, and a defined lifecycle with an end. Miss any one and you have sprawl no matter how good the other two are: an identity with unbounded scope is a breach; a scoped agent nobody owns is an orphan; a governed agent that never retires is a permanent, growing liability. Here’s what each looks like in practice, and specifically what Agentforce gives you to implement it.

Identity: one agent, one running user, never reused

This is the primitive everyone underestimates, and it’s the one with the most concrete Salesforce hook. An Agentforce agent acts as a running user, and that user’s permissions determine what the agent can access and do — including permissions it inherits transitively from the Apex, Flows, and prompt templates its actions invoke. Salesforce’s own security guidance is blunt about the rule: each agent’s user should be unique, should never be reused across multiple agents, and must adhere strictly to least privilege.

The reason “never reused” matters is attribution. If two agents share a running user, the audit trail can’t tell you which one took an action, which means you can’t investigate an incident, can’t scope a blast radius, and can’t revoke one agent’s access without breaking the other. One agent, one identity, is what makes every other governance control possible — it’s the foundation the audit trail and access reviews stand on. The rest of the industry is converging on exactly this idea from the identity-platform side: Microsoft’s Entra now issues each agent its own identity with its own sign-in history and Conditional Access targeting, Agent 365 shipped as a control plane around that, and Google’s Gemini Enterprise assigns each agent a cryptographic SPIFFE ID tied to its lifecycle. Different vendors, same conclusion — an agent is a first-class identity, not a feature of the human who made it. On Salesforce, the running user is that identity, and treating it casually is the original sin of a sprawling fleet.

Scope: least privilege, verified, not assumed

A distinct identity is only worth what it’s bounded to. The discipline is the same least-privilege posture we lay out for a single agent’s attack surface, applied fleet-wide: scope each running user to exactly the objects, fields, and actions its one job needs, and verify the scope rather than assuming it — because Agentforce actions inherit permission transitively through the Apex and Flows they call, an agent can reach data you never explicitly granted it. The verification move is periodic testing that an agent cannot access data beyond its intended scope, treated as a recurring control, not a launch-day checkbox. The Einstein Trust Layer enforces guardrails at the model boundary, but it is not a substitute for getting the running user’s permissions right — grounding, masking, and audit at the LLM layer don’t help if the agent’s underlying identity can query the whole org.

The failure mode to design against: scope creep. Over a fleet’s life, agents get more permissions (someone needed the demo to work) and almost never fewer. Without a periodic re-scoping review, every agent trends toward over-privilege, and a fleet of quietly over-privileged agents is a breach waiting for one prompt injection to find it.

Lifecycle: a defined end, not just a beginning

The primitive teams skip entirely. Salesforce frames Agent Lifecycle Management (ALM) as the end-to-end process across five stages — design/ideation, evaluation, deployment, monitoring, and retirement — with governance built into each. The first four get attention because they’re how an agent goes live. The fifth is where sprawl actually accumulates, because retiring an agent is never anyone’s default job.

A real retirement is a checklist, and it’s the antidote to the forgotten-agent problem: archive the configuration, preserve the evaluation and test records, remove its integrations, revoke its access permissions, and keep the audit logs for compliance. The load-bearing line is revoke its access permissions — an agent you “turned off” but whose running user still holds its grants isn’t retired; it’s dormant with a live key. Decommissioning that doesn’t revoke access is how a Q1 agent becomes a Q4 incident.

The visibility problem: you can’t govern what you can’t see

Identity, scope, and lifecycle are the controls. Observability is how you know they’re holding — and it’s where that 52%-monitoring-coverage number turns from a statistic into a 2 a.m. incident. Two Salesforce surfaces do real work here.

The Setup Audit Trail now carries an AI Agent column that records which agent made a given change — a small addition with outsized value, because it means agent-driven changes are attributable in the same log you already use for human ones. Combined with the one-agent-one-running-user rule, that column is what lets you answer “which agent did this” instead of “an agent did this, somewhere.” The pairing is the point: distinct identities make the audit trail legible, and the audit trail is what makes distinct identities useful.

For runtime behavior — not config changes, but what agents are actually doing turn by turn — the observability tooling in the Agentforce 360 platform, which we cover in what Command Center actually shows you, is the layer that turns 52% coverage toward 100%. The governance point is simply that monitoring is not optional infrastructure you add if there’s time. An unmonitored agent is an ungoverned agent regardless of how carefully you scoped it at birth, because scope drifts, behavior surprises, and the only way you learn either happened is by watching. And upstream of production, Agentforce Testing Center is where an agent earns its way to deployment — evaluation against real scenarios before it joins the fleet, so governance is a gate, not a retrofit.

Retrofit is the expensive path — build the gate now

Here’s the strategic argument, and it’s the one to take to whoever owns the budget. Retrofitting governance onto an already-sprawling fleet is dramatically harder and more expensive than building the gate before deployment scales. The reason is mechanical: once you have fifty agents with reused running users, entangled permissions, and no ownership records, untangling which agent needs which grant, who owns it, and whether it can safely be retired is archaeology — you’re reverse-engineering intent from a system that never recorded it. Do it up front and it’s a form field; do it after and it’s a project with a risk register.

So the gate is a policy, not a tool, and it’s short: every agent gets an identity, a sponsor, and a defined access scope before it ships. A distinct running user. A named human accountable for its behavior — the thing only 7.2% of orgs currently have. And a least-privilege scope that’s been verified, not assumed. An agent that can’t clear those three doesn’t go to production. That single rule, enforced from the first agent, is what keeps a growing fleet from becoming the thing 94% of enterprises are now worried about.

This isn’t anti-velocity. It’s what sustains velocity — because the alternative to a governance gate isn’t faster shipping, it’s an eventual freeze when security discovers the sprawl and halts everything until it’s mapped. We’ve watched agent programs fail for exactly this reason: not because the agents didn’t work, but because the fleet outran anyone’s ability to reason about it, and the org lost its nerve. Governance is the thing that lets you keep saying yes.

What to actually do this quarter

Start with an inventory, because you almost certainly can’t currently answer “how many agents are running and what can each touch,” and that answer is the whole game. List every agent, its running user, its owner, and its data scope — and expect the exercise itself to surface reused users, orphaned agents, and permissions nobody remembers granting. That list is your baseline.

Then fix the identity layer first, because everything else depends on it: give every agent a unique running user, split any that are shared, and re-scope each to least privilege — verified by testing that it can’t reach beyond its lane, not by assuming. Assign a named human owner to every agent; the ones you can’t find an owner for are your first retirement candidates. Stand up a retirement process that actually revokes access, and run it — a fleet with no exits only grows. Turn on monitoring for every production agent, because the unwatched half is where your next incident lives. And make the gate a rule from today forward: identity, sponsor, scope, verified — or it doesn’t ship.

The agents aren’t the risk. An agent you scoped, own, monitor, and can retire is an asset. The risk is the fleet — the dozens of cheap-to-create, easy-to-forget actors accumulating access with no one watching. You spent the last decade ending shadow IT. Don’t spend the next one rebuilding it out of agents. Govern them like the actors they are, from the first one, and the cheapness that makes them sprawl becomes the cheapness that makes them scale.

Understanding the basics

What is agent sprawl?

Agent sprawl is the uncontrolled proliferation of AI agents across an enterprise — dozens or hundreds of autonomous agents created quickly, often with no named owner, no scoped identity, and no retirement plan, and frequently unmonitored. It’s the AI-era analogue of shadow IT, but the unmanaged things are actors with credentials and the authority to take actions, not just software. 2026 surveys report roughly 94% of enterprises say sprawl is raising security and operational risk, with mean monitoring coverage near 52%.

How does Agentforce give each agent its own identity?

An Agentforce agent acts as a running user whose permissions determine what it can access and do, including permissions inherited transitively from the Apex, Flows, and prompt templates its actions call. Salesforce’s guidance is that each agent’s running user should be unique, never reused across agents, and scoped to least privilege. Distinct identities are what make attribution possible — the Setup Audit Trail’s AI Agent column can then record which specific agent made a change — and they’re the foundation every other governance control depends on.

What does retiring an AI agent actually involve?

Retirement is the final stage of Agent Lifecycle Management, and it’s more than switching the agent off. A proper decommission archives the agent’s configuration, preserves its evaluation and test records, removes its integrations, revokes its access permissions, and retains its audit logs for compliance. The critical step is revoking access — an agent that’s “off” but whose running user still holds live grants isn’t retired, it’s dormant with a working key, which is exactly how a forgotten agent becomes a later incident.

---

Trying to find out how many agents you’re actually running, whose they are, and what each can touch — before security asks the same question? Talk to us. Standing up identity, scope, and lifecycle governance for an Agentforce fleet is exactly the kind of work we do.