Decision guide

Runtime Guardrails and Supply Chain Security

Fact review observed 2026-08-09Review expires 2026-09-08v1.0.0

Direct answer

Runtime guardrails and supply-chain controls can overlap at install-time boundaries while still solving different problems. Snyk documents SCA and code-scanning capabilities; GitHub dependency review evaluates dependency changes in pull requests; Socket analyzes dependency changes and Socket Firewall can intercept package-manager requests; HOL Guard publishes package-manager intent plus harness/event-specific runtime coverage. The practical choice is layered: use the controls that cover your dependency, install, and agent-action boundaries rather than assuming one category replaces another.

Install HOL Guard

The old “supply-chain tools act only before install, runtime guardrails act only after install” split is too broad. Current products can span multiple lifecycle points. Compare the exact object and decision boundary instead: dependency metadata, package-manager request, install intent, source code, harness event, tool call, or other consequential action.

Best fit

  • Teams that already use supply chain security tools
  • Security architects building a layered defense
  • Developers wanting to understand what runtime guardrails add beyond supply chain checks

Not a fit

  • Teams that only need one layer of security
  • Teams with no package dependencies

Limitations

  • This guide explains the complementary boundary, not specific product features.
  • Supply chain tool capabilities vary; check each tool’s coverage.

Current named-product sources

Observed 2026-08-09; re-review is due by 2026-09-08.

Primary sources

Questions

What is the difference between runtime guardrails and supply-chain or plugin scanning?

Runtime guardrails and supply-chain or plugin scanning can overlap at install-time boundaries while still solving different problems. Scanning reviews packages, plugins, and dependency metadata. Runtime guardrails apply policy at agent-action boundaries. HOL Guard is local-first runtime control on the developer machine for shell, secrets/file reads, MCP server change, and plugin/skill install. It is not a cloud MCP gateway. It is not a complete prompt-injection preventer. A scanner and a runtime policy boundary can be complementary rather than interchangeable.

Does a catalog scan mean the plugin supply chain is safe?

No. A scan is not a safety guarantee. The current public catalog scanner is registry-broker-fallback static scoring, not a live exploit test.

Are catalog plugin counts the same as Registry Broker agent counts?

No. About 205 catalog plugins are not Registry Broker agent counts.

Are runtime benchmark fixtures live attack measurements?

No. Runtime benchmark fixtures are modeled. They are not live attack measurements.

Related guides and research

Apply this guidance

Use these boundaries in a real environment. The click is recorded with this page, content version, and destination for outcome analysis.

Install HOL Guard

Gap decision: GAP-DEC-004 · Neutrality review: NEUTRALITY-004

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-012: runtime guardrails and software supply chain security
Next rescan
Changelog
  1. v1.0.0 — Initial publication.