Short answer
Yes, for most workloads, as long as you control four things before you walk away: what the agent can touch, what it can spend, where it runs, and what happens when it crashes. Scope its permissions, cap spending on the AI account, run it on its own machine, and have a process supervisor restart it.
The short answer
Yes, with conditions. Thousands of people run persistent agents like Hermes, Claude Code, Codex, and OpenClaw around the clock, and the overwhelming majority of unattended incidents are boring: the process died and nobody noticed, or a task loop burned more API credit than expected. Catastrophic stories are rare, and nearly all of them trace back to an agent that was given broader permissions than its job required.
The question that helps is "how far could the damage spread if this agent gets something wrong tonight?" That's the blast radius, and you set it before you walk away. Four things decide it:
- Permissions: what the agent can read, write, and execute
- Spend: how much money it can consume through your AI accounts
- Isolation: whether it runs next to your personal files or on its own machine
- Recovery: what happens when the process crashes at 2am
Get those four right and leaving an agent unattended is routine. Get them wrong and you're relying on luck.
Risk 1: the agent can touch more than its job requires
This is the risk behind most real horror stories. An agent asked to summarize emails does not need shell access. An agent that organizes your downloads folder does not need your SSH keys. But the path of least resistance during setup is to grant everything, click "always allow," and move on. That's fine while you're watching. Unattended, it means any mistake the model makes runs with your full authority.
The fixes are dull, and they work:
- Scope permissions to the task. Most agents have permission or tool profiles. Claude Code has an allowlist for commands and file paths. OpenClaw has
tools.profile. Use the narrowest profile that lets the job succeed, and widen it only when a task actually fails for lack of access. - Give the agent its own accounts where possible. A dedicated email address, a bot token with limited scopes, an API key with restricted permissions. If the agent misuses a credential, you revoke one credential, not your identity.
- Don't let an unattended agent keep credentials it only needed once. Setup often needs broad access, and running doesn't. Check what's still in the environment before you leave it alone.
With scoped permissions, a bad decision by the model ends up as a log line instead of an incident.
Risk 2: runaway spend
The most common unattended failure that costs real money is a loop: the agent tries something, fails, retries with a slight variation, fails again, and repeats for six hours. Each attempt is an API call. Nothing malicious is going on. It's a stuck process with a credit card.
The first control is a hard spending limit on the AI account itself. Anthropic, OpenAI and most other providers let you cap monthly spend or set billing alerts, and a hard cap turns the worst case from "a surprising invoice" into "the agent stopped at your limit." If you only do one thing from this article, make it this. It takes five minutes.
Subscription access helps too, where it fits. Running Claude Code on a Claude subscription or Codex on a ChatGPT plan means a stuck loop hits a rate limit instead of an open-ended meter. And give long-running tasks a budget in the prompt. Telling the agent to stop and report after a set number of attempts is crude, but it works, because well-behaved agents respect it.
Hosting doesn't change any of this. Whether the process runs on your laptop, your VPS or a managed platform, the spend flows through your AI account, so the cap on that account is the control that matters. The real cost of running a persistent AI agent breaks down the full cost picture.
Risk 3: it runs next to things it should never see
An agent on your personal laptop shares a filesystem with your tax documents, your browser sessions, and every credential your other tools have cached. Even with scoped permissions, that's a crowded place for something autonomous to live. There's a second problem too. Agents that read the outside world (web pages, emails, messages from strangers) can be fed instructions by the content they read. Prompt injection is a real, unsolved class of attack, and a clever prompt won't reliably stop it. The defense that works is making sure even a successfully hijacked agent has nothing valuable within reach.
Isolation fixes this, and in practice it's yes or no: either the agent has its own machine or it doesn't. A cheap VPS, a spare box or a managed VM all work. The isolated machine holds the agent, its workspace and the scoped credentials it needs. Everything else you own lives somewhere the agent simply can't reach. On Hivra, each agent gets a private virtual machine of its own, so you get that boundary without building it. The agent does real work inside its computer, and the computer is the boundary.
If you must run unattended on a shared machine, at minimum run the agent as a separate OS user with its own home directory. That's weaker than a separate machine, but it beats sharing your login.
Risk 4: silent death, the opposite failure
Ask people what they fear about unattended agents and they describe the agent doing too much. Ask people who actually run them what goes wrong and they describe the agent doing nothing: the SSH session dropped, the laptop slept, the OAuth token expired, the disk filled with logs. The task you trusted to the agent quietly didn't happen, and you found out days later.
This failure mode is pure infrastructure, and it has standard fixes: run the agent under a process supervisor (systemd, Docker restart policies, or tmux at minimum), monitor that it is actually alive, and check in on its first few unattended nights before trusting it with anything important. The mechanics are in why your AI agent dies when you close the terminal, and the full setup is in how to run AI agents 24/7.
Silent death is a safety issue too. An agent that crashes mid-task can leave a file half-written or a job half-migrated. Tasks you can safely re-run (idempotent ones) are the sign of a workload that's ready to run unattended.
The pre-departure checklist
Before leaving any agent to run overnight for the first time, walk this list. It takes about fifteen minutes.
- Permissions: does the agent hold any access this task does not need? Remove it.
- Spend cap: is there a hard limit or a subscription boundary on the AI account it uses?
- Isolation: is it on its own machine or VM, away from your personal files and credentials?
- Recovery: if the process dies, does it restart? Would you find out?
- Reversibility: can everything it is about to do be undone? Deleting, sending, and publishing deserve a human in the loop until the agent has a track record.
- Kill switch: do you know, right now, how you would stop it from your phone?
On reversibility, a sensible order is to let a new agent run read-only or draft-only tasks unattended first: research, summaries, monitoring, drafts for your review. Let it take actions with consequences only after weeks of watching it behave.
Does managed hosting change the safety picture?
Partly. A host can take some of these risks off your plate, and some it can't touch.
It handles isolation and the machine underneath the agent. On Hivra, every agent runs on its own private VM instead of your laptop or a shared container, so the boundary from risk 3 is there by default. Hivra runs that machine for you, paid plans are not paused for inactivity, and you get chat, terminal, and file access from a browser, which means you can check on the agent from your phone.
Know what runs inside that boundary, too. Hivra's chat runs the official Claude Code and Codex CLIs with permission prompts bypassed by default, so the VM is the boundary instead of a per-command prompt. The Permissions setting on the agent's Manage tab narrows that to Limited or Read-only. Anthropic's docs say the skip-permissions flag behind that default belongs inside a container or VM. Our guide to what the skip-permissions flag skips covers what a computer of its own leaves exposed, and what Hivra's defaults are. Hermes runs from Hivra's maintained build of the open-source agent.
What it can't handle is permissions and spend. Those stay yours under any hosting model. Hivra is built around bring-your-own login, so your Anthropic or ChatGPT account bills you directly, with no Hivra markup on that usage, and the spending caps you set with your provider are the ones that protect you. No host can decide which credentials your agent should hold. Hivra is independent and is not affiliated with Anthropic or OpenAI.
Run it with the boundaries already built
If you want to run an agent unattended without assembling the isolation pieces yourself, Hivra launches Hermes, Claude Code or Codex on a private VM. Plans start at $9.99 a month for 2 vCPU and 4 GB of RAM, paid plans are not paused for inactivity, and they come with a 7-day money-back guarantee on card payments. You bring your own AI login, keep your own spending limits, and can check on the agent from any browser. The permission decisions stay yours, including the Manage tab setting that decides how much a Claude Code or Codex agent may do on its computer.
Common questions
Is it safe to leave an AI agent running overnight?
For most workloads, yes, provided four things are controlled: the agent's permissions are scoped to its task, the AI account it uses has a hard spending cap, it runs on an isolated machine or VM rather than your personal laptop, and a process supervisor restarts it if it crashes. Most unattended incidents are a dead process or a costly retry loop, not a rogue agent.
What is the biggest risk of running an AI agent unattended?
In practice, over-permissioning. Most real incidents trace back to an agent holding broader file, shell or credential access than its job required, so a bad model decision ran with full authority. Scoping permissions to the task turns most mistakes into harmless log lines.
Can an unattended AI agent run up a huge API bill?
It can if nothing caps it. A stuck retry loop is the classic cause. The fix is a hard spending limit on the AI provider account itself, or subscription-based access where a loop hits a rate limit instead of a meter. Hosting choice doesn't affect this. Usage always bills through your account, so the cap on that account is the real control.
What about prompt injection? Can content the agent reads hijack it?
Prompt injection is a real and unsolved class of attack for any agent that reads untrusted content like web pages or inbound messages. The defense that works is limiting the blast radius: scoped credentials, an isolated machine, and human review for irreversible actions, so even a successfully manipulated agent has little of value within reach.
Which tasks should an AI agent not do unattended?
Anything irreversible without a track record: deleting data, sending messages to other people, spending money, or publishing publicly. Start a new agent on read-only and draft-only work such as research, monitoring, and summaries, then promote it to consequential actions after it has behaved well for weeks.
Does using a managed platform make unattended agents safe?
It helps with two of the four risks. A platform like Hivra provides isolation (a private VM per agent) and runs the machine underneath the agent for you, with paid plans that are not paused for inactivity, plus browser access so you can check on it from your phone. Permission scoping and spending limits remain your job under every hosting model. On Hivra, Claude Code and Codex run with permission prompts bypassed by default until you pick Limited or Read-only on the agent's Manage tab, and usage runs through your own AI accounts.