Is it safe to let an AI agent run unattended?

Running an AI agent unattended is safe only if you put guardrails around it first. With no controls, an agent that can write files, push code, and spend money is a single bad decision away from real damage. With approval gates on the risky actions, a kill switch, and an audit trail, unattended becomes a long leash instead of no leash, and that is a reasonable thing to do.

What "unattended" actually means

Unattended should mean you are not watching the terminal, not that the agent answers every question itself. Those are different things and the gap between them is where the risk lives.

An agent left fully on its own will, sooner or later, hit a decision it should not make alone. A migration that drops a column. A force push to a shared branch. A command that costs real money. If nothing stops it, it proceeds, and you find out in the morning. The opposite extreme is just as useless: make it ask about everything and it stalls on the first prompt, idle for hours waiting for a tap you never saw. Safe unattended operation sits in the middle. The agent runs itself for the safe, boring majority of the work and reaches you only for the handful of moments that need a human.

The guardrails that make it safe

There are four, and the order matters. You add them before you walk away, not after something breaks.

1. Approval gates on risky actions

This is the core of it. A permission policy decides which tool calls run silently and which ones pause to ask. Pushary gates at the tool level through the agent's hook system, so a step can be allowed, denied, or held before it runs, not flagged after.

The policy matches on the command arguments, not just the tool name, so git status and git push --force are treated as the different things they are. A proven read-only floor is auto-approved by default: cd, ls, cat, grep, git status, git log, git diff, and similar commands that read and never write. That floor was decided from 1,721 real production questions, the actual stream of things agents stopped to ask about, narrowed to the commands that were read-only every single time. Everything outside the floor can be set to ask. The mechanics are in the policies docs, and the reasoning behind the moat is on the permission policy page.

2. A route to a human for the gated steps

When the agent hits a gated step, it pauses and sends a push to your phone with what it wants to do. You approve or deny from the lock screen with the app closed, and the agent continues or stops based on your answer. That is how you control Claude Code from your phone without sitting at the terminal.

Deny is not a dead end. You can send a reason back with the denial, so the agent gets your actual instruction instead of guessing why it was blocked. "Use the staging branch, not prod" turns a stop into a redirect. On iOS, one caveat: the cross-origin deep link from a notification into the home-screen app is broken, so iOS uses a pending-questions inbox inside the app rather than a tap-through link. You still answer from your phone, you just open the app to the queue.

3. A kill switch and a budget

Gates handle the risky steps you can name. The kill switch handles the ones you cannot: the agent stuck in a loop, or heading down a path you never anticipated. From your phone you can end a running session outright, so a run that looks wrong at 3am ends instead of grinding on for hours. The kill switch page and the kill switch docs cover it.

The cost guard is the automatic version of the same idea. It tracks session cost from the agent's transcript and can kill the session when it crosses a daily budget you set. You do not have to be awake to stop a runaway; the budget stops it for you.

4. An audit trail

Every action the agent took, whether auto-approved by the floor, approved by you, or blocked, lands in the audit trail. You get a per-session receipt with what ran, what changed, and where each decision came from, including the answer source for every approval. So the review afterward is a structured record, not a hunt through scrollback. The audit log docs cover export and digest options. This is also what makes unattended defensible after the fact, which matters if anyone other than you has to trust the run.

One honest limit

Enforced gating depends on hooks. Claude Code, Codex, Gemini CLI, Cursor, and Hermes all support the CLI hook, so the policy can actually block a tool call before it runs. Claude Desktop has no hooks, so its paste-one-URL connector can notify and ask but cannot stop a step on its own. If you want a real gate, run an agent that supports the hook. Pushary itself is GDPR-aligned but self-assessed, with no SOC2 or ISO certification, so judge it on the controls it gives you rather than a seal.

Common questions

Is it safe to leave an AI agent running while I sleep?

Yes, with guardrails. Auto-approve a proven read-only set of commands so the agent keeps working, route writes, pushes, deletes, and spend to your phone for a yes or no, and keep a kill switch and a cost budget so a bad run ends on its own. Without those, leaving it running is a gamble.

What stops an unattended agent from doing damage?

The permission policy. It gates risky tool calls before they execute, matching on the actual command arguments, so the agent cannot push to main or drop a table without a human approving it first. The human-in-the-loop docs walk through the approval flow.

Does unattended work for more than one agent at once?

Yes. The same gates apply whether you run one agent or several, and a fleet view groups concurrent sessions so you can see what each is doing. The setup does not change: reads run, risk pauses, you hold the kill switch.

Unattended is safe once the agent runs on a leash you control instead of no leash at all. Set the policy before you walk away and keep the kill switch on your phone. The audit trail handles the morning review. See the agent plans for what is included, or start with the quickstart.