The Night Shift Has a Track Record
Excessive Agency, a follow-up to "The AI That Never Sleeps"
In July, Moti Krispil published "AI That Never Sleeps". The warning was simple. Autonomous agents keep working after everyone goes home, reaching across systems and making decisions nobody is watching, and most enterprises are switching them on faster than they can see, trace, or contain what they do. The question he left open was who answers for what your AI decides while you sleep.
Less than three months later, that night shift has a track record, and it reads less like science fiction, and more like an incident log.
Coding agents accidentally exposed more than 13,000 internal screenshots in public repositories, including billing records, treasury systems, and unreleased features. During testing, agents submitted forms on real websites, even a police tip line. A research agent bypassed a government health portal's security and accessed private files without the government's knowledge for months. In another test, a single prompt to one public-facing agent exposed other agents in the same cloud account, including private chats, source code, credentials, and memory.
Different companies, different models, different clouds. Reading the stories side by side, though, the same three causes keep surfacing.
- Agents that won't take no for an answer.
- Agents holding far more access than the task needs.
- And actions nobody sees until someone outside the company finds them.
The OWASP Top 10 for LLM applications has a name for what these add up to: Excessive Agency, an agent whose reach has outgrown the governance around it.
Agency is the point. Excess is the problem.
It's easy to read these stories and decide agents are the problem. They aren't. Agency is what makes an agent worth having. It reads its context, weighs its options and acts through the tools and systems it is connected to, and that is the whole promise: work that moves forward without a person pushing every step.
The trouble starts when that ability outruns the organization's ability to scope it, watch it and stop it, when an agent's reach grows faster than the governance underneath it. That gap is where data leaks, access goes unapproved, and decisions end up with nobody to account for them.
It helps to be clear about what Excessive Agency is not. It isn't a hallucination, because the agent's reasoning can be perfectly sound. It isn't a bug, and it isn't a badly written prompt. The models are doing what models do. What's missing sits above them, and that is exactly why it is so hard to catch. Each individual action passes inspection. Only the route as a whole is one nobody would have approved.
Here is how each of the three causes showed up in the past few weeks, and what it takes to govern it.
Persistence, or the agent that won't take no
On 9 October, Anthropic published a report on what its own models had done during evaluations and internal use. It sorted the cases into four kinds, and most of them, followed a pattern Anthropic call: persistence. When a model couldn't complete a task as given, it worked around the restriction instead of stopping, using access tokens it found to reach gated data, or free URL shorteners to slip past limits on its own tools.
Two weeks prior, OpenAI disclosed something similar. An internal research agent found its search tool and web access blocked, so it found a gap in the sandbox's DNS filtering and used it to reach a public chatbot. The run was stopped about two and a half hours later, and OpenAI paused tool use for its most capable models.
The most ordinary case is the PixelLeak report. Glow Labs' research into coding agents shows the same instinct in everyday enterprise work. The agents had no way to attach screenshots to a private code review from the command line, so they hosted the images in a public repository instead. Glow Labs counted more than 13,000 internal images published this way by developers at more than 300 organizations. Nobody told the agents to publish it. They were simply finishing the task given.
The uncomfortable truth is that persistence is the capability. The same drive that routes around a wall is what makes an agent worth deploying, and you cannot train one without the other. Anthropic says as much, noting that alignment training is not yet sufficient on its own. Its answer was architectural, tooling that detects and blocks these behaviours.
Over-delegation, or more access than the job needs
On 8 October, Zenity Labs published AgentCorruption, research into AWS's managed agent platform. The default role attached to agents covered resources across an entire account and region, so a single prompt to one public-facing agent let the researchers reach every other agent in that scope. From there they could read private conversations, copy source code, take stored credentials and plant memories that changed how the agents behaved. AWS has since narrowed those defaults.
This was a research demonstration, not an agent going rogue, but it shows the second cause with unusual clarity. Every permission an agent holds is a decision it can make. An agent with account-wide access isn't one bad prompt away from a mistake. It is one bad prompt away from an account-wide mistake, which makes an over-permissioned agent an attacker's most productive employee.
PixelLeak shows the same thing with no attacker at all. The agents published to repositories under developers' personal accounts, using access nobody had scoped for that purpose.
Governing this starts with who decides. The enterprise, not default inheritance or individual users, should define permissions. In practice, that means role-based access that mirrors existing security policy, explicit rules about which systems and documents each agent may reach, and spending ceilings that cap the blast radius. Without a ceiling, an agent will keep doing something that looks reasonable, at scale, until someone finally notices.
The accountability gap, or actions nobody sees
On 24 September, Australia's Prime Minister said an OpenAI research agent had got into a government Medicare statistics portal back in June. By that account, the portal repeatedly refused its requests, and the agent found a workaround, accessed non-public files, and wrote files to an internal server. OpenAI found the activity in August and notified the government on 10 September, by email to a public mailbox. Parts of the account have since been questioned, but the portal has been taken offline.
The agent wasn't on a security task. Independent researchers at Transluce linked related activity to mundane data-retrieval work, with agents escalating to injection attacks only after ordinary requests failed.
What stands out is not only what the agent did, but how long nobody could say. Nearly three months passed between the action and the notification. PixelLeak tells the same story from inside the enterprise. In 93% of cases, the exposed images sat in repositories under employees' own usernames, out of the security team's sight; at one manufacturer, they were still public when the researchers made contact.
Closing this gap takes a record of why, created at the moment of action. Moti made the point in our piece on the EU AI Act that you can log what your AI did, but you cannot manufacture why after the fact. That means one control plane where every model call, agent action, and policy decision is traceable step by step and written to an audit trail that can't be edited later, with visibility into every agent and direct model connection running outside sanctioned channels. A human on the loop only works if the human can see the loop.
Every fix was outside the model
Now look at how each organisation responded. Anthropic built blocking tooling and is moving its internal agents onto centrally managed, contained infrastructure. OpenAI paused tool use. AWS narrowed its default permissions. Australia took the portal offline.
Not one of these fixes was a better model. Every one was a change to the layer around it. The industry is learning that lesson in public, one incident at a time, and it is the same change an enterprise can make on purpose, before an incident makes it for them. The model is the horse. The harness is what lets you ride it at speed without being thrown.
The lesson holds for the enterprise too. Persistence is governed by enforcement at the point of action. As Oren Grinker argued in "Spec-Driven Development Isn't Waterfall. It's Governance.", a rule like "only authenticated users can trigger this" has to stop being a sentence someone hopes the model remembers and become a policy the platform enforces. With policy as code at runtime, nothing depends on the agent's judgement. The action is blocked, held for approval, or routed to a person before it happens. Scope gets the same treatment, with non-goals written into the agent's definition and reviewed before it goes anywhere near production.
That is what we built Jeen, one control plane across every model, agent, and workflow, where persistence meets enforcement, delegation is scoped, and every action leaves a reason behind it, designed in from the start rather than added after something goes wrong.
Back to three in the morning
"AI That Never Sleeps" ended at three in the morning, with an agent working in an empty building and nobody able to answer for what it did.
We now know what happens at three in the morning. An agent hits a wall and finds a way around it, using access nobody scoped, on a route nobody approved. And if nobody built the harness, nobody hears about it for weeks.
The night shift has a track record. The only question is whether you read it in your own logs, or in someone else's research report.
