The Short Answer
A dormant AI agent is still a live identity until someone revokes its access. ibl.ai lets you run agents inside your own perimeter, so you own all the code and the data, and the inventory, logs and keys needed to retire them.
Two recent numbers frame the problem. Arrakis Security's 2026 Autonomous Agents Threat Report found about 76% of enabled agents had not run in 60 days, as Help Net Security reported.
Deloitte's 2026 State of AI in the Enterprise found 21% of respondents report a mature governance model for agentic AI. They measure different populations, but they point at the same gap.
What did the Arrakis report find about dormant AI agents?
The Arrakis report found that enabled agents commonly sit idle with their access intact. About 76% had not run in 60 days and 44% had not run in 180 days, according to the company's release.
The release says their credentials still work and their triggers still fire. It also says 24% of dormant agents can be started by an unsigned webhook from outside the organization.
Help Net Security adds that 19% of agents used API keys or tokens that never expired, embedded in their configurations. It also reports that 70% connected to at least one sensitive integration, and 99.4% of those had no verified data loss prevention on that connection.
How much weight can the 76% figure carry?
The 76% figure is real evidence, but of something narrower than its headline. It comes from thousands of agents in Arrakis customers' production environments over 12 weeks, so it describes one security vendor's customers, not every agent in the world.
Inactivity was measured from each agent's last recorded run. An agent on a quarterly schedule can look dormant at day 60 and be doing its job. So 76% measures inactivity, not abandonment, and no one outside those environments knows the true share of abandoned agents.
The finding that survives every caveat is the mechanical one. An agent that has not run for six months can still hold a working key, and in 44% of cases that first clause applied. Idle is a state of the schedule. Revoked is a state of the credential.
What does Deloitte's 21% actually measure?
Deloitte's 21% measures what respondents say about their own organizations.
The survey, fielded in August and September 2025, covered 3,235 IT and business leaders in 24 countries, all directly involved in their AI programs, and Deloitte reads the result as roughly 80% lacking mature governance capabilities for agentic AI.
Meanwhile 74% expect to use agents at least moderately by 2027, 23% extensively, and 5% as a core part of operations. Adoption plans are running well ahead of the controls.
It would be easy to go further and say that 80% of organizations cannot say what their agents decided, why, or when. Deloitte does not report that figure. It reports a maturity gap, and it names audit trails and real-time monitoring among the missing capabilities.
Which agent governance controls would catch a dormant agent?
Deloitte's article names decision boundaries, real-time monitoring and audit trails that capture the full chain of agent actions, plus cross-functional oversight.
It does not spell out retirement. Dormancy is what falls through that gap, so here are four controls to add, in order.
- Keep an inventory with one named owner per agent. An agent with no owner has nobody to answer whether it should still exist.
- Record the expected schedule. That turns "60 days idle" from a guess into a signal: a quarterly job is fine at day 60, and a daily job is not.
- Give credentials an expiry. A token that lapses fails safely, which fixes the 19% case without anyone remembering anything.
- Make retirement a revocation step. Removing an agent from a dashboard is not enough. Disconnect its tools, delete its keys and disable its triggers, then log it.
We covered the first of these in why the agent registry comes first, and the identity layer in why agents need corporate identities.
How do you retire an AI agent's access on infrastructure you own?
Retiring an agent's access means working from the connection outward, and it helps to hold the systems that record each piece. On ibl.ai, MCP connectors are scoped by organization, agent or user, and can be deactivated, disconnected or removed.
Agents on a Virtual Machine Shell get a stronger default: the VM starts with no network at all. If you open egress to bind a secret, the agent can call an API with a key it can never read, so it cannot print or log the key.
For evidence, Audit records who changed an agent's configuration and when, Transcripts shows the recorded conversations, subject to your privacy settings, and RBAC policies set who may reach which agent.
Be precise about what that gives you. We do not ship an automatic dormant-agent detector, and the owner and schedule above are decisions your organization still has to make. What ownership adds is that the records and the keys are yours to query and revoke, on your own timetable.
ibl.ai's Agentic OS is model-agnostic and has no per-seat pricing, so an unused agent costs no seat to keep. That is exactly why it still needs an owner.
What should a security team do this week about dormant agents?
A security team can start with one list and one number. Export every enabled agent, sort by last run, and split it at 60 and 180 days, the two Arrakis cut-offs. Then answer three questions for each: who owns it, what schedule it should be on, and what can it reach.
Anything with no owner and a sensitive connection goes first. For related risk in regulated finance, see what the Binance and Allium incidents mean for firms running agents.