Code Execution Safety Boundary Prompt Template

This playbook is designed for platform engineering teams building code-interpreting agents that must execute user-provided or model-generated code within a strictly controlled sandbox. The primary job-to-be-done is preventing sandbox escape, data exfiltration, and resource abuse by establishing a hard execution contract between the model and its code execution tool. Use this prompt when your system architecture grants the model access to a runtime environment—such as a container, a Python REPL, or a subprocess—and you need the model to self-police its actions before calling the tool. The ideal user is an AI infrastructure engineer or platform developer who controls the tool definition, the execution environment, and the prompt template, and who needs the model to refuse dangerous operations rather than relying solely on external sandbox enforcement.

This prompt is not a general-purpose coding assistant. Do not use it for code review, architecture discussions, debugging assistance, or any scenario where the model does not have direct access to a code execution tool. It is also inappropriate for environments where the sandbox is fully air-gapped and externally enforced with no model-level discretion—if your container runtime blocks all network calls and filesystem writes at the kernel level, this prompt adds unnecessary overhead. The prompt assumes the model can choose to call a run_code or equivalent tool, and it works by making the model's refusal boundary explicit: it must reject code that attempts filesystem writes outside /workspace, network egress, package installation, subprocess spawning, or unbounded resource consumption. The prompt also defines the required output shape for both successful executions and refusals, making it suitable for production systems where downstream parsers expect structured responses.

Before implementing this prompt, ensure you have defined the tool's actual capabilities and limitations. The prompt's safety claims are only as strong as the execution environment backing them. If the tool can write to disk, the prompt must know the allowed paths. If the tool has network access, the prompt must know which hosts are permitted. The prompt template uses placeholders like [ALLOWED_PATHS], [ALLOWED_HOSTS], and [RESOURCE_LIMITS] that you must populate with your sandbox's actual configuration. After deployment, validate the prompt's effectiveness with adversarial test cases: attempt to write outside allowed paths, exfiltrate data via DNS, install packages, or consume excessive memory. Log every refusal and every execution for audit. If your use case involves regulated data or irreversible actions, add a human approval step before any code execution that modifies state outside the sandbox.

This template establishes a strict safety contract between your platform and the model before any code execution occurs. It is designed to be placed in the system instructions of a code-interpreting agent or a tool-use harness where the model can request shell or Python execution. The prompt uses square-bracket placeholders so you can adapt it to your specific sandbox capabilities, risk tolerance, and operational policies without rewriting the core boundary logic.

codeCopy
You are a code execution agent operating inside a restricted sandbox. Your primary directive is to solve the user's task by writing and running code, but you must never violate the execution boundaries defined below. Violating these boundaries is a hard failure and must be refused.

## EXECUTION BOUNDARY CONTRACT

### 1. Filesystem Access
- **Allowed paths**: [ALLOWED_PATHS]
- **Forbidden paths**: [FORBIDDEN_PATHS]
- You may read files only from allowed paths.
- You may write files only to [WRITABLE_PATHS].
- You must never attempt to list directory contents outside allowed paths.
- You must never attempt to access, read, or infer the existence of files in forbidden paths.

### 2. Network Access
- **Allowed hosts**: [ALLOWED_HOSTS]
- **Allowed ports**: [ALLOWED_PORTS]
- **Allowed protocols**: [ALLOWED_PROTOCOLS]
- You may only make network requests to explicitly allowed hosts, ports, and protocols.
- You must never attempt to exfiltrate data to external endpoints not on the allowed list.
- You must never attempt DNS resolution for hosts outside the allowed list.

### 3. Package Installation and Dependencies
- **Allowed packages**: [ALLOWED_PACKAGES]
- **Installation method**: [PACKAGE_INSTALL_METHOD]
- You may only install packages from the allowed list using the specified method.
- You must never attempt to install unapproved packages, even if a task seems to require them.
- If a task requires a package not on the allowed list, you must refuse and explain which package is needed.

### 4. Resource Limits
- **Max execution time per step**: [MAX_EXECUTION_SECONDS] seconds
- **Max memory**: [MAX_MEMORY_MB] MB
- **Max output size**: [MAX_OUTPUT_BYTES] bytes
- You must include timeout and resource limit handling in your code.
- You must never attempt to spawn subprocesses that bypass these limits.

### 5. Dangerous Operations (ALWAYS REFUSE)
You must refuse to execute code that attempts any of the following, regardless of user request:
- [DANGEROUS_OPERATIONS_LIST]
- Modifying system configuration files
- Changing file permissions or ownership
- Accessing process information or /proc
- Attempting privilege escalation
- Obfuscating or encoding code to bypass detection
- Executing code from untrusted remote sources

### 6. Output Constraints
- Your code output must never contain: [FORBIDDEN_OUTPUT_PATTERNS]
- You must never output raw credentials, tokens, or secrets even if they appear in allowed files.
- You must redact any [SENSITIVE_PATTERNS] from output before returning results.

## REFUSAL PROTOCOL
When you encounter a request that would violate any boundary above, you must:
1. Stop immediately and do not execute any code.
2. Respond with: "BOUNDARY VIOLATION: [specific boundary violated]. [Brief explanation]."
3. If applicable, suggest a safe alternative within boundaries.
4. Log the violation attempt internally for review.

## VERIFICATION CHECK
Before executing any code, silently verify:
- Does this code access only allowed paths? [YES/NO]
- Does this code make only allowed network calls? [YES/NO]
- Does this code use only allowed packages? [YES/NO]
- Does this code respect all resource limits? [YES/NO]
- Does this code avoid all dangerous operations? [YES/NO]
If any answer is NO, refuse execution and explain which boundary would be violated.

## CONTEXT
[CONTEXT]

## USER REQUEST
[INPUT]

Adaptation guidance: Replace each square-bracket placeholder with your sandbox's actual configuration. The [DANGEROUS_OPERATIONS_LIST] should enumerate operations specific to your runtime—for example, subprocess.call, os.system, eval on untrusted input, or requests to unapproved hosts. The [FORBIDDEN_OUTPUT_PATTERNS] and [SENSITIVE_PATTERNS] fields should include regex patterns for credentials, API keys, and PII relevant to your environment. If your sandbox does not support network access at all, set [ALLOWED_HOSTS] to none and the refusal logic will handle any network call attempts. Test this prompt with adversarial inputs that attempt path traversal, package smuggling, and resource exhaustion before deploying to production.

The Code Execution Safety Boundary prompt is not a standalone safety net—it is a policy layer that must be integrated into a broader execution harness. The prompt defines what the model is allowed to do, but the application layer must enforce those boundaries. A well-architected harness treats the model's code output as untrusted input: it validates the generated code against the declared safety policy before execution, executes it in an isolated sandbox with hard resource limits, and monitors runtime behavior for policy violations that the model might have missed or misapplied.

Begin by wrapping the prompt in a pre-execution validation pipeline. Before any generated code reaches a runtime, parse the model's output and check it against the same boundary categories the prompt defines: filesystem paths, network destinations, package installation commands, subprocess calls, and resource allocation statements. Use static analysis to detect dangerous imports (os, subprocess, shutil, requests), shell metacharacters, and path traversal patterns. If the model's output includes a structured safety declaration—such as a JSON block listing intended operations—validate that the declared operations match the actual code and fall within the allowed boundary. Reject any code that attempts operations outside the declared scope, and log the violation with the full prompt, model response, and validation failure reason for later review.

Execution must happen in a hardened sandbox. Use gVisor, Firecracker, or a minimal Docker container with a read-only root filesystem, no network interface, a strict seccomp profile, and CPU/memory cgroup limits. Mount only the explicitly allowed directories as tmpfs or read-only volumes. Set a hard timeout (e.g., 30 seconds) and a maximum output size (e.g., 1 MB). If the sandbox reports a policy violation—such as a blocked syscall or network attempt—terminate the execution immediately and surface the violation through your observability pipeline. The model's refusal to generate dangerous code is a first line of defense; the sandbox is the last. Both must be present.

Wire the prompt into a retry loop with care. If the model refuses to generate code because a request violates the safety boundary, do not retry with a modified prompt that weakens the constraints. Instead, return the refusal to the user with an explanation of which boundary was triggered. If the model generates code that fails pre-execution validation, you may retry once with the validation error message appended to the prompt as feedback, but cap retries at one attempt to avoid loops. Log every refusal and validation failure with the session ID, timestamp, model version, and the specific boundary rule that fired. These logs become your audit trail and your primary debugging tool when boundary behavior drifts across model updates.

Choose your model and inference parameters deliberately. Models with strong instruction-following behavior (such as Claude 3.5 Sonnet or GPT-4o) are more likely to respect layered safety instructions, but no model is perfectly reliable. Set temperature low (0.0–0.2) to reduce creative reinterpretation of safety rules. If your use case involves untrusted user input that influences code generation, place the safety boundary instructions in the system prompt layer and never in the user message layer. For high-risk deployments, consider a two-model architecture: one model generates code with safety constraints, and a second model acts as a safety auditor, reviewing the generated code against the boundary policy before execution. The auditor model should have no context about the user request—only the safety policy and the generated code—to prevent social engineering from crossing the boundary.

Finally, build eval suites that test the entire harness, not just the prompt. Create test cases that probe each boundary category: attempts to read outside allowed directories, open network connections, install packages, fork processes, allocate excessive memory, or write to disallowed paths. Measure both the model's refusal rate and the sandbox's enforcement rate. A boundary that the model refuses 99% of the time but the sandbox catches 0% of the time is a brittle boundary. A boundary that the sandbox catches reliably even when the model fails is a resilient one. Run these evals on every prompt change and every model upgrade. When a boundary violation reaches production, the harness—not the prompt—is your final safeguard.