AI Coding Agent Security Architecture: Hard Isolation vs. LLM-Based Soft Review
This article examines two fundamentally different security paradigms for AI coding agents: kernel-level hard isolation, which enforces resource boundaries through operating system sandboxing, and LLM-based soft review, which uses classifier models to evaluate agent intent. We compare both approaches across six dimensions—trust model, permission granularity, bypass resistance, cross-platform support, user experience, and engineering trade-offs—and discuss how a layered defense strategy can balance safety with flexibility for enterprise deployments.
Introduction: A Fundamental Choice That Shapes Everything
When architects design the security layer for an AI coding agent, the first question is rarely “which model to use” or “how to write prompts.” It is far more foundational: how do we constrain the agent’s behavior boundaries?
Two distinct technical approaches have emerged in industry practice. One relies on operating system kernel–enforced mandatory access control to fundamentally limit which resources the agent can reach—a “hard isolation trust model.” The other leverages the large language model’s own reasoning ability to evaluate the agent’s intent, layered with multi-tier permission policies and interactive approvals—a “soft review trust model.”
This is not a checklist of seven or eight independent decisions. It is a philosophical commitment whose consequences ripple through permission design, cross-platform strategy, user interaction, and attack resilience. This article systematically compares the two paradigms across six core dimensions and explores where each fits in enterprise scenarios.
1. Trust Philosophy: Hard Constraints vs. Soft Review
1.1 Kernel-Level Hard Isolation
The core assumption: never fully trust the AI’s judgment; enforce behavior through immutable low-level mechanisms. Concretely, this approach uses OS kernel sandboxing—Landlock + seccomp + bubblewrap on Linux, the Seatbelt mechanism on macOS, and Restricted Tokens on Windows—to draw hard resource-access boundaries at the process level.
The strength is determinism. No matter what instructions the agent produces, any action that crosses a kernel-defined line is blocked unconditionally. Because it does not depend on “understanding” intent, it can stop novel attack techniques as long as they involve unauthorized resource access.
1.2 LLM Classifier Soft Review
The core assumption: the LLM’s own comprehension can judge whether an agent’s action is reasonable. In practice, an independent classifier model scores the agent’s intent before execution, combined with path-level allowlists/denylists and user-facing approval prompts.
The strength is flexibility. It can recognize context-dependent risks—for example, that “delete file” may be perfectly legitimate in one scenario and dangerous in another—reducing false positives. The weakness is equally clear: if the classifier has never seen a certain attack pattern, it may let it through.
2. Six-Dimension Deep Comparison
2.1 Security Model and Core Mechanism
| Dimension | Kernel-Level Hard Isolation | LLM Classifier Soft Review |
|---|---|---|
| Core Mechanism | OS kernel sandbox | Independent LLM classifier + multi-tier permissions |
| Trust Assumption | Zero-trust; assume the agent may overreach | Partial trust; rely on AI-on-AI review |
| Typical Stack | Landlock / seccomp / bubblewrap / Seatbelt / Restricted Tokens | Classification scoring + path rules + interactive approval |
The hard isolation model’s security rests on the OS’s mandatory access control (MAC). Even if every user-space logic layer is bypassed, kernel-level restrictions hold. The classifier model’s security rests on inference accuracy—a single reasoning failure can break the entire chain.
2.2 Permission Granularity and Access Patterns
Hard isolation typically exposes three explicit modes:
- Read-only — the agent can read files but make no modifications; suited for code review, documentation generation, and similar tasks.
- Workspace-write — the agent can write only within a predefined working directory; all other paths are unreachable.
- Danger-full-access — all restrictions lifted, usually requiring explicit user confirmation and risk acknowledgment.
Soft review relies on path-level allowlists and denylists, with the classifier scoring each operation’s intent in real time. For instance, when the agent attempts to access /etc/, the classifier evaluates whether this qualifies as a legitimate system-configuration action and decides accordingly.
From an engineering standpoint, hard isolation yields cleaner, more auditable boundaries. Soft review handles ambiguous situations more gracefully but makes it harder to establish a unified audit standard.
2.3 Bypass Resistance and Novel Attacks
This is where the two models diverge most sharply.
Hard isolation has very high bypass resistance. Interception happens at the kernel level and is deterministic—it does not need to “understand” the attack, only to detect an out-of-bounds action. Even if attackers devise techniques the classifier has never seen, any attempt to touch restricted resources is blocked by the kernel. That said, the model is not invulnerable: if an attacker exploits a sandbox-escape vulnerability, restrictions can be circumvented. But exploiting such kernel flaws is far harder than fooling a classifier.
Soft review has comparatively lower bypass resistance. Its security depends heavily on the classifier’s generalization. Carefully crafted adversarial inputs can produce incorrect safety scores, allowing dangerous operations. Recent research on prompt injection and adversarial samples against LLMs confirms that these models have significant blind spots against unknown attack patterns.
2.4 Cross-Platform Compatibility
Cross-platform support is the biggest engineering hurdle for hard isolation. Sandbox mechanisms differ substantially across operating systems:
- Linux — requires combining Landlock (path restrictions), seccomp (syscall filtering), and bubblewrap (lightweight containers).
- macOS — depends on the Seatbelt mechanism with a completely different policy configuration model.
- Windows — uses Restricted Tokens, needing a separate implementation.
The same agent codebase thus demands different security-layer implementations per platform, raising development and maintenance costs.
Soft review has a natural cross-platform advantage. Classifiers and permission rules run in user space, so a single code logic works across platforms, requiring only minor adaptations for file-system path differences.
2.5 User Experience
Hard isolation tends toward a “cold” experience. When the kernel blocks an operation, the agent usually receives a silent failure, and the user may see only a generic “operation failed” message without detailed explanation. Secure, yes—but potentially confusing during debugging and collaboration.
Soft review favors interactive dialogs. When the classifier assigns a low safety score, the system presents a dialog explaining the reason (e.g., “This operation modifies a system directory and may affect stability. Continue?”) and lets the user approve or cancel. This is more user-friendly but introduces “approval fatigue”—if prompts appear too often, users may habitually click “Allow.”
2.6 Engineering Recommendations
In practice, the two models are not mutually exclusive. A widely adopted best practice is layered defense:
- Bottom layer — a kernel sandbox that sets non-negotiable hard boundaries (e.g., no access to credential files, no outbound network calls).
- Middle layer — an LLM classifier inside the sandbox that performs semantic review of in-sandbox actions.
- Top layer — user-facing approval for high-risk operations, forming a final human-decision gate.
This “hard isolation + soft review + human approval” three-tier architecture strikes a practical balance between security and flexibility.
3. Enterprise Selection Considerations
For enterprise teams, the decision should go beyond technical specs:
- Compliance — heavily regulated sectors such as finance and healthcare often require deterministic, auditable security mechanisms; hard isolation more readily satisfies these needs.
- Development velocity — startups or fast-iteration teams may favor soft review for its cross-platform convenience and flexible permissions.
- Attack surface — if the agent must access a wide and dynamic set of resources (multi-service calls, dynamically generated paths), pure hard isolation may be too rigid; soft review can supplement it.
- Cloud-native integration — when deploying on cloud platforms such as Baidu AI Cloud, container-platform isolation and object-storage permission controls can further reinforce the bottom-layer security boundary.
4. Conclusion
Designing security architecture for AI coding agents is not a simple “pick A or B” decision—it is a fundamental choice about trust. Kernel-level hard isolation delivers a deterministic safety floor at the cost of flexibility and cross-platform ease. LLM-based soft review brings semantic understanding but introduces dependency on model robustness.
Understanding the logical chain behind each paradigm—from trust assumptions to mechanism design, from permission granularity to user experience—is the prerequisite for sound architectural decisions. As OS security mechanisms evolve and LLM robustness improves, the two approaches are likely to converge further, enabling more trustworthy and efficient intelligent programming infrastructure.
