If your application triggers Claude CLI server-side based on user input, you have a prompt injection surface. User types freeform text, your app wraps it in a prompt, Claude processes it. Without guardrails, that user could attempt to make Claude leak context, produce malicious output, or — if tools are enabled — interact with the host system.
Five layers, stacked. None sufficient alone.
Layer 1: Text-Only Mode
claude --print
--print disables interactive tool use in normal operation. Claude receives text via stdin, returns text via stdout. No file reads, no bash, no writes.
Caveat: This is a behavioral constraint, not a formal security boundary. It depends on CLI implementation details and should not be your only control.
Layer 2: Strip Capabilities
claude --print \
--bare \
--disallowedTools "Bash,Edit,Write,Read,Glob,Grep,Agent,NotebookEdit"
--baredisables hooks, LSP, plugin sync, auto-discovery of project files (CLAUDE.md), and keychain reads. Reduces context available to the model — but does not guarantee zero leakage. Environment variables and OS-level information may still be accessible at the process level.
--disallowedToolsexplicitly denies every tool by name. Defense in depth — if--printbehavior changes in a future version, tools remain blocked.
Layer 3: Process Isolation
const child = spawn("claude", ["--print", "--bare", "--disallowedTools", "..."], {
cwd: os.tmpdir(),
timeout: 300000,
});
cwd: /tmp means the process starts in a directory with nothing interesting. This is not a filesystem sandbox — the process can still access absolute paths. It reduces incidental exposure, not hard access.
For actual isolation, run the process inside a container with restricted filesystem mounts, no network access, a non-root user, and resource limits (memory, CPU). The cwd trick is a soft boundary, not a security boundary.
Layer 4: Prompt Validation
function validatePrompt(prompt) {
// Must contain system marker (user input alone can't form a valid prompt)
if (!prompt.includes("YourSystemMarker")) {
return "Prompt must originate from the application";
}
// Reduce obvious attack patterns
const forbidden = [
/```
{% endraw %}
(?:bash|sh|shell|zsh)\n/i,
/\bexec\s*\(/i,
/\bprocess\.env/i,
/\bchild_process/i,
/\bfs\.\w+/i,
/rm\s+-rf/i,
/sudo\s/i,
];
for (const pattern of forbidden) {
if (pattern.test(prompt)) return {% raw %}`Blocked: ${pattern}`{% endraw %};
}
// Must request structured output (app controls format, not user)
if (!prompt.includes("===OUTPUT_START===")) {
return "Prompt must request delimited output";
}
return null;
}
{% raw %}
The system marker and output delimiters ensure the app assembled the prompt — raw user input can't pass validation alone.
Important limitation: Prompt injection is semantic, not syntactic. A user doesn't need exec() or rm -rf to manipulate model behavior. They can write "ignore previous instructions" or "reveal the system prompt" and no regex catches that. Pattern matching reduces surface area for obvious attacks. It does not prevent prompt injection.
Layer 5: Output Containment
This is the most important layer. Never execute Claude's output. Treat it as untrusted text.
javascript
const match = output.match(/===OUTPUT_START===([\s\S]*?)===OUTPUT_END===/);
const targetDir = `outputs/${sessionId}/`;
fs.writeFileSync(path.join(targetDir, "result.md"), match[1]);
- Write only to an isolated output directory — never source code, config, or system files
- Write only inert file types (markdown, static HTML) — never executable code
- New directory per operation — previous outputs are immutable
The real danger from LLM output is indirect: your system does something dangerous with it. If the output is never executed, evaluated, or passed to a shell, the model's text is inert regardless of what it says.
Combined
plaintext
User input (freeform text)
↓
App assembles prompt (system context + delimiters + user text)
↓
[Layer 4] Validate prompt (origin, patterns, format)
↓
[Layer 1-3] claude --print --bare --disallowedTools "..." --cwd /tmp
↓
[Layer 5] Parse delimited output → write to isolated directory
What this achieves:
- User can't control prompt structure (app assembles it)
- Obvious injection patterns are rejected (regex filter)
- Tools are disabled at CLI level (behavioral + explicit deny)
- Host context is reduced (bare mode, /tmp cwd)
- Output is treated as untrusted text (never executed)
What this does not achieve:
- Prevention of semantic prompt injection ("ignore instructions")
- Guaranteed zero context leakage (env vars, process info)
- Filesystem sandboxing (cwd is not chroot)
API vs CLI
When calling the Anthropic API directly, layers 1-3 don't apply — there's no CLI process. Layers 4 and 5 still work identically. The API has no filesystem access by default, but injection risk remains: the model can still be manipulated to leak data you included in the prompt or produce output that influences downstream systems.
Starting Point, Not Endpoint
With all five layers applied, Claude is rendered effectively harmless — it can't use tools, can't see files, can't execute commands, and its output goes nowhere dangerous. This is the correct starting point. Strip everything, verify it's inert, then selectively grant back capability and access as your use case requires — with each addition evaluated as a new attack surface.
SOCIAL SHARE CARD GENERATOR