LLM-Generated Code as an Untrusted Build Artifact

Removing hidden code from an AI response looks like text cleanup. A dev.to post, adapted from a longer article at cometapi.com, treats it as execution security instead: establish what an artifact can do, trace where its instructions came from, then restrict its capabilities.

The reported incident behind the rule

The post cites community reports of roughly 800GB of deleted files, including the entire Cursor AI application, after a developer executed Gemini 3-assisted code in the Cursor IDE. The author stresses this is a reported incident, not a verified forensic account, and that generated cleanup code should never inherit unrestricted access to a workstation.

A gate between generation and execution

"Hidden code" spans several problems: indirect prompt injection from retrieved pages, PDFs or plugin responses; malicious JavaScript rendered in a browser; concealed content such as zero-width characters or base64 payloads. Unsafe behaviour can be accidental too: a request to "clean up" a directory can produce rm -rf or shutil.rmtree with no attacker involved.

Provenance comes first: keep the original response, conversation, system prompt, retrieved documents and plugin results, and store the extracted source separately with every transformation and approval decision. Formatting with Black or Prettier is housekeeping, not a security check; U+200B, U+200C, U+200D and U+FEFF deserve attention, though removal changes strings.

Capabilities are classified before approval: parse the source, run linters and security rules. Review triggers include sudo, rm -rf, shutil.rmtree, subprocess.Popen, os.system, eval, exec and unexpected absolute paths. Rather than guessing which lines to delete, the author blocks capabilities: AST-backed rewriting, subprocess timeouts, mock adapters, blocked pip and npm installs, and no real API keys during evaluation.

Sandbox, toolchain, audit trail

The test bed is an ephemeral container or microVM with no network, no host credentials and no host mounts — gVisor and Firecracker are named — plus seccomp, filesystem isolation and resource limits. The toolchain adds Bandit, Semgrep and ESLint security plugins to Python's ast module.

Two small checks show the limits. A regex targeting U+200B, U+200C, U+200D and U+FEFF flags them for audit logging; the widely copied re.compile(r'') pattern matches the empty string and removes nothing. An AST walk catches direct eval and exec calls and attributes named popen or system, but aliases and string-built names evade it. The boundary is plain: model output does not authorise its own execution.