Comparison guide
Runtime Guardrails vs Native Agent Controls
Fact review observed 2026-09-13Review expires 2026-10-13v1.1.0
Direct answer
Native agent controls and external runtime guardrails both constrain agent actions, but coverage depends on the specific harness and event surface. HOL Guard publishes stable and alpha support contracts instead of claiming identical interception across every harness. Native controls can be simpler because they are built into a harness; an external guardrail can add a separate policy boundary on the surfaces it can observe. The published HOL benchmark is fixture-based and must not be read as live attack-resistance evidence.
On this page
Who this guidance is for
Best fit
- Teams using multiple AI coding agent harnesses
- Security teams needing consistent controls across tools
- Developers evaluating whether to rely on native controls or add guardrails
Not a fit
- Teams using a single harness with sufficient native controls
- Teams with no AI tooling
| Criterion | Native controls | HOL Guard runtime policy |
|---|---|---|
| Decision boundary | Inside the harness on events the harness exposes | External policy boundary on Guard-supported harness/event surfaces |
| Coverage scope | Varies by harness and version | Explicit stable/alpha support contract; supported, partial, and blind spots are published |
| Approval path | Harness-specific permission/approval UI where provided | Native approval when supported; otherwise documented local/browser fallback by harness |
| Failure behavior | Harness-specific; verify current product documentation | Published per harness/surface; some adapters are fail-open and others are surface-specific |
| Cross-harness operation | No single native contract across different harness products | One Guard policy model, but actual interception remains harness/event-specific |
| Separate installation | Usually part of the harness | Yes |
| Evidence standard | Current primary harness documentation and direct tests where available | Commit-pinned support manifest plus versioned evidence. Guard Gauntlet is the live method; the July 2026 fixture benchmark is not a scored run. |
| Known non-coverage | Depends on each harness | Uninstrumented actions and explicitly unsupported/partial event surfaces are not claimed as protected |
Limitations
- Native control capabilities change with each harness release; verify current behavior.
- The benchmark uses fixture-based outcomes, not real-world attack measurements.
Current named-product sources
Observed 2026-09-13; re-review is due by 2026-10-13.
- Anthropic: Claude Code security documentation
- Claude Code documents permission-based controls for edits and commands plus sandboxed Bash with filesystem and network isolation.
- Cursor: Cursor Agent security documentation
- Cursor documents manual approval defaults for sensitive actions and terminal commands, with configurable run modes for trusted calls.
- OpenAI: OpenAI Codex security controls
- OpenAI documents Codex sandbox boundaries for writes and network access plus approval policies for actions outside the sandbox.
Primary sources
Questions
Are runtime guardrails a replacement for native agent controls?
No. They constrain agent actions at different levels and are complementary, not interchangeable. Native controls are built into each harness and vary by implementation. HOL Guard sits at a separate local policy boundary on the harness/event surfaces it supports. Neither approach is universally superior.
Does HOL Guard replace Cursor, Claude Code, or Codex native approvals?
No. Cursor native approvals remain Cursor-owned. Other harness permission UIs remain those products' controls. HOL Guard can require approval at supported local action boundaries (shell, secrets/file reads, MCP server change, plugin/skill install). Coverage is explicitly harness- and event-specific. Unsupported or partial surfaces are not claimed as protected.
Does the HOL Guard benchmark prove native defaults are unsafe in the wild?
No. Runtime benchmark fixtures are modeled. They are not live attack measurements and must not be read as live attack-resistance evidence.
Does a catalog or plugin scan mean native controls are enough?
No. A scan is not a safety guarantee and cannot intercept runtime actions. The current public catalog scanner is registry-broker-fallback static scoring, not a live exploit test. Catalog plugin counts are not Registry Broker agent counts.
Apply this guidance
Use these boundaries in a real environment. The click is recorded with this page, content version, and destination for outcome analysis.
Gap decision: GAP-DEC-003 · Neutrality review: NEUTRALITY-003
Fact-audit changelog: 2026-09-13 reviewed named-product and product-coverage wording against current primary sources and the Guard support contract.
Gap prioritization may originate from fixture-derived analysis; it is not represented as a live search-engine observation.
About this page
- Author
- HOL Guard Team
- Technical reviewer
- HOL Guard Team
- Reviewed
- Content version
- 1.1.0
- Buyer prompt
- GAE-009: runtime guardrails and AI code security scanners
- Next rescan
Changelog
- v1.0.0 — Initial publication.
- v1.1.0 — Revalidated native agent controls and Guard coverage claims against current primary sources and the Guard support contract.