Policies vs Gates vs Guardrails in Safeguard: What Runs Where

In Safeguard, a policy is a rule that evaluates your software and records findings, a gate is a checkpoint that turns the results of its linked policies into one pass or fail decision, and a guardrail is a rule Safeguard enforces on your behalf at the point where the risk shows up, from a pull request to a live tool call made by an AI agent. Policies and gates live in the platform and decide what happens to a build or release. Guardrails run wherever the risk is: in CI, in front of MCP servers, between your app and a model provider, and inside running workloads. All of them are generally available (GA).

The words overlap in everyday speech, so teams often configure the wrong one. This post is the comparison: what each control decides, where it runs, what vocabulary of actions it uses, how exceptions work, and which one to reach for when you write a new rule. If you want the full walkthrough of turning a written standard into a CI gate, read From plain English security policy to release gates in Safeguard, which this post builds on rather than repeats.

Key takeaways

• Policies (GA) are rules over your SBOM, vulnerability, licence and attestation data. Each one runs a saved search and records Passed, Failed, Error or Not evaluated, plus the matching issues as findings.
• Gates (GA) are checkpoints with no rules of their own. A gate combines its linked policies and each policy's Action (Block, Warn or Notify) into Passed, Warning, Failed, Error or Not evaluated.
• Approval is an exception workflow, not a fourth Action. The Safeguard docs we checked on 25 October 2026 show Block, Warn and Notify as the policy Actions, and handle approval through exception requests with a justification, an expiry and an approver.
• Guardrails (GA) are the enforcement layer. The Guardrails and Enforcement docs describe policy as code with BLOCK, WARN and AUTO_FIX effects across CI, registry and runtime, with time boxed exceptions and two person breakglass.
• MCP Guardrail (GA) applies allow, deny or monitor rules to every MCP tool call, through an SDK inside the agent process or a proxy in front of the MCP server.
• AI Gateway, the LLM firewall (GA) checks prompts, responses and tool calls, with monitor mode as the default and enforce mode switched on per tenant. It fails open by default so a gateway problem never breaks your app.
• Runtime protection (GA) can respond to suspicious workload behaviour with alert, block, kill, quarantine or isolate, where everything beyond alert is policy gated and the destructive actions need human approval.
• Autonomous remediation (GA) can open fix pull requests when a gate or guardrail fires, but it ships switched off, with every category set to Manual.
• Kubernetes admission control is not available yet. The docs say the admission controller is not published.

Why three similar words cause real problems

Most security programmes already have a written standard, such as "no known exploited critical vulnerabilities in production". The trouble starts when someone tries to make it bite.

If you only write the rule as a report, nothing stops a release. If you put a blocking check in one pipeline, the release built from another pipeline sails through. If you try to govern an AI agent with a build gate, you discover the agent never goes through a build at all: it calls tools at runtime, through a protocol your CI system has never seen.

Each of those failures comes from putting a rule in the wrong place. Rules about what ships belong where software is assembled and released; rules about agent tool calls belong in the call path; rules about model output belong between the app and the model. Safeguard has a different control for each, with different action words because they act on different things.

What the standards ask for

Several public frameworks shape how these controls should work. None of them names a product, but together they explain why you need all three.

• NIST SP 800-218, the Secure Software Development Framework (SSDF). The SSDF asks organisations to define security requirements for software development, to define criteria for security checks, and to keep records showing those checks ran. In plain terms: write the rule, decide what passing looks like, and keep evidence. That maps to a policy, a gate and the gate's evaluation history.
• NIST SP 800-204D, on integrating software supply chain security into DevSecOps CI/CD pipelines. Its focus is on building security checks into the pipeline itself rather than bolting them on after release. A gate wired into CI is the direct expression of that idea.
• OWASP SAMM, Policy and Compliance practice. SAMM describes maturity as moving from a security baseline of policies and standards, to requirements that apply to every application, to measuring and reporting each application's adherence. Policies are the baseline; gates and their outcomes are the measurement.
• CISA's Known Exploited Vulnerabilities (KEV) catalog. KEV gives you an objective, public signal for "this is being exploited now". It is the most common input to a blocking policy because it is hard to argue with.
• Kubernetes admission controllers. The Kubernetes docs explain that admission control can be validating, mutating or both, and that validating controllers may not change the object they review. That is the model for deploy time guardrails, and it is why the missing Safeguard admission controller matters (more below).
• OWASP Top 10 for LLM Applications, LLM01 Prompt Injection. OWASP says plainly that it is unclear whether there are fool proof prevention methods for prompt injection, and lists mitigations instead. That is the argument for a runtime guardrail that observes and limits impact, rather than a one time scan.
• The Model Context Protocol security best practices. The MCP specification's security guidance discusses risks such as the confused deputy problem, token passthrough and session hijacking. Those are request time risks, which is why an MCP guardrail has to sit in the request path.
• NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework. It is a cross sector companion to AI RMF 1.0 for generative AI, and it frames AI risk as something you manage across the lifecycle, including after deployment. Runtime guardrails are one of the places that happens.

Together they say: define the rule once, check it wherever the risk can enter, and keep a record of every decision.

What is a policy in Safeguard?

A policy is the rule itself. The Safeguard Policies and Gates docs describe policies as rules that evaluate your SBOMs and generate findings. They define acceptable risk thresholds and required controls, and they can be advisory or blocking.

What a policy can test

The docs list example conditions:

These draw on capabilities that are themselves GA in Safeguard: software composition analysis and vulnerability management with EPSS and KEV enrichment, licence compliance, and attestation and signing.

How a policy is evaluated

Under the hood, the Policy outcomes docs say a policy runs its starred search each time Safeguard evaluates it on a gate. That happens when the policy is first linked to a gate and again after new assessment data arrives for the product. The result is one of four outcomes:

An Error is never counted as a pass, so a broken rule does not quietly let things through. New policies have no threshold, so any match fails them; older policies created with a threshold above zero keep it.

Where you write one

The docs give the path: Settings › Policies, then Create Policy, then define conditions with the visual builder or YAML, set severity and actions, and save. Safeguard also lets you create policies and generate findings from plain English prompts (GA), which works through Search: you describe the rule in a sentence, review what it matches across your real projects, and save it. The plain English to release gates walkthrough shows that flow end to end.

A policy that is not linked to a gate only records. It stops nothing until you link it.

What is a gate in Safeguard?

A gate is a checkpoint. The docs describe gates as checkpoints that enforce policies: they block deployments when policies fail, integrate with CI/CD pipelines, and require approvals for exceptions. A gate has no rules of its own. Everything it decides comes from the policies linked to it and the Action set on each of those policies.

Safeguard's offering material describes gates placed at checkpoints by stage, such as Monitor or Plan and Fix, and by function, such as App Sec or Dev. That lets the same policy behave differently for different audiences: a rule can warn developers on a pull request gate and block on the release gate.

The three Actions: Block, Warn and Notify

Each policy has exactly one Action, and it decides what a failed policy does to the gate. This is from the Policy outcomes docs as checked on 25 October 2026:

Notify fires when a policy starts failing and again when it finds new matches, not on every evaluation.

Where approval fits

Approval is not a fourth Action. It is the exception workflow that sets a Block aside for a specific case. The steps the docs give are:

1. Click Request Exception.
2. Select the policy and the finding.
3. Provide a business justification.
4. Set an expiration date.
5. Submit for approval.

Approvers are notified, review and decide, and an audit trail is recorded.

How a gate decides

The order is fixed, and it is worth memorising because it is what your pipeline sees:

1. No policies linked: Not evaluated.
2. Any Block policy failed: Failed.
3. Otherwise, any policy could not be evaluated: Error, with the reason.
4. Otherwise, any policy not yet evaluated: Not evaluated.
5. Otherwise, any Warn policy failed: Warning. The gate passes and names the policy.
6. Otherwise: Passed. Failed Notify policies are listed as notified.

A gate that has never been evaluated shows Not evaluated, never Passed. And Error ranks above Warning, so a broken policy cannot hide behind a passing gate.

You see outcomes in two places: the Outcome column on Policies › Gates and Policies › Policies, and, when you expand a gate, each linked policy's Action, outcome, effect on the gate, matches and evaluation time, plus the gate's evaluation history page by page.

Where a gate runs

This is the point that separates gates from guardrails most sharply. Gates are evaluated by the platform, on the scans Safeguard runs for your connected repositories. The Guardrails docs are explicit that the CLI has no separate gate command and that plain safeguard scan reports findings without failing a build.

What connects a gate's verdict to your pipeline is one CI step:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

Per the docs, it waits for the scan and for the gate's policies to be evaluated on the new data, then exits 0 when the gate is Passed or Warning, and non zero when the gate is Failed, Error or Not evaluated, or when evaluation does not finish before the timeout. The step needs a secret key created under Settings › Developer with the scopes scans:trigger and scans:read, stored in your CI as SAFEGUARD_API_KEY.

Two operational facts from the docs are easy to miss. Policy outcomes are turned on per workspace by Safeguard, so if you do not see an Outcome column, ask your Safeguard contact first. And SAST findings are scanned and shown in Safeguard but are not part of the CI fail conditions yet, so CI gating today covers dependency vulnerabilities and the policy data above.

What is a guardrail in Safeguard?

A guardrail is the broadest of the three. The Guardrails and Enforcement docs define it as a rule Safeguard enforces on your behalf. Unlike a scanner that only reports, a guardrail blocks, gates or auto remediates at the moment a risk appears.

In practice, "guardrail" covers four distinct mechanisms in the Safeguard docs, and they do not share configuration or vocabulary. Knowing which one you mean saves a lot of confusion.

1. Supply chain guardrails: policy as code across the lifecycle

This is the guardrail described on the Guardrails and Enforcement page. Guardrails are defined in YAML. Each has a target (what it applies to), one or more rules, and an effect. Rules evaluate against a combined document of SBOM, vulnerability, licence, signature, provenance and reachability data. The effects are BLOCK, WARN and AUTO_FIX.

Here is the first rule of the example in the docs, which blocks production images that contain KEV listed critical vulnerabilities and does not allow exceptions:

apiVersion: safeguard.sh/v1
kind: Policy
metadata:
  name: block-critical-cves-in-prod
spec:
  targets:
    - kind: Image
      labels:
        env: production
  rules:
    - id: no-known-exploited-critical
      description: Block production images containing KEV-listed CVEs.
      condition: |
        any(
          vulnerabilities,
          severity == "critical" AND kev == true
        )
      effect: BLOCK
      exception:
        allowed: false
        approvers: ["security-leads@company.com"]

Note the exception block. That is how a supply chain guardrail says "this rule can never be waived", or names who may approve a waiver.

The docs list curated guardrails you can switch on, including KEV in production, an EO 14028 SBOM requirement (a CycloneDX SBOM attestation signed in the last 90 days), a licence allow list, an abandoned package rule (zero commits in 365 days and a CVE open more than 180 days), an unsigned container rule and an AI model provenance rule that blocks loading weights without a signed model card.

AUTO_FIX is the effect that makes guardrails different from gates. With Griffin integrated, the docs describe a CI guardrail that, instead of failing the build when a dependency upgrade introduces a CVE, opens a pull request that pins the dependency to the last safe version, updates the lockfile and reruns tests. Auto fix guardrails need a pre approved scope: which repositories, which ecosystems, which severity bands. This rides on autonomous remediation (GA), which ships switched off with every category set to Manual, so nothing is auto fixed until you decide it should be.

2. MCP Guardrail: allow, deny or monitor each agent tool call

The second mechanism governs AI agents. Safeguard's offering describes MCP Guardrail (GA) as generating guardrail proxy URLs for MCP servers, so agent tool traffic is governed. The docs call the enforcement component Guard, and they say plainly that it is a different mechanism from the supply chain guardrails above: Guard policies govern live MCP tool calls at request time, with allow, deny and monitor actions.

How it works, per the Guard Policies docs:

• You author and edit Guard policies in your Safeguard workspace. There is no local policy file; whatever the SDK or proxy enforces is a live pull of what is saved.
• Exactly one policy per organisation is the default, and only the default is enforced.
• Rules are checked in priority order, highest first. The first rule that matches wins.
• If no rule matches, Guard flags the request for monitoring rather than silently allowing or blocking it. If no default policy exists yet, all traffic is flagged for monitoring.

You can enforce in two places. The Guard SDK sits inside an agent or MCP server process you control. The Guard proxy sits in front of MCP servers you do not control, such as third party servers, and you point the agent at a proxy URL instead of the server. Requests the policy blocks never reach the upstream server. The docs say the SDK and proxy enforce the same policy; only the place differs, and you can run both. For a full walkthrough, read Put a policy proxy in front of MCP servers with Safeguard MCP Guardrail.

This pairs with agent identity (GA), which tracks which agent holds what access and at what level. Identity tells you who the agent is and what it can reach; the MCP Guardrail decides what each call is allowed to do.

3. AI Gateway: guardrails on prompts and responses

The third mechanism is the AI Gateway, Safeguard's LLM firewall (GA). The docs describe it as a runtime enforcement point for the AI in your applications, sitting as an inline proxy or a thin SDK shim between your app and the model provider. It evaluates prompts, responses and tool calls.

It has its own vocabulary. The gateway runs in monitor or enforce mode, and individual checks have verdicts such as block, redact, monitor and throttle:

Monitor is the default everywhere. Enforce mode is switched on per tenant with an explicit opt in. The gateway fails open by default: on any gateway error or timeout, traffic passes and an alert is raised. The docs give a default per request evaluation budget of 150 ms; over budget, traffic passes with an alert. Fail closed is available only if a tenant opts in.

Gateway decisions are recorded as guardrail events, one per decision, rather than as standard findings, and raw prompt and response text is never stored. There is no CLI command for running the gateway yet. Our earlier post, Monitor before you block with the Safeguard AI Gateway, maps these checks to the OWASP LLM Top 10.

4. Runtime protection: gated responses inside workloads

The fourth is runtime protection (GA), which watches workloads as they run. Its response actions are the most forceful in the product, so they carry the strictest controls. Per the Runtime Protection docs:

The default is detect and alert until a tenant opts in, and destructive actions need human approval unless a specific high confidence rule is opted into automatic response. Responses are safe fail and rate capped, so a storm degrades to alert only.

Where guardrails run: the enforcement points

The Guardrails and Enforcement docs list six enforcement points. Here they are with their status as the docs describe it on 25 October 2026:

The docs also extend guardrails to procurement: TPRM (GA) can require a signed SBOM from a vendor before contract signing.

The comparison in one table

One line to remember it by: the policy is the sentence in your standard, the gate is where a release is judged against it, and a guardrail is the rule standing in the path of the risk.

Step by step: choosing the right control for a new rule

When someone hands you a new requirement, run it through these steps before you open a settings page.

1. Write the rule as one sentence. For example: "No production image may contain a KEV listed critical vulnerability." Or: "Agents may not call write tools on the billing MCP server." If you cannot write it as one sentence, it is two rules.

2. Ask what the rule is about. Is it about software you build and ship (dependencies, images, licences, provenance)? Is it about what an AI agent does with a tool? Is it about what goes into or comes out of a model? Is it about how a running workload behaves? Each answer points to a different family: policy and gate, MCP Guardrail, AI Gateway or runtime protection.

3. Find the earliest point where the risk can be stopped. A vulnerable dependency can be caught in the IDE, on the pull request, in CI and at the registry. A risky tool call can only be caught in the request path. A leaked field in a model answer can only be caught on the response path. Put the control at the earliest point the docs show as available, and add later points as backstops.

4. Express the rule in that family's form.

   • For software you ship: create a policy (Settings › Policies › Create Policy, or from plain English in Search) and check what it matches across your projects before you link it to anything.
   • For agent tool calls: add a rule to your default Guard policy in the workspace, and give it a distinct priority so its order is clear.
   • For model traffic: set the relevant gateway check, and leave the gateway in monitor mode first.
   • For workload behaviour: start from detect and alert.

5. Start in observe mode. Every family has one: Notify then Warn for gates, WARN for supply chain guardrails, monitor for MCP Guardrail and the AI Gateway, alert for runtime protection. Measure for a sprint before anything blocks.

6. Wire enforcement in. For gates, link the policy to a gate on Policies › Gates and add safeguard ci scan --wait --fail-on-gate <gate> to every pipeline that ships, before the publish or deploy step. For MCP traffic, point agents at the proxy URL or add the SDK. For model traffic, route calls through the gateway.

7. Decide the exception path before you block. Set who approves, how long an exception may last, and which rules can never be waived. For supply chain guardrails, write allowed: false on the rules you will never waive.

8. Turn on enforcement and watch the evidence. For gates, watch the Outcome column and evaluation history. For guardrails, the docs describe an Enforcement dashboard with allow, warn and block trends by policy, team and asset class. A rule that blocks thousands of times a week, the docs note, probably needs auto fix or a rewrite.

Worked example 1: one supply chain rule, three layers

The rule: no KEV listed critical vulnerability in production.

• As a policy: a policy whose condition is critical severity and KEV listed. On its own it records which projects fail today. Link it to a gate with Notify for a week to see the size of the backlog.
• As a gate: move the Action to Warn on the pull request gate, then to Block on the release gate. Add the --fail-on-gate step to the release job. Now a release that carries such a vulnerability fails its pipeline, and anyone who needs to ship anyway must request an exception with a justification and an expiry.
• As a guardrail: the docs' YAML example above expresses the same rule for production images, with allowed: false so it cannot be waived. With auto fix in scope, the CI guardrail can open the upgrade pull request instead of only failing.

The layers do not compete: the policy defines, the gate makes CI honour it, and the guardrail reaches places a pipeline never touches, such as a registry push.

Worked example 2: an agent rule

The rule: agents may read from the billing MCP server but may not call tools that change data.

A gate cannot help here, because the agent never builds anything. This is a Guard policy. You add rules to your organisation's default Guard policy in the workspace: a higher priority rule that denies the write tools on that server, and a lower priority rule that allows the read tools. Because the first matching rule wins and unmatched requests are flagged for monitoring, any new tool the server adds later shows up as monitored traffic rather than silently allowed. If you do not control the server's code, register it and route the agent through a Guard proxy URL. Pair this with agent identity so you can answer which agent tried which call.

Decision table: which control for which rule

How exceptions differ across the three

Exceptions are where governance programmes most often decay. Each family handles them differently.

Gates. A developer requests an exception against a specific policy and finding, with a business justification and an expiration date. Approvers are notified, decide, and an audit trail is recorded. The Policies and Gates docs list exception history among the compliance reports, which is what an auditor will ask for.

Supply chain guardrails. The Guardrails docs say every blocking guardrail supports time boxed exceptions: an approver with the right role grants an exception for a specific asset for a specific duration, it appears in the audit log, and it expires automatically. Emergency breakglass exceptions need two person approval and alert the security channel. The YAML exception block lets you name approvers per rule or forbid exceptions outright.

MCP Guardrail. The Guard Policies docs describe rules, priorities and a monitor fallback rather than a request and approve flow. If a specific agent needs access another agent does not, express that as a narrower, higher priority rule, and review it like any other policy change.

Runtime protection. Approval sits in front of the action rather than behind it: kill, quarantine and isolate need human approval unless you opt a specific high confidence rule into automatic response.

How the three produce evidence

For an audit, each control answers a different question.

• Policies answer "what is the requirement?" The definition, its search or YAML, its Action and its linked gates are the record.
• Gates answer "was the requirement checked on this release?" Each push becomes a project version named after its branch and commit, and the gate's evaluation history shows the decision for each one.
• Guardrails answer "what happened at the moment of risk?" The Guardrails docs say every guardrail decision produces a signed audit record, is logged to the Safeguard audit stream, and is emitted as an OpenTelemetry span for SIEM ingestion. Guard keeps audit history per call, and the AI Gateway records guardrail events with redacted metadata.

These records feed the Compliance and GRC suite (GA), which maps evidence to controls continuously across hundreds of frameworks, including NIST SSDF and EO 14028 requirements. Our post on continuous compliance in Safeguard covers how that mapping works. Remember the limit: evidence that a check ran is not evidence that it was the right check. Auditors will still ask how each rule was chosen and who reviewed it.

What Safeguard does not do

• It does not enforce where it is not wired in. A gate fails a pipeline only if that pipeline runs the --fail-on-gate step. A repository without it, a release built on a laptop, or a fork pull request that does not receive secrets is not gated. An agent that talks to an MCP server directly, not through the proxy or SDK, is not governed by MCP Guardrail.
• No Kubernetes admission control today. The docs say the admission controller is not published and warn against installing any chart that claims to be it. Deploy time enforcement in the cluster is yours to build with your platform's own admission policies.
• SAST findings do not fail CI yet. SAST (GA) runs on the platform and its findings show in Safeguard, but the CI docs say they are not part of the fail conditions yet.
• Gates do not fix code. A failed gate stops a release; it does not change the dependency. Autonomous remediation (GA) and AUTO_FIX guardrails can open fix pull requests, but remediation ships switched off with every category set to Manual.
• The AI Gateway is not a guarantee against prompt injection. OWASP itself says fool proof prevention is unclear. The gateway fails open by default, so it limits impact and records events; it does not replace least privilege for the tools and data your model can reach. There is no CLI command for it yet.
• Policy outcomes are switched on per workspace. Until Safeguard turns them on for you, there is no Outcome column and --fail-on-gate has nothing to evaluate.
• It does not write your standard. Plain English policy creation drafts a rule from a sentence, but a person accountable for the rule must review what it matches and decide thresholds, waivers and owners. Training, design review and code review still need people.

Common mistakes

• Using a gate to govern agents. Agents act at runtime through tool calls, not through builds. Use MCP Guardrail and agent identity for agents; use gates for software you ship.
• Looking for an approval Action. The Actions are Block, Warn and Notify. Approval happens through exception requests, so configure the exception process.
• Mixing up the action words. Block on a gate, BLOCK on a supply chain guardrail, deny in a Guard policy and block in the AI Gateway all stop something, but they act on different objects and are configured in different places. Write down which one you mean.
• Treating Not evaluated as a pass. A gate that never ran shows Not evaluated, and --fail-on-gate fails on it. That is deliberate. Fix the linkage rather than loosening the step.
• Relying on the Guard fallback. Unmatched MCP requests are monitored, not denied. If you want deny by default for a server, write an explicit low priority deny rule rather than assuming one exists.
• Leaving two default Guard policies. The docs warn that with more than one default policy for an organisation, which one loads is not guaranteed. Keep exactly one.
• Granting exceptions with no expiry or reviewer. Default to the shortest expiry that covers the fix plan, never let a requester approve their own exception, and review exception history monthly.

FAQ

What is the difference between a policy and a gate in Safeguard?

A policy is a rule that runs a saved search over your software data and records Passed, Failed, Error or Not evaluated plus the matching findings. A gate is a checkpoint with no rules of its own; it combines its linked policies and their Actions into one decision. Both are GA.

What is a guardrail in Safeguard?

A guardrail is a rule Safeguard enforces where the risk appears, rather than only reporting it. In the docs the word covers supply chain policy as code (BLOCK, WARN, AUTO_FIX), MCP Guardrail for agent tool calls, the AI Gateway for model traffic, and runtime protection responses. All are GA.

What actions can a Safeguard gate take?

Per the docs checked on 25 October 2026, each linked policy has one Action: Block fails the gate, Warn passes it with a warning, and Notify passes it and sends a notification. Approval is handled by the exception workflow, not as a separate Action.

How do I fail a CI build on a Safeguard gate?

Add safeguard ci scan --wait --fail-on-gate <gate> to the job, with a SAFEGUARD_API_KEY secret that has the scans:trigger and scans:read scopes. It exits non zero when the gate is Failed, Error or Not evaluated. The plain English to release gates walkthrough shows a full pipeline.

Where do Safeguard guardrails run?

The docs list the IDE, commit checks, CI, registries and runtime as available enforcement points, plus procurement through TPRM. MCP Guardrail runs in the agent process or a proxy in front of MCP servers, and the AI Gateway runs between your app and the model provider. Kubernetes admission is not available yet.

Can Safeguard block a Kubernetes deployment?

Not today. The Guardrails docs say the admission controller is not published and that there is nothing to install. Use your cluster's own admission policies for deploy time checks, and use Safeguard gates and registry guardrails earlier in the path.

How do I control which tools an AI agent can call?

Use MCP Guardrail (GA). Write allow, deny and monitor rules in your organisation's default Guard policy, and enforce them with the Guard SDK inside processes you own or a Guard proxy URL in front of MCP servers you do not. Pair it with agent identity (GA) to track which agent holds what access.

Does the Safeguard AI Gateway block prompt injection?

In enforce mode it can block direct and indirect injection and jailbreak attempts, and redact personal data in responses. Monitor mode is the default, enforce mode is switched on per tenant, and the gateway fails open by default. Treat it as one layer, not a guarantee.

Do Safeguard gates satisfy NIST SSDF on their own?

No tool satisfies a framework on its own. Gates give you a defined check and a record of every evaluation, which supports the SSDF's expectations around security criteria and records. How you chose the rules, who reviews them, and how you handle exceptions are still yours to show.

A gate or guardrail tells you a release or an artifact breaks a rule; it does not make the vulnerable dependency go away. When a Block fires on a dependency that has a fix, or on one that has no fix yet, these are the ways teams get back to green without an open ended exception.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to Safeguard. You add Safeguard from Claude's connector directory, where it is listed as a community connector, sign in with OAuth and choose which tools Claude can use. It is a small, concrete example of the principle behind MCP Guardrail: an agent gets only the tools you allow.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. It asks the CLI to fix a lodash CVE in a repository; the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It is what clearing a failed gate looks like from the developer's side.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session with the Safeguard mobile app. Work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. That is human approval sitting in front of an agent's action, the same idea runtime protection applies to its destructive responses.

Click through it at your own pace, or open it full screen.

To try it yourself, download Safeguard and read the Safeguard docs.

Quick check

Sources

• NIST CSRC: SP 800-218, Secure Software Development Framework 1.1
• NIST CSRC: SP 800-204D, software supply chain security in DevSecOps CI/CD pipelines
• OWASP SAMM: Policy and Compliance
• CISA: Known Exploited Vulnerabilities Catalog
• Kubernetes: Admission control
• OWASP GenAI: LLM01 Prompt Injection
• OWASP GenAI: Top 10 for LLM Applications
• Model Context Protocol: Security best practices
• NIST AI 600-1: AI RMF Generative AI Profile
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: Guard Policies
• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: AI Gateway (LLM Firewall)
• Safeguard docs: Runtime Protection
• Safeguard docs: CI/CD Integration
• Safeguard: Download

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.