Two Security Architectures for AI Coding Agents: Sandbox-First vs. Analysis-First

1. A fundamental split: how to keep AI-executed commands safe

For an AI coding agent to participate in real development, it must read files, edit code, run commands, and reach the network. Once those capabilities exist, “how do we stop dangerous actions” becomes the first architecture question.

Across current agent implementations, two opposing engineering philosophies stand out:

• Fence first (sandbox-first): Do not assume the model is always correct. Use OS-kernel sandboxes to hard-limit what the agent can do. Even if the model is tricked or errs, out-of-bounds operations are blocked at the physical layer.
• Analysis first: Do not fully trust the model’s output. Use another LLM classifier to review the intent and risk of every command in real time, then combine that with permission rules to allow or deny.

This choice is not isolated. Tool count, file-edit style, permission granularity, and user experience all follow from it.

2. Comparing security models

2.1 Kernel-level sandbox (fence first)

Push the security boundary down to the OS:

• On macOS, use built-in sandbox execution (Seatbelt-style mechanisms).
• On Linux, combine Landlock, seccomp, bubblewrap, and similar kernel features.
• On Windows, isolate processes with restricted tokens.

A typical pattern is a few run modes—read-only, workspace-write, full-access—and every shell command runs inside the matching sandbox.

Strengths:

• Deterministic blocking. Kernel limits do not depend on prompts. Prompt injection, base64 obfuscation, environment-variable splicing, or novel attacks unseen by a classifier still fail if they cross the boundary. Resistance to bypass-style attacks is high.
• Relatively simple on the model side. There is no large rule engine in the model path; policy is the sandbox config.

Costs:

• High cross-platform cost. Each OS needs its own sandbox, and behavior can differ.
• Quieter UX. When the kernel rejects an action, the model often sees only a failure string. Users may not know why, and debugging gets harder.

2.2 LLM classifier plus permissions (analysis first)

“Use AI to review AI”:

• Maintain static rules such as path allowlists and denylists.
• Score every command with an LLM classifier.
• High-risk operations trigger interactive approval.

Strengths:

• Better interaction. Blocks can explain why a command looks dangerous, which educates the user.
• Lower cross-platform cost. Review logic is software-only and can be shared.
• Finer permissions. Control by tool, path, and operation type.

Costs:

• Weaker bypass resistance. Safety depends on correct analysis. Injection, command obfuscation, and novel patterns can fool the classifier. This is probabilistic, not deterministic.
• Latency and cost. Every command needs an extra model call.

2.3 An insight worth keeping

Security consensus: deterministic defenses beat probabilistic ones. Kernel sandboxes are physically immune to many attack patterns; classifiers depend on not being bypassed. Strong designs often stack both—sandbox as backstop, classifier for fine-grained governance, humans for approval. For attack surfaces such as injection that produces “ordinary-looking” malicious commands, see general guidance such as the OWASP LLM Top 10.

3. Comparing tool systems

3.1 Swiss Army knife: few tools, strong composition

Give the model a small set of tools (on the order of a dozen). The core is a shell executor; other work is composed as commands:

• File search: no dedicated tool; the model runs general searchers such as ripgrep in the shell.
• File edit: a transactional patch tool so one commit can change multiple files atomically.
• Web: CLI tools such as curl.
• Multi-agent work: spawn sub-agents in batches for parallelism.

Pros: high flexibility, lower token cost (small schemas, short system prompts). Cons: reliability depends on the user’s environment (whether rg/curl exist and which versions), poor observability (shell is a black box), coarse permissions (allowing shell allows almost everything).

3.2 Specialist toolbox: many tools, fine grain

Provide dedicated tools per task (40+), each with a clear I/O schema:

• Search: Glob/Grep tools, sometimes shipping a ripgrep binary to drop environment dependency.
• Edit: precise single-point edits with structured find-and-replace.
• Network: dedicated fetch and search tools that return structured results.
• Code understanding: LSP for go-to-definition, find-references, and similar semantic ops.

Pros: higher reliability (bundled deps), strong observability (structured steps for audit and replay), permissions per tool. Cons: higher token cost (schemas and descriptions consume context), less flexibility (the model can only do what designers anticipated).

4. How to choose: scenario-driven advice

There is no universal winner—only fit:

Scenario	Lean toward
Enterprise intranet, high compliance, injection resistance is a hard requirement	Sandbox-first, deterministic boundary
Interactive development, approval UX and audit logs matter	Analysis-first, fine-grained tools
Weaker models that need tool guidance	Specialist toolbox, less free-form action
Strong models, open-ended tasks	Few tools + shell, more flexibility

Regardless of path, these practices apply:

1. Defense in depth: Stack sandbox, rules, classifier, and human approval so one layer failing is not catastrophic.
2. Least privilege: Default to read-only; grant write and network only as needed.
3. Auditability: Trace commands and file changes; support replay and rollback.
4. Visible failure: Explain denials to both user and model so silent failures do not cause retry loops.

5. Closing

Fence-first vs. analysis-first is an inversion of trust: “trust the model, not the environment” vs. “trust the environment, review the model.” Understanding that split is more useful than memorizing any product’s feature list. When you build or select an AI coding agent, decide first which layer holds the security boundary; the rest of the design follows. On the cloud, you can also combine vendor container sandboxes, fine-grained access control, and logging to stand up an environment that balances safety and efficiency.