# Why Always-On AI Agents Are a Security Disaster Waiting to Happen Most AI agent frameworks today default to long-running or "always-on" processes. The agent wakes up, stays connected, and waits for the next task. On the surface this feels convenient. In practice, it dramatically increases your attack surface. ## The persistence problem When an agent runs continuously, several bad things compound: - It maintains live credentials or access tokens for extended periods. - Any vulnerability in the agent (prompt injection, tool misuse, library bug) has a much longer window to be exploited. - State and memory accumulate. Over time this creates a larger, harder-to-audit footprint. - You lose the natural boundary that comes from "this process only exists for this job." We've seen this pattern before with other infrastructure. Long-lived servers, always-on cron jobs, persistent background workers — they all became favorite targets once attackers realized the process would still be there tomorrow. AI agents are worse because they are *designed* to take actions on your behalf using powerful tools (shell, Git, APIs, file systems). Giving one of them a permanent home is asking for trouble. ## Real blast radius Consider a typical "always-on" research agent. It has read access to several repositories and a Notion workspace. It also has an API key for an LLM provider. If that agent is compromised: - The attacker can keep using the credentials as long as the process is alive. - They can exfiltrate data slowly over days. - They can wait for the agent to receive a new high-privilege task and piggyback on it. With an ephemeral agent the story is different. The container only exists for the duration of the mission (30 minutes, 2 hours, whatever you declared). When the TTL expires, the environment is gone. The credentials that were injected for that run are no longer usable by anything because the process that held them no longer exists. ## What "ephemeral" actually buys you Ephemerality is not just a nice-to-have. It is a security control: - **Reduced persistence window**: The agent can only act while it is alive. - **Natural cleanup**: No need to remember to revoke tokens after every run. The container death does it for you. - **Smaller audit surface**: You can reason about exactly what a single mission was allowed to do because the contract is explicit and time-bounded. - **Easier forensics**: When something goes wrong, you have a clear start and end for the incident. This is why military and high-security operations have used "raid" style thinking for decades. You don't leave special forces in the target area indefinitely. You send them in with a clear objective, strict rules of engagement, and a hard extraction time. ## How most frameworks get this wrong Many popular agent platforms optimize for "developer experience" by keeping agents alive. They offer nice dashboards, long-running loops, and background workers. These are useful for prototyping. They are dangerous in production. The usual justification is "resumability." If the agent dies, you lose progress. But resumability and permanence are not the same thing. You can snapshot state without keeping the executing environment alive. ## A better pattern Define the mission, give the agent exactly the tools and secrets it needs for that mission, run it in an isolated environment, capture the output and state, then terminate it. The next time you need similar work, launch a fresh agent with the previous state as context. The new agent gets fresh credentials scoped to the new mission. This is the pattern RAID was built around. A recipe (YAML) describes the entire contract — persona, allowed tools, policy rules, TTL, secrets by name, and whether state should persist. The agent boots, does the work inside a container boundary, and goes away. No background process is left holding the keys. ## The uncomfortable truth If your AI agent can read your code, write to your repos, or call internal APIs, and it is also designed to stay running indefinitely, then you have created a very attractive long-term target. Ephemerality is one of the few controls that actually shrinks the blast radius instead of just documenting it. Most teams building agents are still ignoring it. Don't be most teams.