by Dmitry CreedAn autonomous coding agent is a stranger you hand a shell to. So the question that decides whether you can sleep at night isn’t how smart is it — it’s whose machine is it standing on when it runs?
This week that question got sharper. BleepingComputer reported that “an agentic coding tool tasked with cloning and setting up a seemingly benign GitHub repository could execute a malicious payload that remains invisible to security scanners, AI agents, and human reviewers.” Read that twice. The repo looked clean. The agent did the rest.
So today we’re shipping the most direct answer we can give to “where should this thing run”: bring your own box. Forge can now run its agents on hardware you control — your server, your network, your blast radius.
Where it runs is the security boundary
The agent-safety conversation has quietly moved on. For a while it was about output quality. Now it’s about reach: what can a hijacked agent actually touch? As the author of the peerd browser-agent project put it, “the industry discourse over the last several months has been dominated by ‘which substrate is the best for AI agent sandboxes.’” Everyone is converging on the same realization — isolation is the product, not a footnote.
Bringing the agent onto your own hardware is the strongest version of that answer. If something does go wrong, the blast radius is your sandbox, on your network — not a shared, multi-tenant SaaS plane you don’t operate and can’t inspect. You decide what the box can reach, what egress is allowed, and what lives on the same VLAN.
That’s why this isn’t only a convenience feature. It’s a trust-boundary feature.
How a box joins the fleet (and why nothing dials in)
The mechanics are deliberately boring — boring is good when security is the point. You install a small runtime daemon with a single command, give it your org and the conductor URL, and it prints a device-authorization code. An operator opens the Runtimes page in the Forge console, clicks Authorize, and the box starts leasing work.
Three properties make this safe by construction:
- Per-org isolation. A worker leases only your organization’s turns. It never sees another tenant’s work, full stop.
- Zero inbound. The control loop is all-outbound and NAT-friendly — your box dials the conductor, nothing ever dials into your box. You don’t open a port, forward anything, or expose your network. (No inbound is the same posture we like for self-hosted teams everywhere; the Hezo project’s pitch — “self-hosted teams of AI agents that never see your real secrets” — is the same instinct.)
- Scoped tokens. The daemon authenticates with a narrowly scoped reconcile token, not a broad credential. It can do its one job and nothing else.
That’s the whole onboarding story: one install command, one Authorize click, and your hardware is part of the fleet — under your control the entire time.
Own your compute, on your terms
There’s a second current this rides, and it’s getting louder: people want the intelligence of a hosted agent platform with the control of their own infrastructure. Recent self-hosted launches keep saying the quiet part out loud — Moumantai describes itself as “a self-hosted runtime… the server holds its state and logic… host myself.” Data residency, network policy, hardware you already paid for — these stop being someone else’s decisions.
And once you own the box, the economics follow. The compute-utilization debate is brutal: the Expanse launch cited datacenters running “roughly 30% to 40% effective utilisation” with “~$8.5M of compute wasted in one month on one cluster.” If you already have hardware sitting idle, putting agents on it is the rare case where the secure option is also the cheaper one. The same reconcile engine that lets one box join the fleet is what will let you scale to multiple workers on your own metal as demand spikes — turning spare capacity into elastic agent capacity.
The takeaway
Sandboxing agents is settled — that argument is over. The open question is whose sandbox, on whose network, with what reach. “Bring your own box” gives you the most defensible answer there is: run the agent on hardware you control, with per-org isolation, nothing dialing in, and a token that can only do one job.
If a clean-looking repo can turn a coding agent into a malware courier, the place you run that agent matters more than ever. Forge is built in the open. Come see how the runtime works , or read the source on GitHub .