--- title: "Dormant AI Agents Keep Their Credentials: What the 76% and 21% Numbers Mean for Governance" slug: "dormant-ai-agents-live-credentials-governance-gap" author: "ibl.ai" date: "2026-10-31 12:00:00" category: "Premium" topics: "AI agent governance, dormant AI agents, agent credentials, non-human identity, agent lifecycle management, Deloitte State of AI in the Enterprise, Arrakis, audit trails, agent security, RBAC" summary: "Arrakis telemetry found about 76% of enabled agents had not run in 60 days, and Deloitte found only 21% of organizations report mature agent governance. What the two numbers do and do not prove, and how to retire an agent's access." banner: "" thumbnail: "" linkedin: | Most AI agent risk conversations are about what an agent might do. Arrakis published a number about agents doing nothing. In its 2026 telemetry, about 76% of enabled agents had not run in 60 days, and 44% had not run in 180. The company says their credentials still work. About a quarter of the dormant ones could be started by an unsigned webhook from outside the organization. Read it carefully: this is one security vendor's customer data, and a quarterly job looks dormant at day 60 too. The number does not prove 76% of agents are abandoned. It does prove something simpler. "Not running" is not the same as "off". Deloitte's 2026 report, surveyed in late 2025, supplies the other half: 21% of respondents report a mature governance model for agentic AI, while 74% expect to use agents at least moderately by 2027. The fix is unglamorous. An inventory with an owner per agent, an expected schedule, credentials that expire, and a retirement step that actually revokes access. All of it depends on being able to read the logs and pull the keys. Owning the stack is one way to guarantee you can. #iblai #AgenticAI #AIGovernance #AISecurity #EnterpriseAI --- ## 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](https://arrakis.security/2026-threat-report) found about 76% of enabled agents had not run in 60 days, [as Help Net Security reported](https://www.helpnetsecurity.com/?p=388959). Deloitte's [2026 State of AI in the Enterprise](https://www.deloitte.com/global/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) 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](https://hackread.com/arrakis-security-report-finds-76-of-ai-agents-are-dormant-but-keep-their-credentials-and-connections/). 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](https://www.deloitte.com/us/en/about/press-room/state-of-ai-report-2026.html), 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.
  1. Keep an inventory with one named owner per agent. An agent with no owner has nobody to answer whether it should still exist.
  2. 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.
  3. Give credentials an expiry. A token that lapses fails safely, which fixes the 19% case without anyone remembering anything.
  4. 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](/blog/agent-governance-new-shadow-it-day-one-controls), and the identity layer in [why agents need corporate identities](/blog/ai-agent-corporate-identity-enterprise-security). ## 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](/docs/os/agent-settings/mcp) are scoped by organization, agent or user, and can be deactivated, disconnected or removed. Agents on a [Virtual Machine Shell](/docs/os/agent-settings/sandbox) 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](/docs/os/analytics/audit) records who changed an agent's configuration and when, [Transcripts](/docs/os/analytics/transcripts) shows the recorded conversations, subject to your privacy settings, and [RBAC policies](/docs/os/organization-settings/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](/product/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](/blog/binance-allium-breach-credentials-agent-security-financial-services). ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.