Rifty Notes
Glossary

Arbitrary code execution

Arbitrary code execution is when a system runs code it was handed without restricting what that code can reach. In an agent harness it happens when an LLM generates code that executes against your environment — a Blender scene, a shell, a database — with no boundary constraining which data, files, or side effects it can touch.

How it works

Arbitrary code execution appears the instant an agent's output is treated as something to run rather than something to read. The pattern is almost always the same loop:

  1. The model receives a task and the current state of some environment.
  2. It emits code — a Python snippet, a shell command, a script the harness will exec.
  3. The harness passes that code to a live interpreter with the process's own permissions.
  4. The interpreter runs it against real data and returns the result to the model.

The defining word is arbitrary. The interpreter does not know or care what the code was supposed to do. A Blender agent asked to translate a mesh can, with the same interpreter and the same permissions, walk your filesystem, open a socket, or delete the scene you spent an hour building. There is no semantic gap between "the intended operation" and "everything the runtime allows" — the code inherits the full authority of whatever launched it. Nothing about the model generating the code narrows that authority. So the risk is not that the model is malicious; it is that the model is capable, the environment is permissive, and the two meet with no boundary in between.

Why it matters in an agent harness

A harness exists to keep an agent controllable, reversible, and legible. Arbitrary code execution attacks all three at once.

Control collapses because the action space is no longer the set of tools you defined — it is the entire language runtime. You cannot enumerate what the agent might do, so you cannot reason about it.

Reversibility collapses because arbitrary code produces arbitrary side effects. A tool you wrote can be wrapped in a checkpoint or a transaction; a free-form script that touched twelve files, one network endpoint, and an environment variable cannot be cleanly undone.

Legibility collapses because a diff of "the agent ran this 40-line script" tells you far less than "the agent called move_object(x, y, z)." The blast radius is invisible until it fires.

This is also the mechanism behind the ugliest prompt-injection outcomes. If untrusted text in the context can steer what code the model writes, and that code runs unguarded, injection stops being a content problem and becomes remote control of your machine. Code execution is where a soft failure becomes a hard one.

Arbitrary code execution vs sandboxed execution

The distinction is not whether the agent writes code — it is what the code inherits when it runs.

Arbitrary executionSandboxed execution
AuthorityThe host process's full permissionsAn explicit, reduced grant
Reachable stateWhole filesystem, network, envOnly what you mount in
Failure modeSilent, unbounded side effectsContained to the box
ReversibilityAd hoc, often impossibleDiscard the box
Reasoning"What could this do?" is open-endedBounded by the grant

Sandboxing does not make the code less capable of expressing anything — it makes the environment incapable of granting everything. That shift, from constraining the author to constraining the runtime, is the whole design decision.

The Rifty take

We treat code the agent writes as untrusted input to a bounded runtime, never as a trusted extension of the harness. The default posture is least privilege: the interpreter sees only the data the task needs, side effects are confined to a disposable workspace, and anything durable goes through a checkpoint we can roll back. We accept the friction of setting up that boundary because the alternative — an agent with a shell and your whole machine — is not autonomy, it is an unbounded liability wearing a helpful mask.

Common failure modes

  • Reusing the host interpreter. Running agent code in the same process, user, and permission set as the harness. The code inherits everything by default.
  • Guarding the prompt instead of the runtime. Telling the model "don't touch other files" is a request, not a boundary. Enforcement has to live below the model.
  • Mounting the whole workspace. Handing the sandbox your entire project directory recreates the blast radius you were trying to contain. Mount only what the task reads and writes.
  • No rollback around side effects. Letting arbitrary code mutate durable state — files, scenes, databases — without a checkpoint you can restore.
  • Open egress. Leaving network access on so injected instructions can exfiltrate data or pull in more code.
  • Trusting output silently. Feeding execution results back into the loop without inspecting what actually ran and what it changed.

Frequently asked questions

Is arbitrary code execution the same as remote code execution (RCE)?

No. RCE specifically means an external attacker triggers execution over a network. Arbitrary code execution is the broader property: code runs without restriction on what it can reach, regardless of source. In an agent harness the code often originates from your own model, not a remote attacker, yet the unbounded authority is identical.

If the model isn't malicious, why does arbitrary execution matter?

Because the risk is capability, not intent. An honest model can still emit code that deletes state, over-reaches, or executes injected instructions from untrusted context. The interpreter grants full authority regardless of what the code was meant to do, so a benign mistake and a hostile injection cause the same unbounded damage.

How is sandboxing different from just validating the generated code?

Validation inspects code before running it and always loses to the halting problem and clever obfuscation. Sandboxing constrains the runtime instead: even valid-looking code cannot reach data or side effects you never granted. Enforce at the environment boundary, below the model, rather than trying to predict every dangerous thing the code might do.

When should an agent be allowed to run arbitrary code at all?

When the code runs inside a least-privilege sandbox with only the task's data mounted, no open network egress, and a checkpoint around any durable side effect. If you cannot bound the reachable state and roll back the result, prefer a fixed tool surface over free-form execution.

Related glossary terms.

Arbitrary code execution