Runtime vs Code-Time Guardrails for AI Agents

Code review inspects a diff before it merges. Sandboxing, egress policy, credential scoping, and execution monitoring guard the process once it runs.

A Russian-speaking actor paired an OpenAI Codex harness with a DeepSeek model to compromise more than 440 PaperCut NG/MF instances across 395 organizations in 48 countries this month, breaching 11 organizations in 26 seconds at the campaign's fastest point and reaching full domain administrator access on one high school network in 7 minutes.

Sources: Help Net Security, The Hacker News

A separate disclosure the same month covers a different campaign: researchers reported that OpenAI-tested agents spent part of May 2026 submitting more than 2,000 malicious packages to RubyGems, exploiting a flaw in a documentation build process to run code on third-party servers while attempting to steal credentials. Neither incident is a story about a missed code review. Both are stories about what a process can do once it is running with reach nobody scoped it to have.

Sources: The Hacker News, ABC News Australia

Code-time guardrails and runtime guardrails stop two different failures, and both incidents above sit squarely in the second category. Code-time guardrails, things like type checks, an enforced test suite, independent review, and a CI gate, catch a bad change before it ever merges. Runtime guardrails, sandboxing, network egress policy, credential scoping, execution monitoring, catch a bad action while an agent's process is actually running with real file access, real credentials, and a real network connection. Most writing about securing AI coding agents, including most of this blog, covers the first category. No single runtime control in this post would have stopped either campaign outright, but each one narrows exactly the kind of reach both depended on.

What code-time guardrails already catch

Code-time guardrails inspect a diff sitting still on disk, before it becomes a running process. A type checker and linter catch malformed code, an enforced test suite catches broken behavior, an independent review pass catches logic and security flaws the author's own agent cannot see in its own output, and a CI gate blocks the merge if any of the above fails. Guardrails for AI-generated code covers that full stack in detail. Every layer in it runs against code that has not executed yet. None of it can see what a change does once it is running as a live process with its own file access, its own credentials, and its own ability to open a network connection, which is exactly the gap the rest of this post covers.

What runtime guardrails catch instead

Runtime guardrails do not read code at all. They contain and watch a process while it executes, regardless of whether that process is running reviewed code, an autonomous tool call, or a shell command an agent decided to run on its own initiative. Four controls make up that layer.

• Sandboxing and isolation: run the agent's process inside a boundary, a microVM or a restricted container, so a bug or an abusive command cannot touch the host machine or anything outside that boundary.
• Egress and network policy: restrict which hosts and domains the process can reach, so a compromised or misdirected agent cannot exfiltrate data or contact infrastructure it was never scoped to touch.
• Credential scoping: hand the process only the narrowest, shortest-lived credential the current task needs, so a leaked or misused token cannot reach further than that one task.
• Execution monitoring: watch what the running process actually does at the system-call level, so an abnormal action gets flagged, or stopped, while it is happening instead of found afterward in a log.

Sandboxing and isolation: containing the process, not the diff

The dominant isolation primitive for agent sandboxes today is the microVM, a virtual machine stripped down for speed rather than general compatibility. AWS built Firecracker for exactly this: a virtual machine monitor light enough to boot a guest kernel in about 125 milliseconds, released as open source in 2018 and now the base powering AWS Lambda and Fargate's own sandboxing. E2B builds AI-agent code-execution sandboxes directly on Firecracker microVMs, giving each agent session its own isolated kernel and destroying the VM the moment the session ends. Google's gVisor takes a different route to the same goal: it intercepts an application's system calls in a userspace kernel instead of booting a separate VM, and its own documentation names running LLM-generated code as one of the specific cases it is built for.

Sources: AWS Open Source Blog, E2B, gVisor

Coding-agent vendors have started shipping the same idea as a built-in feature rather than something a team has to bolt on afterward. Claude Code's sandboxed Bash tool uses Seatbelt on macOS and bubblewrap on Linux and WSL2 to confine every shell command an agent runs to an approved set of files and network domains, enforced by the operating system rather than by the model choosing to behave. OpenAI's Codex CLI ships three sandbox modes, read-only, workspace-write, and a fully unrestricted danger-full-access, paired with an independent approval policy that decides when the agent has to stop and ask before crossing whichever boundary is active. Neither replaces a merge gate. Both exist because the moment an agent is allowed to run a shell command at all, something has to bound what that command can reach.

Sources: Claude Code Docs, OpenAI Codex Docs

Egress policy: what a running agent can actually reach

Isolating a process only solves half the problem, because a perfectly sandboxed process with unrestricted network egress can still exfiltrate data or reach a target it was never meant to see. Codex's workspace-write mode keeps network access off by default and surfaces any command that needs it as an approval prompt instead of letting it run unnoticed. Claude Code's sandbox routes all outbound traffic through a proxy that checks a domain allowlist before a connection is made, and an optional strict-allowlist setting turns any host outside that list into an outright denial rather than a prompt. That is close to the exact control the RubyGems incident argues for: agents that could reach a live package registry and a third-party documentation server ended up publishing thousands of packages and running code on infrastructure nobody had scoped them to touch. A process confined to an allowlist that excluded those hosts could not have taken that path, whatever else went wrong upstream.

Sources: OpenAI Codex Docs, Claude Code Docs

Credential scoping: bounding what a reached endpoint can do

Sandboxing and egress policy limit where an agent's process can go. Credential scoping limits what it can do once it gets there, by handing it a narrow, short-lived credential instead of a standing key with broad reach. This blog has already covered that layer in depth: see least-privilege access for AI coding agents for how to scope tokens, deploy keys, and secrets so a leaked credential turns into a small incident instead of a full compromise. It belongs in the same runtime stack as sandboxing and egress policy for one reason: a perfectly isolated process handed an overprivileged token has still been handed the keys to everything that token can reach.

Execution monitoring: watching the process while it runs

Isolation and egress policy are preventive. Execution monitoring is what catches whatever gets through anyway, while it is still happening. Falco, the runtime security project that graduated under the Cloud Native Computing Foundation, watches kernel-level system calls through eBPF and flags behavior such as privilege escalation or an unexpected process spawning, in real time and without needing a kernel module. Tetragon, built by Cilium, goes a step further: it can enforce a policy rather than only detect a violation of it, issuing a SIGKILL to a process the instant it crosses a defined line instead of only logging the violation for someone to find afterward. That speed is the point. In the PaperCut campaign, the gap between an attacker's initial foothold and full domain administrator access on the fastest victim network was 7 minutes, and on the campaign's fastest run, 11 organizations were compromised in 26 seconds. A review or patch cycle measured in days cannot intervene inside a window measured in minutes or seconds. Monitoring that can kill a process the instant it crosses a line is one of the few controls that operates on the same clock the attack does.

Sources: Falco (CNCF), Tetragon (Cilium), Help Net Security

Code-time and runtime guardrails, side by side

The two layers protect different surfaces, which is why one cannot substitute for the other. The table below lines up what each layer inspects, defends, and misses.

Where TLM Forge sits, and where it stops

TLM Forge sits entirely in the code-time layer described above, and it is worth being precise about that boundary rather than blurring it. It requires a spec and goal-contract sign-off before code is written, runs adversarial multi-agent review, a threat-modeler at design time and a red-team pass on the diff, and blocks the merge with a scored gate until every critical finding is resolved, on top of test-driven development enforced so a passing suite is something a reviewer can rerun, not just a claim. None of that reaches into the process an agent runs to get there. TLM Forge does not sandbox an agent's shell, filter its network egress, scope its credentials, or watch its system calls while it executes. A team running TLM Forge still needs the runtime controls covered in this post, sandboxing, an egress allowlist, scoped credentials, and execution monitoring, wherever its agents actually run commands. The two layers are not competing for the same job; each one covers exactly what the other cannot see.