Skip to main content
Guardrails run as a genuinely separate service — its own repo, its own REST API (GET /catalog, POST /scan, GET /healthz) — with no scanning logic or rule catalog vendored into the registry. Structural validation confirms a package is well-formed; guardrails are a second, independent gate for content risk that runs immediately after, before any archive is written. Only Level 1 rules may set mandatory: true. The guardrails service itself force-runs every mandatory rule regardless of what a caller’s /scan request asks for — a caller can never disable one by omission or bug, because enforcement lives in the service, next to the catalog, not in the caller. The registry owns a separate, narrower thing: which configurable checks a tenant has opted into (file-backed per-tenant guardrail policy) — a tenant-administration concern tied to its own auth/RBAC model, not something the content-scanning service needs to know about.