AI Coding Agent Architecture: Sandbox-First vs. Reviewer-First

TL;DR

Two families of AI coding agents represent opposite engineering philosophies. Their main disagreement isn’t about which is stronger, but about where the security line is drawn:

• Sandbox-first: the operating system kernel sets a hard limit on what the agent can do, and safety comes from restricting its capabilities.
• Reviewer-first: the model judges the intent and risk of an action before it runs, and safety comes from semantic review.

This root choice determines almost every downstream design decision.

1. The Core Mental Model: Every Difference Traces Back to One Root Decision

The design differences between the two agent families may look scattered, but they are really different answers to the same question: how do you keep the AI safe while it runs commands?

Route	Trust in the model	Security mechanism	In one phrase
Sandbox-first	Trusts the model, but not its runtime environment	The OS kernel restricts what the AI can do	Trust the model + trust hard isolation
Reviewer-first	Does not fully trust the model	A language model classifier reviews what the AI wants to do	Use AI to review AI

This choice settles nearly everything else:

• If safety is delegated to the kernel, the model can be given as much freedom as possible. The tool set stays small, but policies have to be implemented separately for each platform.
• If safety is delegated to the model’s judgment, every action has to be nameable and classifiable. That makes the tool set grow and requires a unified, cross-platform permission layer.

These aren’t seven or eight independent decisions. They are a chain reaction from one root decision, and the five dimensions covered below all trace back to it.

2. The Security Model: Where Uncertainty Gets Stopped

2.1 Sandbox-First: It Doesn’t Ask About Intent, Only About Capability

Sandbox-first security doesn’t depend on understanding what a command means. It asks one question: do the resources and privileges an operation needs fall within the capabilities declared for it in advance? Common capability boundaries include:

• File system: the workspace is writable by default; files outside it are read-only or invisible by default.
• Network: outbound internet access is blocked by default, and only allowlisted domains are reachable when necessary.
• Privileges: the agent runs with ordinary user privileges and discards high-privilege tokens it doesn’t need.
• Resources: CPU, memory, execution time, and the number of concurrent processes are capped.

The operating system kernel enforces these limits, typically through:

• System call filtering, so only the system calls an application needs get through.
• User namespace isolation, which gives a process its own view of users and privileges.
• Bind mount control, which decides which directories are writable and which are read-only.
• Restricted tokens, which strip high privileges from a process.

Even if malicious content tricks the model, it can’t carry out anything beyond its capability boundaries.

In the typical three-tier model, privileges relax step by step:

• Read-only: the agent can inspect and analyze code but can’t modify files.
• Workspace-write: the agent can modify the workspace. Whether it can reach the network depends on configuration.
• Unrestricted: guardrails are mostly removed, so use this tier with great care.

Main strengths

• Strong resistance to bypass: interception happens in kernel space and is deterministic, so there is no room for misjudgment.
• Immune to novel attack techniques: however new an attack is, any action that crosses a capability boundary gets blocked.
• Predictable performance cost: guardrail checks run on the kernel path and don’t consume any model inference.

Main limitations

• Expensive to implement across platforms: sandbox mechanisms differ widely between the major operating systems, and each platform needs its own implementation and validation.
• Poor failure feedback: guardrails tend to reject an operation without explaining why. The model may then retry the same action and get stuck in a fruitless loop.
• Security depends on configuration: once the boundaries get too coarse (say, the whole user home directory is writable), the guardrails become meaningless.
• Granularity vs. usability: the finer the guardrails, the more likely they are to block legitimate operations, which means granting exceptions all the time.

2.2 Reviewer-First: One Model as the Gatekeeper for Another

Reviewer-first designs don’t rely on kernel isolation. Instead, a language model classifier assesses the risk of each action before it runs. The typical flow is:

1. The model proposes an action.
2. The system first checks the action against deterministic rules, such as path allowlists and denylists.
3. Any action that doesn’t match a rule is scored by the classifier.
4. Based on the score, the system lets the action through, asks the user to approve it, or rejects it.

These designs usually also combine session settings, project-level configuration, and user-level configuration into stacked layers of permissions.

Main strengths

• Consistent across platforms: one set of permission logic runs everywhere.
• Clear feedback: the approval dialog can explain why a permission is needed, so users can make an informed decision.
• Semantically precise: the system can tell how risky “read test logs” is compared with “export production data”.

Main limitations

A classifier is a model too, so its judgments can only approximate correctness. It has three main attack surfaces:

1. Prompt injection: an attacker hides instructions in code comments, dependency descriptions, or web content to trick the agent into generating commands that look harmless but are actually dangerous.
2. Command obfuscation: a dangerous operation is split up, encoded, or assembled from pieces so it no longer looks high-risk. For example, a command can be base64-encoded, then decoded and run. Or the real command can be built indirectly from environment variables or script files.
3. Novel attacks: patterns the classifier never saw during training or rule design are hard to detect reliably.

All three target the judgment rather than the boundary.

2.3 Side-by-Side Comparison

Dimension	Sandbox-first	Reviewer-first
Core mechanism	Kernel-level sandbox	Model classifier + layered permissions
Main implementation	Native sandbox features on each platform, such as system call filtering, namespaces, controlled mounts, and restricted tokens, often used with a lightweight container runtime	Path rules + classifier scoring + interactive approval
Resistance to bypass	Very high: the kernel blocks deterministically	Lower: depends on whether the analysis is correct
Against novel attacks	Blocked by capability limits	May be bypassed
Cross-platform cost	High: implemented separately for each platform	Low: one set of logic works everywhere
User feedback	Fails silently, with little explanation	Explains the reason interactively
How security fails	Configuration is too permissive, and the guardrails become meaningless	A misjudgment lets a dangerous action through

The fundamental difference: sandbox-first is physically immune to manipulation. No matter how the agent is tricked, the kernel blocks any action that crosses a boundary. The reviewer-first defense holds only if the classifier recognizes the manipulation.

3. The Tool System: General-Purpose or Specialized Toolbox

Once the security model is set, the tool system naturally splits into two forms.

Dimension	General-purpose tools	Specialized tools
Number of tools	Few	Many (dozens)
File search	No built-in search tool; the model runs command-line search programs	A dedicated search tool with a built-in high-performance search binary
File editing	Patch-style editing: modifies multiple files in one call and can commit them as a transaction	Single-spot editing: changes one place at a time and writes it to disk right away
Shell execution	A single shell tool that runs inside a kernel sandbox	A single command-execution tool that runs after a permission check
Network access	Command-line HTTP clients invoked through the shell	Dedicated web fetch and search tools
Code understanding	No dedicated tool	Tools for understanding code, built on the Language Server Protocol
Multi-agent	Supports spawning agents in bulk	Supports spawning and managing subagents

• General-purpose tools (the Swiss Army knife): the model gets a shell and a few primitives and combines commands on its own. The model has almost as much room to operate as a human engineer, and any new task it can do needs no new tools.
• Specialized tools (the professional toolbox): high-frequency operations get purpose-built tools with clear inputs and outputs, and search, fetching, and code analysis come with their dependencies built in. Call parameters stay under control, results can be validated, and errors are structured, which makes it easy to collect statistics and audit activity at a higher layer.

How the two forms trade off:

Dimension	General-purpose tools	Specialized tools
Flexibility	High: not limited by the types of tools available	Low: tasks beyond the toolset need workarounds
Runtime reliability	Depends on the commands and dependencies already installed on the user’s system	Dependencies are built in and ready to use
Token cost	Lower: few tool definitions	Higher: many tool descriptions eat into the context budget
Observability	Weaker: commands are free text and must be parsed before they can be measured	Stronger: structured fields can be loaded straight into analytics
Where security is controlled	Mainly in the guardrail policy	In each tool and in the classifier

There is also an easy-to-miss coupling. The more specialized tools there are, the more kinds of actions the classifier has to understand, which makes the reviewer-first permission layer heavier. General-purpose tools, on the other hand, reduce most actions to “run a command”. That fits naturally with sandbox-first thinking: check capabilities, not intent. Tool design and security model shape each other.

In specialized toolsets, a single edit tool usually changes only one spot, so a large change takes many calls in a row. The model can also forget earlier instructions as the context grows. These systems therefore often ship with project-level convention files and task-list mechanisms to keep behavior on track and long tasks consistent.

4. Platform Adaptation and Engineering Cost: Upfront Investment vs. Ongoing Burden

• Sandbox-first: heavy upfront, cheap at the margin. Each target operating system needs its own sandbox implementation, and behavior has to be verified as consistent across OS versions. Kernel mechanisms vary a lot between versions, and older systems may lack some isolation features, so there has to be a fallback plan. Cross-platform adaptation is the main engineering burden.
• Reviewer-first: light upfront, ongoing cost. The core permission logic doesn’t depend on the platform, but the classifier needs constant maintenance: adding rules, tracking new attack techniques, and tuning scoring thresholds. How secure the system stays depends on how much is invested in running it over time.

5. Interaction Experience: Silent Failure vs. Explainable Approval

• Sandbox-first works like building access control: if access is granted, the agent goes through; if not, it’s turned away, usually without a reason. This is efficient for expert users but unfriendly to the model. With no feedback it can understand, the model tends to retry the same action. It may even mistake a rejection for an environment problem.
• Reviewer-first works like a security checkpoint. It tells the user things like “this operation needs access to a directory outside the workspace. Allow it?” and leaves the decision to them. That takes more effort to understand, but it buys explainability and a sense of control.

This difference in experience also shows up in the defaults. Sandbox-first systems tend to make the “unrestricted” mode an explicit option that warns users about the risk. Reviewer-first systems tend to require confirmation for high-risk actions so the user steps in at critical moments.

6. Scenario Fit: There Is No Best, Only the Best Match

Scenario	Key constraint	Better fit
Personal local exploration and rapid prototyping	Frequent interaction, varied tasks	Reviewer-first: clear feedback, rich toolset
Automated pipelines and bulk refactoring	Unattended runs; results must be deterministic	Sandbox-first: kernel enforcement doesn’t depend on judgment
Team collaboration on a shared codebase	Changes must be auditable and reversible	Either works; sandbox-first is easier to audit
Production environments or sensitive data	A boundary breach has serious consequences	Sandbox-first, plus network controls and human approval
Shipping across many operating systems	A consistent experience is required	Reviewer-first: one set of logic works everywhere

7. Enterprise Adoption: From Picking a Side to Layering

In production, the safer approach is not to choose one or the other, but to layer them: capability limits form the floor, semantic review is the explanation layer, and human approval guards high-risk actions.

Agent requests to run a command
        │
        ▼
① Deterministic rules: denylisted commands and high-risk patterns
   (force push, recursive delete, system config changes, etc.) ──match──▶ Reject immediately
        │ no match
        ▼
② Kernel guardrails: file, network, privilege, and resource limits ──out of bounds──▶ Reject, and return an error the model can understand
        │ pass
        ▼
③ Semantic review: the classifier assesses risk using project conventions and current task context
        │ high risk
        ▼
④ Human approval: show the command, its impact, and how to roll back ──denied──▶ Stop and log the decision
        │ approved
        ▼
Run it, with a structured audit log recorded throughout

Recommended practices to go with this setup:

1. Least privilege by default: expose only the workspace and the network domains that are needed, and open up more only item by item as required.
2. Isolated execution environment: run the agent in a separate container or cloud VM, and keep sensitive code and credentials outside what it can see.
3. Short-lived, narrowly scoped credentials: inject temporary credentials only when needed, and limit both their permissions and how long they last.
4. Make changes reversible: take a snapshot or commit baseline before every change so any change can be diffed and rolled back.
5. Audit and monitor: collect command, file-change, and network-access logs in one place, and set alerts for abnormal frequency and abnormal paths.
6. Separate the generating model from the reviewing model: have the review step use a model and rules that are independent of the generation step, to reduce the bias that comes from an agent endorsing its own work.
7. Protect the supply chain: pin dependency versions, verify their integrity, and review install scripts and build hooks.
8. Review the output: scan the model’s responses for sensitive information so keys and tokens don’t leak.

In the cloud, these controls can be assembled from general-purpose capabilities into a complete loop. On Baidu AI Cloud, for example, a common setup is:

• Use a container service to host the isolated execution environment.
• Use object storage to hold workspace snapshots and build artifacts.
• Use a log service to collect audit records in one place.
• Use monitoring and alerting to track abnormal behavior.

8. Conclusion: Answer the Root Question First, Then Pick Tools

Sandbox-first and reviewer-first are not the difference between “safe” and “unsafe”. They are two ways of distributing risk:

• Sandbox-first concentrates risk in engineering implementation and configuration: get it right once and benefit for the long term.
• Reviewer-first concentrates risk in judgment accuracy and ongoing operations: it’s quick to get started, but needs sustained investment.

Before choosing, answer two questions:

1. Where will this agent run, and what is the worst outcome if it goes beyond its boundaries?
2. Can the team maintain security policies and permission rules over the long term?

For unattended, high-consequence scenarios, make capability limits the foundation. For interactive work with varied tasks, let semantic review improve the experience, with deterministic rules and human approval covering the baseline. Understanding the root disagreement between these two routes is more valuable in the long run than memorizing any tool’s feature list.