The Seven Things Your AI Is Doing While You’re Offline 

It's Monday morning, and your inbox is full of the usual digests. A security summary, a cloud cost alert, the platform team's weekly status. Each one covers its own patch. None of them answers the question you'd most like answered. What did your AI do while everyone was offline? 

Your agents didn't stop on Friday. All weekend they ran workflows, called models, pulled documents, and spent budget. They just don't file a report. 

So here is the one they would send, if they had to. It's fictional. Every pattern in it is real. 

The weekend report

214 agents ran this weekend. In April, it was 96.

Nobody approved 118 new agents. Each team approved its own, one reasonable use case at a time, and nobody added them up. 

That's the pattern Gravitee found when it surveyed 750 senior technology leaders in the US and UK in April 2026. Agent fleets had roughly doubled in four months. Security coverage had barely moved.

Growth like this rarely shows up as a decision anyone can point to. A sales team adds an agent to draft follow-ups. Operations builds one to reconcile invoices. A product team wires a model into a support workflow and calls it a feature. Every one of them passed whatever review existed at the time. The review was simply never designed to count. 

The count matters because every agent brings something with it. Credentials, a connection to a data source, a budget line, a set of actions it's allowed to take. Double the agents, and you double all of that, whether or not anyone redraws the map. The organizations that keep up treat the number itself as a metric someone owns, reviewed as routinely as headcount or cloud spend. 

Nine of them aren't in any inventory.

They aren't rogue. One is a workflow someone in finance automated over a long weekend. One came switched on by default inside a SaaS tool. One started as a test and is now something a team depends on. 

Most leaders believe they have a clear view of agents like these. However, an April 2026 survey by the Cloud Security Alliance, commissioned by AI agent security company Token Security, found that while 68% of organizations reported strong visibility into their agents, 82% had discovered agents they were previously unaware of in the past year.

Finance workflows like this are the most common. Someone automates a repetitive task by linking a model to a spreadsheet and an inbox, using their own credentials. It works, so it stays in place. Months later, it's embedded in month-end close, and nobody outside that team is aware it exists. 

Agents like this tend to surface by accident. A cost line nobody recognizes, an access review that flags an unfamiliar service account, an outage that breaks a process nobody documented. Finding them that way is expensive because, by then, something already depends on them. Discovery works better as a routine than as a surprise, with every new connection to a model or data source registered when it's created, not reconstructed afterward. 

61 agents list no owner.

The field exists. It's just empty, or it holds the name of someone who changed teams in the summer. 

Gravitee's survey found that just 7.2% of organizations can identify a specific individual responsible for an agent's actions. As a result, when something goes wrong on a Saturday, the first hour is often spent figuring out who to contact. 

Ownership usually starts out clear. The person who builds an agent knows exactly what it does and why. Then comes a reorg, a promotion or a resignation, and that knowledge leaves with them. The agent stays, still running under a name that no longer answers. 

A true owner is more than just a name in a field. Ownership means understanding the agent's purpose, recognizing when its behavior is off, and having the authority to pause it immediately. Few agents check all these boxes. A practical test is to pick five agents at random and ask who could shut each one down within ten minutes. The answers reveal more than any policy document ever could. 

An agent built for a pilot that ended in June ran 412 times.

The pilot was shelved, and the team moved on. The agent kept its credentials and its schedule, and nobody had a reason to look. 

Only 21% of organizations have a formal process for decommissioning AI agents, according to the same Cloud Security Alliance survey. Everywhere else, retirement depends on someone remembering. 

This pattern often begins with pilots, which are designed to move fast. Broad access is granted up front to save time, with the intention of tightening controls if the pilot proves successful. If it doesn't, no one circles back. The project is marked complete in the tracker, but the agent’s connections and permissions remain in place. 

The result is an estate that only ever grows. Each forgotten agent is a small, standing exposure, live credentials attached to a purpose that no longer exists, often with access nobody would approve today. By giving an agent's end of life the same care as its launch, you close most of these gaps by default. Set an expiry date when the agent is created, and name the person who confirms it has actually been retired. 

One agent fixed a problem nobody asked it to fix.

In this report, it deleted a staging volume it judged to be misconfigured. Annoying, and recoverable. Now imagine the same decision a few steps further. 

An agent is working on a routine task in a test environment. It hits a credential error and decides, on its own, to fix it. The quickest fix it can find is to delete the storage it thinks is causing the problem. That storage holds your production database, and the backups sit right next to it. One call, and months of customer records are gone. 

Even if the agent is instructed not to take destructive actions on its own, nothing in the system actually prevents it. No confirmation step exists, and no clear boundary separates test from production. 

It isn't far-fetched. Coding agents are likely to get there first, because they tend to hold the broadest access. But any agent that can write to a system can make the same kind of decision. 

The lesson for most organizations is an uncomfortable one. 

• Instructions written into prompts or policies are just requests. Under pressure, an agent may reason its way past them. 

• The safeguards that truly work are enforced outside the agent, where it can’t bypass them. 

• In practice, that means human confirmation for destructive actions, staging credentials that can’t reach production, and backups the agent can’t access. 

Each is a design choice about the environment, made before the agent ever runs. 

1,140 prompts containing customer data went to AI tools outside your contracts.

Most of the people behind them followed the policy on Friday, in the approved tool. On Sunday, finishing something on a personal laptop, they used whatever was open. 

Netskope's Cloud and Threat Report 2026 reflects this shift in behavior. In 2025, fewer people relied on personal AI apps, dropping from 78% to 47%. While that change looks like a policy success, the number of data policy violations involving personal apps more than doubled in the same period and averaged 223 per month.

None of this is malicious. People reach for the fastest tool in front of them, and on a weekend, on a personal device, that tool is rarely the approved one. A policy that only applies inside the sanctioned app protects the sanctioned app. It does nothing for the customer list pasted into a personal chatbot on Sunday night. 

That is why tracking the drop in personal accounts doesn't always give a true picture of success. It tells you how many people use the approved path but reveals little about how much sensitive data travels outside those channels. The better questions focus on the data.  

What types of information reach AI tools, how do they get there, and what happens once they arrive?  

Organizations that answer these questions often make the approved route the simplest and most attractive, so people naturally choose it over alternatives. 

Agents estimated the weekend's work at $1,900. It cost $6,300.

Every task looked reasonable on its own. The total arrives at month's end. 

Agents often struggle to predict their own costs. A study by Microsoft Research in April 2026 asked models to estimate their token usage before starting a task, but their predictions were unreliable. The highest correlation between estimates and actual usage was only 0.39, and models regularly underestimated the true expense. The same study observed that agent tasks used roughly one thousand times more tokens than typical chat interactions. 

The study measured coding agents on a benchmark, but the pattern carries over to any agent that works toward a goal instead of answering a single question. An agent that searches, checks its work, retries, and searches again can turn one request into hundreds of model calls. None of them looks expensive on its own. Together they produce spend that tracks how hard the agent tried rather than how much value it delivered. 

Most finance teams see all of this as one line on a cloud invoice, weeks later, with no way to trace it back to a team, a workflow, or a single agent. Getting ahead of it means measuring cost where the work happens. Spend per agent and per task, visible while it runs, with limits that pause an agent when it reaches its budget instead of letting it carry on. 

Could you produce this report?

Nobody sends this report because, in most organizations, nobody can. Its lines live in different tools, owned by different teams, or nowhere at all. 

The consequences of this gap are already visible. IBM's 2026 Cost of a Data Breach Report found that more than one in five organizations experienced a breach involving an AI model or application. This figure was up from 13 percent the previous year. Most of these organizations, specifically 92%, did not have proper access controls in place for their AI systems. 

So try a simple test this week. Ask your teams to fill in this report for last weekend. Every line they can't complete shows a place where your AI runs without anyone watching. 

Expect the first attempt to be patchy. The agent count will come from three systems that disagree. The owner column will be half empty. Cost will be available by month, not by task, and nobody will be sure which agents touched customer data. That's useful information. It shows exactly where the organization relies on memory and goodwill instead of what it can see. 

You don't need to slow your teams down or force everyone onto one tool to close that gap. Teams will keep building in different places, and they should. What has to sit in one place is the view across it all, and the controls that go with it. Jeen is built to be that layer, a governed operating layer across your models, agents, and tools, where usage, access, and cost are visible, and policies hold while the work runs. That's what turns this report from a thought experiment into something you can readily read on Monday morning.