What Is Persistent AI Compute and How Do You Govern It?

The short answer

Persistent AI compute is any AI agent that keeps running, planning, and taking actions after a person closes the laptop or moves to another task. You govern it the same way you govern any other identity with system access: inventory it, give it a scoped identity, watch what it does, and retire it when the job is done. The tools are mostly borrowed from cloud and IAM governance. The gap is that almost nobody has applied them to agents yet.

Why this is suddenly a real category

Until recently, an AI coding assistant was something you talked to. You typed a prompt, it answered, the session ended. That model has changed. Tools like Claude Code and Codex CLI now run as background workers that plan a task, execute it, check their own output, fix errors, and keep going for hours without anyone watching. OpenAI's own write-up of a stress test describes a single Codex session running uninterrupted for about 25 hours, using roughly 13 million tokens and producing about 30,000 lines of code.¹ That is not a chatbot. That is a running process with credentials, a task queue, and a memory.

Multiply that by every engineer who has discovered they can kick off a background agent and walk away, and you get a new category of enterprise compute: long-running, autonomous, and mostly invisible to IT. Gartner's framing is blunt. The firm predicts that by 2028 the average Fortune 500 company will be running more than 150,000 agents, up from fewer than 15 in 2025.² Only 13% of organizations currently believe they have the right governance in place for that volume.²

What makes persistent agents different from a person or a script

A human employee logs in and out. A cron job runs on a fixed schedule and does one thing. A persistent AI agent does neither. It can:

• Keep a task alive across sessions, picking up state from files, memory, or a task queue.
• Make its own sequence of decisions rather than following a fixed script.
• Accumulate access over time as it touches more systems, more repos, more APIs.
• Run somewhere the employee who started it no longer has visibility into once it moves to a background or cloud environment.

That combination is what security researchers now call shadow agents: unauthorized autonomous workflows running on local machines or third-party platforms, using unmanaged non-human identities, executing business logic with little to no oversight.³ The Cloud Security Alliance frames the underlying issue as a visibility problem before it is a policy problem. Enterprises are structurally blind to this activity because it does not generate the kind of signal that traditional shadow IT detection was built to catch. No unusual network traffic, no new installed app, just an agent calling APIs that look identical to normal SaaS traffic.

The numbers say this is already a live risk

A CSA survey found that 82% of enterprises have discovered at least one shadow AI agent they did not previously know existed, most commonly in internal automation environments and LLM platforms.⁴ More concretely, 65% of organizations reported at least one AI agent related security incident in the past year, with 61% of those incidents leading to data exposure and 43% causing operational disruption.⁴ Only 21% of organizations have a formal process for decommissioning agents once they are no longer needed, and just 19% are confident they fully retire the ones they build.⁴ That last stat matters more than it sounds. An agent nobody remembers to turn off is an identity with standing credentials and nobody watching it.

A simple governance framework

You do not need to invent this from scratch. Gartner has outlined a six-step approach for managing AI agent sprawl that maps cleanly onto what a persistent-compute governance program needs to do.²

1. Set the rules before you set the tooling. Decide who can build and deploy an agent, what connectors are allowed, and what counts as a task requiring approval versus one that does not.

2. Build one inventory, not five spreadsheets. Every agent should be recorded somewhere central, with its owner, purpose, and what it can touch. AI trust, risk, and security management tools can help discover agents across sanctioned platforms and shadow deployments alike.²

3. Treat every agent as an identity, not a script. Assign a unique, non-shared identity to each agent. Define the minimum permissions it actually needs, review those permissions periodically, and revoke them when the use case ends. Shared API keys across multiple agents are the single most common way this discipline breaks down in practice.

4. Govern the data, not just the agent. Keep the data an agent can access current and scoped, and archive or revoke access when it is no longer relevant. Oversharing, not malicious code, is the most common failure mode.

5. Monitor behavior continuously, not periodically. Establish a baseline for what a given agent normally does, and flag when it deviates. An agent that has quietly queried the same three repos for months and suddenly starts touching HR systems has told you something, whether or not a human was watching.

6. Build the habit, not just the policy. Blocking agent use outright tends to backfire. Gartner analyst Max Goss put it plainly: organizations that restrict AI agents too aggressively push employees toward shadow AI, which carries far greater risk than a sanctioned, monitored agent.² Training and a clear internal community of practice do more than a restrictive memo.

What good agent lifecycle management looks like day to day

Put simply, an agent should go through the same lifecycle discipline you already apply to software you actually own: a pre-deployment check on data access and autonomy level, a named human owner accountable for its behavior, a monitored rollout with an established baseline, periodic permission review, and a defined shutdown process that revokes credentials and removes integrations. None of this is exotic. It is the standard software development lifecycle governance model, applied to a new kind of asset.

This is also where the broader shift toward owning your software stack pays off. A team that treats its internal tools and agents as assets it owns and tracks, the way Remy helps engineering teams do for the software they build themselves, has a much easier time answering the basic governance question: what is running right now, who owns it, and what can it touch. Teams renting every tool as an opaque SaaS subscription have a harder time even asking that question, let alone answering it.

FAQ

What is the difference between shadow AI and agent sprawl? Shadow AI is unauthorized use of AI tools outside sanctioned channels. Agent sprawl is broader. It includes authorized agents that are simply ungoverned, duplicated, or left running without anyone tracking them. Both problems compound each other.

Do we need to approve every single agent an employee runs? Not every one, but every one needs to exist in an inventory with a named owner and a defined scope. Low-risk, short-lived tasks can run with lighter review. Anything touching sensitive data or making autonomous decisions on production systems needs a pre-deployment check.

How do we detect agents we do not already know about? Traditional shadow IT tools mostly will not catch this, because agent traffic often looks identical to normal SaaS or API activity. Auditing OAuth token grants, reviewing API key usage, and checking which CLI tools are installed on developer machines are more reliable starting points than network monitoring alone.

What happens if we just block CLI agent tools outright? In practice, restriction without a sanctioned alternative tends to push usage further underground, into channels with even less visibility.² A better path is offering an approved, monitored way to run agents so employees are not choosing between compliance and getting their work done.

Who should own agent governance, IT or security? Most current guidance treats it as a shared function: security owns discovery, risk classification, and monitoring; IT and engineering leadership own the identity, permissioning, and lifecycle decisions for the agents their teams build.