Runtime Guardrails vs Native Agent Controls
Fact review observed 2026-08-09 · source review expires 2026-09-08 · content version 1.0.0
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.
Comparison facts are reviewed by HOL Guard Research. Named vendor facts expire after the current review window rather than being assumed unchanged.
Corrections are triaged within 7 calendar days. Report a correction.
Compare these approaches by action surface, decision timing, failure behavior, approval path, and documented blind spots. Native controls inherit each harness’s capabilities. HOL Guard coverage is explicitly harness- and event-specific; unsupported or partial surfaces remain visible in the coverage table rather than being described as universally protected.
| 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; fixture benchmark is not live efficacy evidence |
| Known non-coverage | Depends on each harness | Uninstrumented actions and explicitly unsupported/partial event surfaces are not claimed as protected |
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
Primary sources
Limitations
- Native control capabilities change with each harness release; verify current behavior.
- The benchmark uses fixture-based outcomes, not real-world attack measurements.
Related
Gap decision: GAP-DEC-003 · Neutrality review: NEUTRALITY-003
Fact-audit changelog: 2026-08-09 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.
- Author
- HOL Guard Team
- Technical reviewer
- HOL Guard Team
- Reviewed
- Content version
- 1.0.0
- Buyer prompt
- GAE-009: runtime guardrails and AI code security scanners
- Next rescan
Changelog
- v1.0.0 — Initial publication.