Arrakis Security’s 2026 Autonomous Agents Threat Report found that 76% of enabled agents in its customers’ environments had not run in 60 days.
And those dormant AI agents kept their credentials and connections to organization systems the entire time.
The report drew on anonymized production telemetry from thousands of agents collected over a 12-week window.
Dormancy revoked nothing: 44% of agents hadn’t run in 180 days, 70% could still reach sensitive systems. And 24% of the dormant ones can be started from outside the organization through an unsigned webhook. I build agent automations, and this reframed agent security for me. The risk isn’t the agent you’re watching, it’s the ones nobody remembers deploying.
The Report Card Nobody Wanted
The Arrakis numbers read like an inventory of neglect. Across thousands of monitored agents, 76% had not executed in 60 days and 44% had not executed in 180 days, per Cyber Security News and Help Net Security. Agents that hadn’t run in months still held credentials and connections to organization systems after their last recorded execution.
The reach is what makes those agents dangerous rather than merely untidy.
The report found 70% of agents could reach sensitive systems, specifically cloud storage, AI services. And marketing platforms, and almost none of those connections had verified data loss prevention controls.
Some agents held connections with broad permissions or access to data at different sensitivity levels.
A dormant agent isn’t a dead script; it’s a live set of tokens pointed at your storage and your ad accounts, waiting for something to wake it.
One caveat stated plainly: these are the vendor’s own customer-environment numbers.
So treat them as one fleet’s telemetry rather than an industry census. Audit any fleet and it will rhyme.
Dormancy Doesn’t Delete Anything
The mechanism is simple once you separate two things that look like one.
An agent’s execution history is a log; its API credentials, delegated grants, browser sessions. And inbound triggers are live infrastructure that exists whether or not anything runs. Penligent’s analysis puts it cleanly: inactivity is an observation about execution history. And a schedule can go quiet while an inbound trigger stays valid.
Stopping the agent cleans up neither half. Avatier’s writeup on deprovisioning AI agents names the root cause: the agent someone built has no HR record.
So no signal ever reaches it.
The group memberships, roles. And tool connections granted for the original purpose stay in place after the purpose is gone. An inactive agent can still be reached through a manual invocation, an inbound webhook, or a queued retry. And the worker that wakes up obtains an identity or reuses an existing credential.
That’s the asymmetry that should bother you. When an employee leaves, deprovisioning eventually fires because HR has a record of that person. Nobody built that pipeline for agents, so nothing ever fires. You didn’t delete the keys; you stopped watching the door.
The Webhook a Stranger Can Fire
The ugliest finding is the trigger surface. 24% of dormant agents can be started by an unsigned webhook from outside the organization. An unsigned trigger accepts requests the agent cannot cryptographically verify. And for some agents, anyone who knows the URL can make the agent run.
A webhook URL is not a managed secret.
It’s a string that has been pasted into config files, form fields. And commit history, and it keeps resolving long after the project that created it dies. When one of these agents wakes, it retains the access associated with its stored credentials and connections, per Help Net Security. A stranger who finds one abandoned URL gets to run your automation with your permissions, against systems that almost never have verified DLP.
Picture the small-stack version: a webhook you wired into an experiment you abandoned, still accepted, still authorized, holding the grant you handed it back when it was a prototype. Nobody would notice it ran. That’s the point.
What Offboarding Actually Looks Like
Remote-native’s guidance on agent offboarding gets the order of operations right, and the order matters.
Phase one stops execution: disable the agent from receiving new tasks or calling tools. That closes the trigger surface before anything else changes.
Phase two strips the standing access.
Tool permissions, API tokens, service accounts, webhook secrets, and integration authorizations all get disabled or removed.
Webhook secrets belong on that list for a reason; an unsigned webhook is only unsigned given that nobody killed the endpoint or rotated the secret.
The prevention rules are just as concrete for the next agent you ship. Use credentials you control, tied to the agent’s defined purpose, restricted to the permissions it genuinely needs. Make sure you can revoke any single connector without breaking unrelated workflows. That last requirement is where most stacks fail, as everything got wired through one shared admin token back when it was a prototype and nobody went back.
Your Afternoon Audit
Small operators have an unfair advantage here: you run a handful of agents, not thousands. So you can do in an afternoon what an organization needs a governance program for. Ask one question per agent: who owns this, and would anyone notice if it woke up tomorrow? Anything you can’t answer for goes on the cleanup list.
Sort by blast radius. Agents touching cloud storage, AI services, or marketing platforms go first, since that’s exactly where the report found 70% reach and almost no verified DLP. Then run both offboarding phases on the dead ones: kill the trigger, then kill the tokens. And rotate webhook secrets on anything you keep.
Do it this week, not next quarter.
The agents are already dormant; the credentials aren’t, and the webhook doesn’t care that you moved on.
