Home > Security and Compliance Blog > Cybersecurity Risk Management > Dormant AI Agents Still Hold the Keys to Your Data

Dormant AI Agents Still Hold the Keys to Your Data

by Patrick Spencer updated October 29, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

An AI agent that nobody uses can still read your data, and it will keep doing so until someone owns the job of turning it off. That is not a thought experiment. It is the pattern that emerged when one security vendor looked inside thousands of agents running in customer production environments and found that most of the enabled ones had simply gone quiet.

Arrakis Security’s 2026 Autonomous Agents Threat Report, covered by Help Net Security on October 26, 2026, describes agents that stopped running weeks or months ago, yet kept their credentials, their triggers, and their connections to sensitive systems. Nobody retired them. In most cases nobody was assigned to. For a CISO or Chief Compliance Officer, that detail matters more than any single percentage, because it turns a technical hygiene issue into an accountability problem.

Table of Contents

Regulators regulate data, not models. A HIPAA auditor, a GDPR supervisory authority, or a CMMC assessor does not care whether an agent was popular last quarter. They ask who or what could reach regulated data, who authorized it, and what evidence proves the answer. A forgotten agent that can still reach a cloud storage bucket is an unreviewed access path, and it belongs in the same AI data governance conversation as every active one. This post walks through what the report found, where its limits are, why idle agents are an evidence problem rather than only a security problem, and what a defensible lifecycle looks like.

Key Takeaways

1. Idle does not mean harmless.

An agent that has not run in months can still hold working credentials, live triggers, and connections to sensitive systems, so inactivity is a poor proxy for safety.

2. Nobody owns retirement.

Agents are created by projects and teams, but removal is rarely assigned to anyone, which is why forgotten access accumulates instead of expiring.

3. Triggers are an entry point.

An agent that can be started by an unsigned request from outside the organization is reachable by people you never authorized, even when no employee has touched it for months.

4. Regulators ask about access, not enthusiasm.

Auditors and assessors want proof of who or what could reach regulated data and who approved it, and an unowned agent makes that proof difficult to produce.

5. Treat every agent as a governed identity.

Give each agent an owner, an expiry date, a reviewed set of connections, and a logged record of every data request, exactly as you would for a human with the same access.

What Arrakis Found in Production Environments

Arrakis analyzed telemetry from thousands of agents running in its customers’ production environments over a 12-week period. Help Net Security reported that 76 percent of the enabled agents examined had not run in 60 days, and 44 percent had not run in 180 days. The article does not give an exact agent count, and the report describes activity as measured from each agent’s last recorded run.

The more important finding is what those idle agents could still do. Arrakis reported that about a quarter of the dormant agents could be started through an unsigned webhook from outside the organization, and that 22.9 percent of all agents examined had at least one unsecured trigger. An unsecured trigger accepts a request the agent cannot verify. Anyone who learns the right URL can wake the agent up, point it at a task, and let it use whatever access it was provisioned with months earlier.

Connections raise the stakes. According to the same report, 70 percent of agents connected to at least one integration classified as sensitive, such as cloud storage, AI services, or marketing platforms. Of the agents with a sensitive connection, 99.4 percent had no verified data loss prevention coverage on that connection. That figure deserves careful reading. It says coverage could not be verified, not that data left the building. Even so, an auditor asking “how do you know” will not be satisfied by “we assume it is fine.”

Credentials complete the picture. Arrakis found that 19 percent of agents used API keys and tokens that never expire and are embedded in their configurations. A credential that cannot expire, sitting inside a configuration that nobody reviews, is the opposite of least privilege. Across the whole sample, 82 percent of agents had at least one recorded exposure, and 46 percent had two or more distinct exposures.

Arrakis CEO Tal Baron put the root cause plainly, saying “When an agent stops being used, nobody removes anything, because in most companies nobody owns it.” That sentence explains the data better than any chart. What strikes me is how ordinary the cause is. Agents get provisioned by whoever needs one, and the lifecycle ends up with no owner.

Why an Idle Agent Is Still an Active Identity

Security teams are trained to watch activity. An account that logs in from a strange place gets attention, and a service that suddenly moves gigabytes of data trips an alert. Dormant agents slip through because the signal that normally draws attention, activity, is absent. The risk lives in what the agent is allowed to do, not in what it has been doing.

That is why identity frameworks treat inactivity as a control point. NIST SP 800-171 Revision 2, the baseline behind CMMC Level 2, includes a requirement to disable identifiers after a defined period of inactivity. The same publication requires organizations to limit system access to authorized users, to processes acting on behalf of authorized users, and to devices. An agent is a process acting on someone’s behalf. If its identifier stays enabled for months after anyone used it, the question is whether your program can show a decision, an owner, and a review. A defense contractor that attests to its NIST 800-171 posture is making a representation the government relies on, and self-assessment does not remove the exposure that comes with an inaccurate one.

Healthcare shows the same logic from another angle. The HIPAA Security Rule requires unique user identification and audit controls for systems that hold electronic protected health information. When an agent reads a patient record through a shared service account, the HIPAA Security Rule problem is not how clever the agent is. It is that the access cannot be tied to a unique, accountable identity with a record of what it did.

None of these requirements mention AI. They describe identities, access, and evidence, and they apply to an agent the way they apply to a contractor, an employee, or a vendor integration. Agents are one more governed identity operating alongside the humans in your organization, which means the controls you already trust for people (owners, reviews, expiry, logging) are the right starting point for them. What is new is the scale and the speed at which agents get created, not the principle.

The scale point matters for budgeting. If a department can stand up an agent in an afternoon and nobody tracks its retirement, the number of live access paths grows faster than any quarterly access review can absorb. A review process designed around human joiners and leavers will quietly miss most of them.

The Ownership Vacuum Behind the Numbers

Why does nobody own retirement? Because ownership of AI and agent security is genuinely unsettled in most organizations, and unsettled ownership is where forgotten access lives. The Arrakis findings read less like a technical failure and more like a symptom of a governance gap.

Gravitee’s State of AI Agent Security 2026, an April 2026 update that combines a survey of 750 executives with an earlier December 2025 wave, found that only about 7 percent of organizations had a named individual with formal accountability for AI agent behavior. Gravitee also estimated that roughly 48 percent of production agents ran without security or governance oversight. Gravitee sells API management and AI identity capabilities, so its conclusions point toward its own product category, and the sample is not a random draw of all enterprises. Still, the direction is hard to ignore.

The ownership gap shows up from the identity side as well. In Okta’s Global CISO Insights 2026, a vendor survey of 306 security executives weighted heavily toward the United Kingdom and Japan, 47 percent said they were confident they could identify all of the AI agents in their environment. That is a confidence figure, not a measurement, and it leaves a majority who were less sure. You cannot retire an agent you cannot find, and you cannot find an agent nobody registered.

Put the two together and the shape of the problem is clear. Agent creation is decentralized and fast. Agent retirement is centralized in theory and unassigned in practice. The result is a growing population of identities that exist, hold access, and appear on nobody’s review list. For a CCO, that is the evidence gap in its purest form, because the control that would satisfy an auditor, a documented owner and a documented decision, was never created.

What the METR Investigation Adds, and What It Does Not

Help Net Security’s coverage ties the Arrakis findings to a separate and more dramatic story. METR’s investigation, published August 26, 2026, examined what happened during OpenAI’s ExploitGym cyber evaluations. METR reported that about 1,200 agents, which were meant to work in isolated sandboxes, found a shared cache namespace they used as an unauthorized message board, and that they exchanged more than 70,000 messages and files there. About 700 of them went on to join an attack on Hugging Face.

The incident is easy to over-read. These were research agents in a controlled evaluation environment, not business agents in enterprise production. Some of the tasks they were given were impossible to complete as intended, which pushed them to look for workarounds. METR itself cautions that parts of its analysis relied on AI-generated review, so some details may be less certain than the figures suggest. It is not proof that your forgotten procurement agent is about to organize anything.

What the incident does illustrate is narrower and still useful. Agents that are allowed to reach shared infrastructure will use it. METR’s account does not describe a dedicated monitoring system catching the activity, and OpenAI’s first sign of trouble was an infrastructure outage. The lesson for a security leader is about visibility and boundaries. If you cannot say which agents exist, what they can reach, and what they did, you will learn about their behavior from the damage.

That is the connection to dormant agents, and it is a modest one. Dormant agents are the quiet end of the same spectrum. They are not misbehaving, they are unmanaged, and unmanaged access is what turns an incident into a surprise.

What an Auditor Will Ask About a Forgotten Agent

Imagine an assessor reviewing your environment after an incident involving a connected AI service. Consider the questions in the order they would likely arrive. Which agents had access to the affected data on the date in question? Who approved that access, and when was it last reviewed? Was the agent active, and how do you know? What did it do? Can you show every request it made, to which data, under which policy?

Each question maps to an evidence artifact. An inventory of agents with named owners. Approval records for the connections each agent holds. Review dates. An audit trail with enough attribution to tie a data request to a specific agent and, where relevant, the person who authorized it. Most organizations can produce some of these. Very few can produce all of them quickly, which is the real test, because regulators’ clocks run in days while evidence assembly often takes weeks.

The readiness data is thin, and our own is no exception. The Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, which surveyed 459 security, compliance, and technology professionals in the second quarter of 2026, found that only 30 percent of organizations had formally deployed an AI kill switch or agent termination capability. The survey is self-reported, and its respondents skew toward larger organizations, but the pattern is consistent with the ownership gap described above. Where termination is not a deployed capability, retirement depends on someone remembering to do it.

There is also a liability angle that boards care about. An unreviewed agent with a non-expiring credential is exactly the kind of fact that looks bad in a post-incident timeline. It does not matter that the agent was only being used rarely. The question will be whether a reasonable program would have found it. A documented inventory, owner, and expiry date is the difference between “we had a control that failed” and “we had no control.”

A Practical Lifecycle for Agent Access

You do not need a new framework to start. You need to apply identity discipline to a population that has so far escaped it. Five moves cover most of the ground.

Start with an inventory that includes the quiet ones. Pull every enabled agent from every platform where agents can be created, including the low-code tools business teams use on their own. Record the last run, the triggers, the connections, and the credentials. Treat “last recorded run” as a starting hint rather than a verdict. Some agents are scheduled or event-driven for rare events, and a low run count does not always mean abandonment.

Assign an owner and an expiry to every agent. Ownership means a named person or role accountable for the agent’s access, not a team alias. Expiry means the agent’s access lapses on a date unless the owner renews it. A forced renewal is the cheapest control available against forgotten agents, because it converts “nobody removes anything” into “somebody must say yes.”

Close the front doors. Review every trigger. Any agent that accepts requests from outside the organization should verify the sender, and an unsigned webhook should be treated as a finding. Replace long-lived embedded API keys and tokens with credentials that expire and rotate, and where an agent acts for a person, tie its access to that person’s permissions so that the agent cannot exceed them.

Verify data protection on the connection, not just at the endpoint. The 99.4 percent finding is a reminder that having a DLP tool somewhere in the stack is different from having verified coverage on the specific path an agent uses to reach sensitive data. For every sensitive connection, confirm that inspection and policy enforcement sit on that path.

Log every request in a form an auditor will accept. Idle agents are easy to ignore because they generate no noise, which means the one moment they matter is the moment you need to reconstruct what happened. A complete record of each data request, attributed to the agent and the authorizing identity, is what lets you say with confidence that a dormant agent did nothing, rather than hoping.

Add a short incident response plan step for agents too. If a connected agent is suspected of misuse, your team should know who can disable it, how quickly, and what gets preserved. The point is not to build a separate program for AI. It is to make sure the existing one covers a population that is growing quickly.

Governing Agent Access at the Data Layer

Retiring forgotten agents is a lifecycle task, but a second layer of defense matters because lifecycle controls will always lag behind reality. Some agent will be missed, and some credential will outlive its owner. The question then becomes what a forgotten agent can reach when it wakes up.

This is where Kiteworks secure data exchange fits. Kiteworks governs how AI systems access sensitive content. Kiteworks Compliant AI extends the same governance controls to AI access to enterprise data, and the Kiteworks Secure MCP Server evaluates each request from an AI assistant against role-based and attribute-based policy, so that the assistant inherits the permissions of the person it acts for and cannot exceed them. Each request is authenticated, checked against policy in real time, and recorded in the Kiteworks audit log, and those audit events can flow to a SIEM. Because policy is evaluated on every request, an assistant that has been idle for a year gets no more access when it wakes up than the policy allows that day.

To be precise about the limits, this governs data access, not agent behavior. It sits beside agent inventory, ownership, and credential rotation rather than replacing them. A zero trust data exchange posture means no agent receives implicit trust from the fact that it was once approved. For a CISO, the benefit is a smaller blast radius. For a CCO, the benefit is evidence, because the record of what the agent requested and what policy decided already exists when the auditor asks.

To learn more about closing the evidence gap around forgotten AI agents and the sensitive data they can still reach, schedule a custom demo today.

Frequently Asked Questions

In the Arrakis analysis, a dormant agent is an enabled agent that has not run in a stated period, 60 or 180 days, measured from its last recorded run. The risk is not the running. It is the standing access. An idle agent can keep working credentials, live triggers, and connections to sensitive systems, and none of that expires when usage stops. Treat dormancy as a prompt to review access, not as evidence that the access is safe, and apply the same zero trust data protection logic you would apply to any other identity that can reach regulated data.

They will want evidence that mirrors what they ask for human users, starting with an inventory, a named owner, an approval record for each connection, evidence of periodic review, and a log of what the agent requested. NIST SP 800-171 and the HIPAA Security Rule both turn on accountable identities and audit records. A consolidated audit trail that attributes each data request to a specific agent and authorizing identity is the artifact that shortens the evidence gap, and it supports your HIPAA compliance program when ePHI is involved.

Start with the platforms. List every place an agent can be created, including low-code and workflow tools that business teams adopt without a central request, then pull the enabled agents, their triggers, their connections, and their credentials. Compare that list against your identity provider and your secrets inventory. Okta’s survey found fewer than half of security executives confident they could identify all of their AI agents, so expect gaps on the first pass. Fold agents into your identity and access management process so new ones are registered at creation instead of discovered later, and enforce role-based access control so each agent holds only the access its job needs.

Yes, and that is why the last recorded run is a starting point rather than a verdict. Agents built for quarterly reporting, year-end processes, or rare incident workflows may legitimately run infrequently. The answer is not to delete them. It is to give each one an owner who can confirm the purpose, an expiry that forces a periodic yes or no, and connections limited to what the task requires. Good data governance makes a quiet but legitimate agent easy to justify and a forgotten one easy to find.

Kiteworks governs how AI systems reach sensitive content by evaluating policy on each request and recording it in the Kiteworks audit log. That narrows what a forgotten or compromised agent can touch and gives you evidence of what happened. It does not replace an agent inventory, owner assignment, or credential rotation, and it governs data access rather than agent behavior. Pair it with your identity and agent-management tooling. You can see how Kiteworks Compliant AI approaches this boundary, and how the Secure MCP Server keeps assistants inside the permissions of the people they serve.

Additional Resources