Running a coding agent on a server means something specific: a process is executing model output with your privileges, against your filesystem, on your network. That is not an argument against doing it. It is an argument for being deliberate about the blast radius.

Start with an honest threat model

Three things can go wrong, and they need different answers:

  1. The agent does something destructive by accident. Overwhelmingly the most likely. A confidently wrong rm, a migration run against the wrong database.
  2. The agent is manipulated. Prompt injection through a file it reads, a dependency's README, a web page it fetches. It has your permissions, so the attacker gets them too.
  3. The box is compromised by something unrelated. An unpatched service, a leaked key.

Credentials: the thing worth being strict about

An agent with shell access can read every file the user can. That includes ~/.aws/credentials, .env files, and its own API key.

  • Do not put production credentials on the box. If the agent needs a database, give it a copy with synthetic data.
  • Scope keys narrowly. A token that can read one repository is a smaller incident than one that can push to all of them.
  • Never bake secrets into cloud-init. On most providers, user-data is readable from inside the instance โ€” often via a metadata endpoint at 169.254.169.254. Anything you put there is readable by everything running on that machine, including the agent. Pass a short-lived bootstrap token instead and exchange it once for the real thing.

Control what the box can reach outbound

Most guidance obsesses over inbound. For a machine running agents, outbound is the interesting direction โ€” that is where exfiltration and abuse go.

The single highest-value rule is blocking outbound SMTP on ports 25, 465 and 587. No legitimate development workload needs to speak SMTP directly; transactional mail goes through an API over HTTPS. A compromised box, meanwhile, will try to become a spam relay almost immediately, and that is what gets an entire hosting account suspended.

Be aware of how your provider's firewall treats directions. On Hetzner, rules are allow-lists, and a direction with no rules is unrestricted. So "block three ports" actually means enumerating every port you still permit, as ranges around the blocked ones. Get the arithmetic wrong and you either re-open SMTP or sever all outbound traffic โ€” and neither failure announces itself.

Reduce the blast radius

  • Do not run agents as root. A normal user with sudo where needed. Most agent work does not require privilege.
  • One machine per tenant. If several customers or clients are involved, separate VMs โ€” not containers sharing a kernel.
  • Snapshot before anything destructive. The cheapest undo available.
  • Commit often. Git is an excellent safety net against an agent that goes off the rails, and it costs nothing.

Watch for the boring signals

You do not need a SIEM. Two things catch most real problems:

  • CPU pinned at 100% for hours on a box that should be idle. That is the cryptominer signature.
  • Sustained outbound connection attempts to many hosts. That is scanning, or a relay.

Where this leaves you

None of this is exotic. Separate users, least-privilege credentials, egress control, snapshots, and a habit of committing. The reason it is worth writing down is that agents make the consequences of skipping it arrive faster โ€” a mistake that used to need a tired human at 2am can now happen in a loop, confidently, at speed.