AI Agent Sprawl: The Ghost Workforce Problem

In one week this summer, two security companies came out of stealth to sell the same product. Act Security raised 60 million dollars to reduce the access surface across cloud infrastructure for humans, workloads, and AI agents. Hush Security raised 30 million dollars, with Akamai joining as a strategic investor, to put every enterprise agent in a central registry with scoped just-in-time permissions and a single kill switch. Same city, same week, same problem statement: nobody knows what their AI agents can touch, and nobody built a way to take it back.

When two funded teams from the same talent pool bet on the exact same wedge in the same seven days, that is not a coincidence. That is a market discovering a hole all at once. The hole has a name now, and Gartner gave it one: AI agent sprawl.

Here is the durable version of the story, the one that will still be true after this week’s funding headlines are forgotten. You are not deploying features. You are hiring employees. Every agent you spin up gets a name, a set of credentials, and the keys to some part of your business. It works nights and weekends, it never asks for a raise, and it never, ever gets fired. You have built a workforce you cannot see and cannot offboard. I call it the ghost workforce, and it is the liability almost no founder is pricing.

What this post covers

• The problem: you hired a thousand employees and never built HR
• The framework: the ghost workforce
• You cannot govern what you cannot see
• Standing access is the loaded gun
• The lifecycle gap: you built hiring, not firing
• The identity explosion is non-linear
• The four sprawl liabilities
• Why this hits solo founders first
• The contrarian take: it is an HR problem, not a security problem
• What to do Monday morning: the offboarding test
• FAQ

You hired a thousand employees and never built HR

Start with the number that reframes everything. Gartner projects that by 2028 the average global Fortune 500 company will run more than 150,000 AI agents. In 2025 that same company ran fewer than 15. That is roughly a ten-thousand-fold increase in three years. And in Gartner’s own read, only 13 percent of organizations believe they have the right governance in place for any of it.

You are not a Fortune 500 company. You are a founder with a small team and a big appetite for automation, which means you hit this curve faster, not slower. The enterprise gets to 150,000 agents through committees and procurement. You get there because building an agent now takes an afternoon, and you have a lot of afternoons.

Each of those agents needs to authenticate to something. A database. An email account. A payments provider. A cloud console. A code repository. To do useful work, an agent has to carry credentials, and credentials are identity. So while your headcount says five people, your identity count says something very different.

The security industry has been measuring this quietly for years. Machine identities now outnumber human identities by about 109 to 1, according to Palo Alto Networks’ 2026 report, up from 82 to 1 a single year earlier. Of every 109 machine identities, roughly 79 are AI agents. Other vendors put the ratio at 144 to 1 or 80 to 1 depending on how they count, but the direction is not in dispute and neither is the slope. AI agent identities are projected to grow 85 percent in the next year alone.

Read that as a founder, not a security analyst. It means the org chart you can draw on a whiteboard is the small, visible tip of the real thing. Underneath it is a growing crowd of non-human workers, each holding a set of keys, most of them provisioned once and never reviewed again. That underwater crowd is where the breaches come from, because it is the part nobody is watching.

The framework: the ghost workforce

Most writing about AI agent security is about a single agent. How much autonomy should it have. What is the worst thing it can do in one action. That is a real question, and I have written a whole piece on how much autonomy to give a single agent and how to size its blast radius. But the blast radius of one agent is not the problem I am describing here. The problem here is arithmetic. It is what happens when you have five hundred of them and you have lost the list.

The ghost workforce is the accumulating population of credentialed agents that nobody offboards. It has four defining properties, and each one makes it worse than a human workforce of the same size.

It is invisible. You can name your human employees. You almost certainly cannot name your agents, their service accounts, and their tokens. Most teams have already lost track of what is running, where, and with what access.

It is credentialed. Every one of these workers holds standing access to real systems. A human employee’s access is at least loosely tied to a job and a manager. An agent’s access is tied to a script someone ran once.

It never leaves. Humans quit, get promoted, change teams, and get walked out by IT. Each of those events triggers an access review. Agents have no such events. The project ends and the agent keeps its keys.

It compounds. Because agents are cheap to create and free to keep, the population only grows. Nobody is incentivized to delete one. Deleting things is scary; leaving them running is easy.

Picture it as an iceberg. What you govern sits above the waterline: your people, your dashboards, the apps you bought on purpose. What breaches you sits below: the agents, API keys, tokens, and service accounts you provisioned in a hurry and forgot. You steer by the part above the line. The part below the line is bigger, and it is the part you hit.

The law underneath the picture is simple. Every agent you deploy is an employee you hired, credentialed, and never wrote a way to fire. Sprawl is not the count of agents. Sprawl is the count of agents multiplied by the access each one holds, multiplied by how long that access outlives its purpose. All three terms are climbing at once.

You cannot govern what you cannot see

Before you can fix sprawl, you have to admit how much of it is invisible. The uncomfortable finding from nearly every survey in this area is that most teams have already lost the map. In one widely cited report, 91 percent of the AI tools in enterprise environments were shadow AI, meaning they arrived without passing through any approval or inventory. Around 68 percent of employees use AI tools their IT function never sanctioned. And roughly 80 percent of organizations say they have already run into agentic AI risks they did not plan for.

Shadow agents are the ones that got deployed without going through a governance door, and they multiply because the door is optional. A developer wires up a helper over a weekend. A workflow tool ships an agent feature and turns it on by default. A vendor’s product quietly spins up its own agents inside your accounts, which is one more reason to take platform risk from the vendors you depend on seriously. None of these appear on a list, because no list exists, and each of them carries credentials to something real.

The discovery problem is why the two funded startups both lead with the word registry. You cannot revoke what you have not enrolled. You cannot scope what you cannot see. The first act of governing a ghost workforce is not writing a policy, because a policy governs the agents you already know about, and those are not the ones that will hurt you. The first act is a census. You have to find the workers before you can manage them, and finding them is harder than it sounds, because they were created by the same speed that makes them useful and they leave almost no paper trail. An agent is born from a script and a key, and neither one files an HR form.

This blindness compounds the lifecycle problem I am about to describe. If you cannot see an agent, you certainly will not offboard it. Invisibility and immortality are the same failure viewed from two angles. The agent you never inventoried is the agent whose access never expires, because there is no record that it exists to expire.

Standing access is the loaded gun

To understand why this matters, separate two things people constantly blur: the trigger and the gun.

The trigger is what makes an agent do something bad. Usually that is a prompt injection. Security researcher Simon Willison named the core version the lethal trifecta: give an agent access to private data, expose it to untrusted content, and let it communicate externally, and data exfiltration becomes trivial. The uncomfortable part is that every genuinely useful agent has all three legs. You cannot remove one without removing the usefulness. Removing the trigger is not really on the table.

The gun is what the agent can actually reach when the trigger fires. That is standing access. And this is the part founders control completely, which is exactly why it is worth your attention.

An agent with a poisoned instruction and no meaningful access is an annoyance. An agent with the same poisoned instruction and standing access to your production database, your email, and your cloud billing is a disaster with a fuse already lit. The injection did not create the danger. The danger was the access you left loaded and pointed at your own systems. As one security team put it plainly, an agent with data access is effectively a privileged user in your environment, whether you think of it that way or not.

Now add the property that makes agents uniquely dangerous: their access only ever goes up. A human’s access follows a sawtooth. It rises as they take on responsibility, then drops hard the day they leave or change roles, because offboarding is a real event that real people perform. An agent’s access follows a ratchet. It gets granted at creation, then extended every time someone needs it to do one more thing, and it is never walked back, because there is no moment in the agent’s life that forces a review. Access accrues and stays.

Security researchers have already catalogued what this looks like in production. A poisoned resume convinces a hiring agent to quietly ship salary and hiring data to an outsider. A crafted email persuades an assistant agent to forward its inbox contents to an attacker-controlled form. A malicious document handed to a helper coaxes out partial customer records. In every one of these cases the model did nothing exotic; it used exactly the access it had been given, aimed at a target the attacker chose. Take away the standing access and the same injection lands on an agent that cannot reach anything worth stealing. The exploit is only as bad as the keys in the agent’s pocket, and the keys are your decision, not the attacker’s.

This is also why the loops you build around agents matter as much as the models inside them. I have argued that loop engineering is the real moat in agent products, and access scoping belongs in that loop. A tight loop grants narrow access, does one job, and hands the keys back. A loose loop grabs broad access once and holds it forever because that was easier to write. The difference does not show up in a demo. It shows up in the breach.

The evidence that this is real is everywhere once you look. Roughly 91 percent of former employee tokens remain active after the employee is gone. Weak management of non-human identities, meaning API keys stored in code, static credentials, and orphaned service accounts, shows up in about 41 percent of breaches. When a project ends, the keys to the kingdom tend to stay live. Now multiply that human-world failure rate by an agent population growing ten-thousand-fold, and you can see the shape of the next decade of incidents.

This is a different failure mode from the one where agents fail silently and you never notice the bad output. Silent failure is about not seeing what an agent did. Standing access is about not limiting what it could do. You need both, but they are not the same control, and confusing them is how teams end up watching the wrong dashboard while the loaded gun sits in a drawer they forgot about.

The lifecycle gap: you built hiring, not firing

Here is the single sentence that made this click for me. An agent from a project that ended three months ago can still hold the same database access and API keys it received on day one. Read it twice. That is not a hypothetical. That is the default state of almost every team running agents today.

The reason is structural. When you deploy agents, you build an onboarding pipeline whether you mean to or not. Someone requests a capability, credentials get provisioned, the agent goes live. That path is smooth because it is the path to getting work done, and getting work done is what you optimize for. What you do not build, because nothing forces you to, is the offboarding pipeline. There is no detection step that notices an agent is idle or orphaned. There is no revocation step that pulls its credentials. There is no retirement step that formally ends its identity. The hiring machine is fully built. The firing machine does not exist.

The security world already knows the fix, and it has a name: zero standing privileges. No identity, human or machine, holds persistent access. Permissions are granted just in time, scoped to a single task, and pulled back automatically the moment the task is done. The agent’s identity stays stable so you can track it across its life, but the access underneath that identity is elevated only for the minute it is needed and never left lying around. Both Act and Hush are, at bottom, selling a way to make just-in-time the default and standing access the exception.

You do not need to buy anything yet to close the biggest part of the gap. You need to decide that an agent’s access has an expiry the same way an employee’s badge does, and then actually build the step that enforces it. The gap is not a technology gap. It is an attention gap. Nobody owns the firing machine because firing an agent produces no visible win, right up until the day it produces the only headline that matters.

The identity explosion is non-linear

The instinct is to treat agent identities like a bigger version of user identities, the way you would scale a table by adding rows. That instinct is wrong, and the reason is that human and agent identities have completely different lifecycles. Governing more humans is linear work. Governing more agents is not, because the very events that govern humans do not exist for agents.

Lifecycle stage	Human identity	Agent identity (default)
Discovery	HR system knows every hire	No inventory; most run unlisted
Provisioning	Role-based, reviewed by a manager	Whatever the script asked for, once
Access scope	Tied to a job function	Often broad, rarely trimmed
Review cadence	Periodic access reviews	None; access has no expiry
Offboarding trigger	Resignation, transfer, termination	No event ever fires
Audit trail	Named person is accountable	Often a shared secret, no owner

Every row in the agent column is a place where governance leaks. Stack them and the cost is measurable. Managing machine credentials already runs about 172,000 dollars a year per ten developers, and that is before the ten-thousand-fold growth lands. Organizations with weak non-human identity management are 22 percent more likely to suffer financial theft and pay roughly 150,000 dollars more to recover when they do. The raw material for these breaches is piling up in plain sight: researchers found 29 million secrets exposed on public GitHub in a single year, with leaks tied to AI services jumping 81 percent year over year.

Counting is harder than it looks, which is part of why the problem hides. A single agent may hold three separate credentials across three systems, so one worker on your mental org chart is three identities in your access logs. Rotate a key and the old one often lingers until something breaks. Copy an agent to a new project and its access quietly forks. The number you would guess if asked is almost always lower than the true count, and the gap between the guess and the truth is exactly the ungoverned surface. When I finally listed mine, I found agents I had genuinely forgotten writing, still holding live keys to services I had stopped using months earlier.

There is a second-order effect that makes the curve steeper than the headcount suggests. Agents create other agents. A supervising agent spins up workers. A workflow provisions a helper. Each spawned identity inherits or requests its own access, and none of them show up on an org chart. This is the same counting problem I described in the orchestration ceiling, but pointed at a different consequence. There, adding agents stops buying you speed. Here, adding agents keeps buying you attack surface. Coordination flattens. Risk does not.

The four sprawl liabilities

When I audit my own agent setups, the mess always sorts into four buckets. Naming them makes the cleanup tractable, because each one has a different fix and a different owner.

Liability	Why it compounds	The fix
Orphaned agents	Outlive their project, keep live keys, have no owner to notice	Inventory with an owner and an expiry per agent
Over-provisioned scope	Granted broad to save time; the extra access is pure downside	Least privilege, then just-in-time elevation
Shared and static secrets	One leaked key unlocks many agents; nobody can be held accountable	One identity per agent, short-lived credentials
No audit trail	You cannot answer what an agent did or touched after the fact	Log every action to the agent’s own identity

Notice that three of the four fixes are free. Inventory, least privilege, and one-identity-per-agent are discipline, not spend. Only the fourth, real runtime logging and just-in-time elevation, is where a tool starts to earn its price. Most founders reach for the tool first because it feels like progress. The order is backward. The discipline shrinks the surface; the tool watches what is left.

This slots into a bigger structure. If you have read my piece on the AI governance stack, treat identity sprawl as the layer underneath all of it. You cannot govern what an agent decides if you cannot even name the agent or revoke its keys. Identity is the floor. Everything else is built on top of it.

Why this hits solo founders first

It is tempting to file this under enterprise problems and move on. That is a mistake, and here is the counterintuitive reason: the sprawl ratio is worse for you than for a big company, not better.

A large enterprise has thousands of humans to dilute its agent count. When it hits 150,000 agents, it also has 100,000 employees, a security team, and a procurement process that at least slows the spread. You have five humans and an unlimited appetite for automation. Your ratio of non-human to human identities is not 109 to 1. Given how many agents a small AI-native team runs per person, it is often far higher. You are running a Fortune 500’s identity problem with a coffee shop’s staff.

You are also every role at once. You are the person who deploys the agent, the person who should review its access, and the person who would get the breach notification. When one person wears all three hats, the review hat is the one that falls off, because it is the only one with no deadline attached. Nobody schedules the meeting where you audit your own shortcuts.

The upside is that you can fix it faster than an enterprise ever could. You do not need a governance committee. You need one afternoon, a spreadsheet, and a rule you actually keep. The same speed that created your ghost workforce can clean it up, if you point it there on purpose. This is the same muscle as treating agents as first-class actors in your system rather than as scripts you forget about the moment they work.

The contrarian take: it is an HR problem, not a security problem

Everyone is racing to frame agent sprawl as a security problem, because security is where the funding is and where the fear lives. I think that framing quietly points you at the wrong fix. Security thinking asks how to defend the perimeter and detect the intrusion. But there is no intruder here. The threat is not a hacker slipping past your walls. The threat is a worker you hired, credentialed, and lost track of. That is not a security failure. That is an HR failure wearing a security costume.

Reframe it as HR and the whole problem becomes legible, because you already know how to run HR for humans. You would never let a contractor keep building-access and payroll rights for months after their contract ended. You would never hand every new hire the master keys because scoping their access was inconvenient. You would never lose the list of who works for you. Yet every one of those is standard practice for the agent workforce, and we excuse it because the workers are software.

The sharp, uncomfortable part is that nobody builds the ghost workforce but you. There is no adversary to blame. It accumulates one Tuesday at a time, one convenient over-grant at a time, each of them individually reasonable and collectively fatal. You are not being attacked. You are being sloppy in a way that will eventually be indistinguishable from being attacked. The good news hiding in that bad news is that a problem you created entirely by yourself is a problem you can end entirely by yourself.

Being honest about the other side: some sprawl is the price of moving fast, and a founder who governs every agent to perfection before shipping anything has made a different, worse mistake. The point is not zero agents or zero risk. The point is that you should know the size of the workforce you are running and be able to end any worker’s employment on demand. Right now most founders can do neither, and they have decided not to look. Not looking is a choice, and it is the choice that turns a manageable liability into an unbounded one.

What to do Monday morning: the offboarding test

Skip the platform evaluation. Start with a test you can run before lunch. Pick one agent you deployed three months ago and answer three questions.

One: can you name what it can access? Not roughly. Specifically. Which database, which scopes, which keys. If you cannot list them from memory or from a document in under a few minutes, that agent is a ghost, and it is almost certainly not the only one.

Two: can you revoke its access in under a minute? Actually do it in your head, step by step. Where do you go, what do you click, how do you know it worked. If the honest answer is that you would have to go hunting through several consoles and hope you got them all, you do not control that access. You are hoping nobody ever needs you to.

Three: can you prove nothing broke and nobody else is using its credentials? If the agent shares a key with three other jobs, you cannot revoke it without collateral damage, which means in practice you never will. Shared secrets are how a cleanup stalls forever.

That single test, run honestly, tells you your true governance posture better than any audit. Then build the fix in this order. First, inventory: one list of every agent, with an owner and an expiry date attached to each. An agent with no owner and no expiry gets deleted or adopted this week, no exceptions. Second, one identity per agent: kill the shared service accounts so every action traces to exactly one worker and you can fire one without firing the rest. Third, least privilege as the starting point, with just-in-time elevation for the rare moments an agent needs more, granted for the task and pulled back after. Fourth, a kill switch you have actually tested, because an untested kill switch is a comforting story, not a control. Fifth, put agent access review on the calendar as a recurring event, so the firing machine finally has a trigger the way human offboarding does.

None of this requires a purchase. It requires deciding that your agents are employees and running them like one. The same discipline shows up across the AI-native playbook: whether it is writing the spec before the code, deciding what to build versus buy, or knowing when to trust the output at all, the founders who win the AI era are the ones who keep a firm grip on the things they created cheaply. Cheap to make has never meant cheap to own.

Your agents are working for you right now, whether or not you remember hiring them. The only question is whether you could let one go today if you had to. Go find out.

Frequently asked questions

What is AI agent sprawl?

AI agent sprawl is the rapid, ungoverned growth in the number of AI agents running across a company and the standing access each one holds. Gartner projects the average Fortune 500 firm will run more than 150,000 agents by 2028, up from fewer than 15 in 2025. Sprawl becomes dangerous because each agent is a non-human identity with credentials, and most are created once and never reviewed, inventoried, or offboarded.

What is a non-human identity?

A non-human identity is any credentialed actor that is not a person: an AI agent, a service account, an API key, a token, or a bot. These identities now outnumber human identities by roughly 109 to 1 in 2026, and about 79 of every 109 are AI agents. They authenticate to systems and take actions just like human users, but they usually lack the lifecycle controls, such as reviews and offboarding, that human accounts get.

Why is standing access more dangerous for agents than for people?

A human’s access drops when they leave or change roles, because offboarding is a real event someone performs. An agent’s access is granted at creation, extended over time, and almost never revoked, because no event forces a review. Combined with prompt injection, that persistent access turns any compromised agent into a ready-made data exfiltration path. The injection is the trigger; the standing access is the loaded gun.

How is this different from limiting a single agent’s blast radius?

Blast radius is about one agent: how much damage a single wrong action can do, and how much autonomy to grant it. Sprawl is about the whole population: hundreds of agents you can no longer name, each holding access nobody revoked. You can size one agent’s blast radius perfectly and still be sunk by five hundred forgotten agents you never counted. Both matter, but they are different controls.

What is zero standing privilege?

Zero standing privilege means no identity, human or machine, keeps persistent access. Permissions are granted just in time, scoped to a specific task, and automatically revoked when the task finishes. The agent’s identity stays stable for tracking, but its access is elevated only for the moment it is needed. It is the leading fix for agent sprawl because it removes the loaded gun without removing the agent’s usefulness.

Do solo founders and small teams really need to worry about this?

Yes, and arguably more than enterprises. A small AI-native team runs many agents per human, so its ratio of non-human to human identities can be far worse than a large company’s. The founder is also the person who deploys agents, the person who should review access, and the person who receives the breach notice. The review step is the one that gets skipped, because it is the only one with no deadline.

What is the fastest way to assess my exposure?

Run the offboarding test. Pick one agent you deployed three months ago and answer three questions: can you name exactly what it can access, can you revoke that access in under a minute, and can you prove nothing else depends on its credentials? If any answer is no, you have a ghost workforce. It reveals your real governance posture faster than any formal audit.

How much does poor non-human identity management cost?

Managing machine credentials already costs around 172,000 dollars a year per ten developers, and weak management shows up in about 41 percent of breaches. Organizations with weak non-human identity practices are 22 percent more likely to suffer financial theft and pay roughly 150,000 dollars more to recover. With agent identities projected to grow 85 percent in a single year, those costs scale with the sprawl.

Every agent you deploy is an employee you hired, credentialed, and never wrote a way to fire. Build the firing machine before the ghost workforce builds your next incident. If this reframed how you think about agents, the companion piece on why judgment is the new bottleneck covers the human side of the same shift.