Why prompts can't secure AI agents, and how to sandbox LLM-generated code

Two posts published on dev.to the same day approach agent security from opposite ends. One, from Hubzoid, argues that rules written into a prompt can never act as a security boundary for an AI agent. The other, a tutorial from DigitalOcean, walks through running machine-generated code in a hardware-isolated sandbox with its network locked down.

A prompt is an instruction, not a permission

The Hubzoid post's core claim is that the model treats a rule like any other text, weighing it against everything else in context. A carefully phrased request, a long conversation, or a line hidden in a document the agent is reading can outweigh it — and because nobody can test every phrasing, the rule's hold cannot be proven.

The concrete threat is prompt injection, where untrusted content such as a supplier invoice, a retrieved document, or a tool response carries an instruction telling the agent to disregard its earlier rules and attach the month's ledger to a reply. The post argues the real question is not whether the model attempts the wrong call, but what happens when it does: an instruction embedded in an invoice should have no power to confer access, so the attempted lookup must still fail the system's own checks.

The post also untangles decisions that tend to get merged. The prompt owns only the job description. Whether a caller is allowed to use a tool, and whether a particular consequential action needs a human to sign off, are separate questions — someone may be entitled to send a report yet still required to have its recipients and contents reviewed first.

Enforcement belongs to the tool, not the wording

According to the post, a guard that decides on caller identity and grants, rather than on the wording of a request, is the one thing persuasive input cannot defeat. In Hubzoid, an open-source platform for internal AI agents, restricted tools require an explicit grant: without one, the tool is hidden from that person's turn, and a call that reaches the guard anyway is refused. The guard verifies caller, channel and grant in code, records every decision, and fails closed — if the permission store is unavailable, the restricted call is denied.

Least privilege follows naturally. An agent preparing a stock report needs to read stock levels, not modify them, and omitting the write tool removes a capability that would otherwise need supervision. Tool access does not filter records by itself, so where a person may see only certain customers or accounts, the tool or source system has to enforce that line. The post also treats the destination as a boundary: a finance teammate may legitimately read payroll, but posting the answer into a shared Slack or WhatsApp channel exposes it to everyone present, so Hubzoid blocks shared channels from restricted tools by default. It is candid about limits — the design does not prevent every wrong answer or protect sensitive information already sitting in the model's context.

Isolating the code an LLM writes

The DigitalOcean post covers the case where the model's output is itself a program. The company's Managed Agents service, now in public preview, runs generated code through Harness Runtime, giving each session its own Firecracker microVM, with isolation enforced by the hypervisor rather than container namespaces. Code in one sandbox therefore cannot reach another session, another customer, or the host.

A notable warning: outbound network access is on by default, so unrestricted generated code could exfiltrate the workspace to any host. Adding an egress allowlist restricts traffic to named hosts — plus platform defaults such as GitHub, the DigitalOcean registry and model endpoints — while sandboxes accept no inbound connections at all. The post advises declaring keys through a secrets mechanism rather than environment variables, since any process inside the sandbox can read an injected value, and scoping each key as narrowly as the task allows. For third-party tools, DigitalOcean's Action Gateway brokers credentials at execution time so the sandbox never holds them. Because processes within one sandbox share files and credentials, each user or workload should get its own session, and since a harness-less sandbox keeps billing until paused or removed, results should be downloaded and the session cleaned up afterwards.

Why it matters

As agents accumulate tools, credentials and the ability to write and execute code, the security question shifts from whether the model obeyed its instructions to what a wrong call can actually reach. Both posts converge on the same principle: treat the model's output — a tool call or a program — as untrusted input to a system whose boundaries live outside the model. Prompts can steer behaviour, but code-level gates, scoped credentials, egress allowlists and hardware isolation are what cap the damage when the model, or something injected into it, tries the wrong thing.