Security Governance in Safeguard: Assets, Identities, Policies, Gates

Security governance in Safeguard is five layers that build on each other. Asset discovery finds what you build, buy and run. Identity controls say which person, service or AI agent can touch it, and at what level. Policies turn your written standards into checks that record findings, gates turn those results into pass or fail at a checkpoint, and guardrails enforce rules where the risk actually appears, including on live AI agent tool calls.

All five are available today (GA). This post is the hub for our governance series. It explains how the layers fit together, summarises each deep dive and links to it, and then gives you a practical order to roll the whole thing out, with the commands and screens Safeguard's documentation shows as of 25 October 2026.

Key takeaways

• Asset discovery (GA) catalogues seven asset classes (repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads), joins them into an asset graph, assigns owners and flags anything ungoverned.
• AI agent discovery (GA) reports the AI coding agents on your people's computers, what each one may do, and the MCP servers, skills and models they use. It is switched on per organisation and each person agrees on their own machine.
• Agent identity (GA) answers which agent holds what access, at what level, across agents working inside Safeguard, agents on laptops and agents calling your own MCP servers.
• Roles, keys and SSO (GA) set the level: built in roles from Owner to Viewer, custom roles, user API keys, service tokens and workload identities.
• Policies (GA) evaluate your SBOM, vulnerability, licence and attestation data and record findings. Policy creation from plain English prompts is part of the GA offering.
• Gates (GA) combine linked policies, each with an Action of Block, Warn or Notify, into one outcome. Approval runs through exception requests with a justification, an approver and an expiry date.
• Guardrails (GA) enforce rules at the moment risk appears, from CI to registries to runtime. MCP Guardrail (GA) allows, denies or monitors each MCP tool call, and the AI Gateway (GA) checks prompts and responses, in monitor mode by default.
• Autonomous remediation (GA) can open fix pull requests when a rule fails, but it ships switched off, with every category set to Manual.

The problem: governance that lives in a document

Most organisations already have a security policy. It says something like "no known exploited critical vulnerabilities in production", "every service has an owner" and "access is least privilege". The trouble is the distance between that document and the systems it governs.

Three things usually go wrong.

The inventory is incomplete. New repositories appear, registries fill with images nobody scanned, vendors ship software without an SBOM, and engineers install AI coding agents that connect to tools nobody reviewed. A policy cannot apply to an asset nobody knows exists.

Identity stops at humans. CI jobs hold long lived tokens, service accounts outlive their projects, and AI agents act with whatever permissions the person who connected them had. "Who did this, and was it a person or an agent" is now a real audit question.

Rules do not bite. A rule written as a report does not stop a release, a check in one pipeline does nothing for another, and a build gate cannot govern an AI agent that calls tools at runtime.

What the standards ask for

The frameworks that shape security programmes describe the same chain from inventory to enforcement.

• NIST Cybersecurity Framework 2.0 puts policy and accountability in its Govern function: GV.PO-01 asks for a policy for managing cybersecurity risk based on organisational context, and GV.RR-02 asks that roles, responsibilities and authorities are established and communicated. Under Identify, ID.AM-02 asks that inventories of software, services and systems are maintained. Under Protect, PR.AA-01 asks that identities and credentials for authorised users, services and hardware are managed. GV.SC-04 asks that suppliers are known and prioritised by criticality.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) 1.1, starts with PO.1.1 (identify and document security requirements), PO.2.1 (roles and responsibilities), PO.4.1 (define criteria for software security checks) and PO.5.1 (separate and protect each environment). PS.1.1 asks you to protect all forms of code from unauthorised access and tampering.
• NIST SP 800-207 describes zero trust as moving defences from network perimeters to users, assets and resources. Every request is judged on who is asking and what they are asking for, which is the same model a per call guardrail applies to an AI agent.
• OWASP Top 10 CI/CD Security Risks lists CICD-SEC-1, Insufficient Flow Control Mechanisms: the ability to push code or artifacts to production without extra review or approval.
• OWASP Non-Human Identities Top 10 (2025) names the identity failures that matter most for service accounts and agents, including NHI1 Improper Offboarding, NHI5 Overprivileged NHI and NHI7 Long-Lived Secrets.
• OWASP Top 10 for LLM Applications 2025 describes LLM06 Excessive Agency, with three root causes: excessive functionality, excessive permissions and excessive autonomy.
• The Model Context Protocol security best practices describe the confused deputy problem, token passthrough and scope minimisation, all of which are about limiting what an agent can reach through a tool server.
• CISA's Known Exploited Vulnerabilities catalog is the shared list most teams use for "known exploited". For US federal agencies, CISA's BOD 26-04, Prioritizing Security Updates Based on Risk, superseded and revoked BOD 22-01 in June 2026 and sets risk based remediation timelines. BOD 22-01's fixed deadlines are history now, so do not build new gates around them.

None of these frameworks names a tool. They agree on the order: know what you have, know who can act on it, write the rule, enforce it and keep evidence.

The five layers in one table

Each layer depends on the one above it. A gate on production images means nothing if half of them are missing from the inventory.

The governance series: what each post covers

Every post below was live on safeguard.sh when this hub was written.

Asset discovery: what it finds and how enforcement applies

Asset Discovery in Safeguard: What It Finds and How Enforcement Applies is the reference for the inventory layer: the seven asset classes, the three connection modes, the asset graph, ownership tagging, the UNGOVERNED status and the coverage metrics, then how policies, gates and guardrails attach to what discovery found. Start here if your question is "what will Safeguard actually see?"

Build a complete software asset inventory in a week

Build a Complete Software Asset Inventory in a Week with Safeguard turns the same capability into a five day plan: repositories on day one, images and workloads on day two, packages and supplier SBOMs on day three, AI models and coding agents on day four, then owners, shadow assets, coverage and the first gates in Warn and Notify on day five. Each day has an exit check. Use it as a project plan.

Agent identity: which AI agent holds what access

Agent Identity in Safeguard: Which AI Agent Holds What Access maps agents in three positions: agents working inside Safeguard through its MCP server, AI coding agents on people's computers, and agents calling MCP servers you run. It walks through ten steps, from connecting an assistant through the connector directory to offboarding, and ties each to the OWASP Non-Human Identities Top 10 and LLM06 Excessive Agency.

Policies vs gates vs guardrails

Policies vs Gates vs Guardrails in Safeguard: What Runs Where is the vocabulary post. It compares the action vocabulary of each control (Block, Warn and Notify for gates; BLOCK, WARN and AUTO_FIX for guardrail policy as code; allow, deny and monitor for MCP Guardrail) and gives a decision table for choosing the right control for a new rule.

Policy gates in CI

Policy Gates in CI with Safeguard: Block, Warn, Notify and Break-Glass is the pipeline walkthrough: one CLI step that fails the build on a gate, and how urgent fixes pass through approved exceptions.

Designing gate exceptions

Designing Gate Exceptions in Safeguard: Expiry, Ownership and Audit covers the part that decides whether a gate survives contact with real deadlines. It separates gate exceptions, guardrail exceptions with breakglass, risk acceptance on a project's Mitigations tab, and VEX statements, then gives a starting expiry policy, ownership rules and an audit trail design.

From plain English policy to release gates

From Plain English Security Policy to Release Gates in Safeguard shows how to write each rule as a plain English search, preview what it matches, link it to a gate and set the Action. It is the best place to start if your written standard exists and you need it enforced.

Five checkpoints for vulnerable dependencies

Stop Vulnerable Dependencies Reaching Production at Five Checkpoints follows one vulnerable dependency through the stages where Safeguard can catch it.

MCP Guardrail: a policy proxy for agent tool calls

Policy Proxy for MCP Servers: Safeguard MCP Guardrail covers the runtime side of agent governance: registering an MCP server, binding a proxy URL to an agent and a policy, writing allow, deny and monitor rules, and reading the audit trail.

AI Gateway: monitor before you block

Monitor Before You Block: Safeguard AI Gateway and OWASP LLM Top 10 covers guardrails on prompts and responses: monitor mode as the default, enforce mode switched on per tenant, fail open behaviour, and how the checks map to OWASP's LLM risks.

Human approval for agent actions

Human Approval for Agent Actions in Safeguard Desktop and Mobile Apps covers allowing or denying the risky steps Safeguard's own agent takes, from the desktop or phone app.

Also useful: Find Every AI Model and SDK You Ship with Safeguard AI-BOM and Safeguard in Your IDE, Claude's Connector Directory and ChatGPT.

Layer 1: assets

Safeguard's asset discovery docs open with a line every governance programme can agree with: you cannot secure what you cannot see. The capability catalogues what your organisation builds, buys or consumes and binds each item to an owner, a business context and a risk profile.

What it discovers

The docs list seven asset classes:

Discovery runs three ways: agentless integrations through OAuth or IAM roles, lightweight collectors on Kubernetes clusters, Linux hosts and CI runners (which, per the docs, do not ship source code or binaries off the host), and SBOM ingestion through Portal upload.

The asset graph, owners and shadow assets

Every discovered asset becomes a node in a typed graph (a repository builds an image, an image runs in a workload, a vendor provides an SBOM), and the Search page answers graph questions in plain language.

Each asset gets four fields: Owner (inferred from CODEOWNERS or container labels, or set by hand), Business unit, Environment and Sensitivity. These are the fields that route everything later. A finding in a production workload marked as regulated pages different people than one in a developer sandbox.

Safeguard also looks for assets that exist but are not governed: a repository in your organisation that is not connected, an image with no SBOM, a running image that appears in no SBOM, or a vendor called from production but missing from TPRM. These show up on the Asset Discovery dashboard with an UNGOVERNED status.

The dashboard reports SBOM coverage, vendor coverage and ownership coverage as time series, the simplest way to show an auditor that the inventory is improving.

AI coding agents on people's computers

AI agent discovery runs inside the Safeguard CLI and the Safeguard Desktop app. It reports, per device and per person, which supported AI coding agents are installed and what each may do (shell commands, file edits, network access, auto approved tools, permission mode), which MCP servers each one connects to, which skills and plugins are installed, which local models exist, and session activity drawn from the agents' own local files.

The privacy design matters for a rollout. Per the docs, credential values are never read (credentials appear by name and kind only), prompts and responses are not collected by default, and everything is redacted on the computer before it is queued.

It is switched on in three steps: Safeguard enables it for your organisation, an administrator turns it on and sets the policy, and each person allows it on their own computer. The results appear under Assets › Inventory › Asset discovery, with tabs for Agents, Models, Skills & plugins, MCP servers and Devices.

Layer 2: identities

Governance needs to know who acted. Safeguard answers that at three levels: people, credentials and agents.

People and roles

The RBAC docs describe a hierarchy of Organization, Team, Project and Asset. Built in roles are:

Custom roles are built from a permissions matrix and can be restricted, for example to production environments only. SSO supports SAML 2.0, OpenID Connect and SCIM 2.0 provisioning, and enterprise tenants can require re-authentication for sensitive actions such as policy changes and approving exceptions.

The separation matters: the people who write policy are not the people who request exceptions, and auditors read everything without changing anything.

Credentials

User API keys are bound to a user, inherit that user's role and are revoked when the user is deprovisioned. Service tokens belong to a service identity for CI and automation, and workload identities are OIDC federated tokens, so no long lived secret needs to exist. Organization secret keys belong to the organization rather than a person; they authenticate CI scans and the Guard SDK, and revoking one is an immediate, organisation wide cutoff.

This is where OWASP's NHI1 (improper offboarding) and NHI7 (long lived secrets) land in practice: a key tied to a person leaves with the person, and an organisation key needs its own review schedule.

Agents inside Safeguard

When Claude, ChatGPT or another assistant connects to Safeguard's MCP server with OAuth, the agent acts as the signed in user, inside that user's tenant, with that user's role. Tool availability is governed per tenant with a feature flag for each MCP tool. A new workspace starts with a small default set of read only tools; everything that creates, changes or deletes something ships disabled until an administrator enables it.

The same flag set decides which tools an assistant can see and which it can call, so it can never call a tool it cannot see. If tool resolution fails, the server falls back to the small default set: in the docs' words, an outage can never broaden what your assistant can do. A call to a tool your tenant has not enabled returns this result, as the tool gating docs show it:

{
  "content": [
    {
      "type": "text",
      "text": "Tool \"safeguard_scan_manifest\" is not enabled for this tenant. An administrator can enable it via MCP tool feature flags."
    }
  ],
  "isError": true
}

Agents calling your own MCP servers

Tool gating applies to Safeguard's own tools. For MCP servers you run, Guard does the same job per agent. A proxy URL binds one registered MCP server to an optional agent and an optional policy, so calls through it are attributed to that agent for policy targeting, risk scoring and audit. A Guard rule can match on an exact agent ID, which is how "this agent may call these tools and no others" becomes enforceable rather than a line in a spreadsheet.

That is what agent identity (GA) means in practice: you can say which agent holds what access, at what level, and back it with the configuration that grants it and the audit events that show it being used.

Layer 3: policies

A policy in Safeguard is a rule that evaluates your SBOMs and related data and generates findings. The Policies & Gates docs list the kinds of condition a policy can express:

Templates cover common starting points, such as No Critical Vulnerabilities, License Compliance, EO 14028 Compliance and No Abandoned Packages. The docs describe creating a policy with a visual builder or YAML; Safeguard's offering also includes policy creation from plain English prompts. The plain English route is covered step by step in the plain English to release gates post.

How a policy is evaluated

Each policy runs its starred search when it is linked to a gate and again whenever new assessment data arrives for the product. The outcome is one of four values:

• Failed: the search found matching issues.
• Passed: the search ran to the end and found nothing.
• Error: the policy could not be evaluated, with the reason shown. An Error is never counted as a pass.
• Not evaluated: the policy has not run on this gate yet.

New policies have no threshold, so any match fails them, which is the right default for governance rules.

One practical note from the docs: policy outcomes are switched on per workspace by Safeguard. If your Gates and Policies tables do not show an Outcome column yet, ask your Safeguard contact to turn it on.

Layer 4: gates

A gate is a checkpoint with no rules of its own. It collects the outcomes of its linked policies and turns them into one decision. Each policy carries exactly one Action, and the docs we fetched on 25 October 2026 show three:

Notify does not repeat itself on every evaluation. You hear about a policy when it goes from passing to failing, and again when it finds new matches.

How the gate decides

The docs give the order exactly:

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 evaluated yet: 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, which closes the hole where a new pipeline reports green because nothing has checked it.

Where approval fits

Approval is not a fourth Action in the public docs; it runs through exceptions. A developer clicks Request Exception, selects the policy and finding, gives a business justification and an expiry date, and submits it. Approvers are notified and decide, and the decision is recorded in the audit trail. For guardrails, the docs add time boxed exceptions that expire automatically and emergency breakglass that needs two person approval.

Failing CI on a gate

Gates are evaluated by the platform on the scans it runs for your connected repositories. To make a pipeline respect a gate, the CI/CD docs show one step that runs safeguard ci scan with --wait and --fail-on-gate <gate>. With policy outcomes on, the command waits for the scan and for the gate's policies to be evaluated on the new data. It exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated, or when its policies were not evaluated before the timeout. There is no plugin, Action or Pipe to install; every CI system runs the CLI in a plain shell step.

Layer 5: guardrails

The Guardrails & Enforcement docs define a guardrail as a rule Safeguard enforces on your behalf: unlike a scanner that only reports, a guardrail blocks, gates or remediates at the moment a risk appears.

Enforcement points

The docs describe six points:

Policy as code

Guardrails are defined in YAML, with a target, rules and an effect of BLOCK, WARN or AUTO_FIX. Rules evaluate a document that combines SBOM, vulnerability, licence, signature, provenance and reachability data. Here is an excerpt of the docs' example (the first two of its three rules; we have not run it):

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"]
    - id: requires-sbom-attestation
      condition: attestations.sbom == null
      effect: BLOCK

The exception: allowed: false line marks a rule nobody may waive.

Built in guardrails you can enable include KEV in production, an EO 14028 SBOM requirement, a licence allow list, an abandoned package rule, an unsigned container rule and an AI model provenance rule. Auto fix guardrails can open a pull request instead of failing a build, within a pre approved scope of repositories, ecosystems and severity bands. That depends on autonomous remediation, which ships switched off with every category set to Manual.

MCP Guardrail: rules on agent tool calls

MCP Guardrail (GA), delivered by Guard, governs live MCP traffic. Guard runs either as an SDK inside an MCP server or agent process you control, or as a proxy in front of MCP servers you do not. Both enforce the same policy, authored in your Safeguard workspace rather than in files.

A Guard rule can match on the JSON-RPC method, the tool name (with glob wildcards) and the agent ID. The first matching rule by priority wins and resolves to allow, deny (with a reason returned to the caller) or monitor (let it through and flag it). If nothing matches, Guard monitors. Rules can also carry input filters, such as a check for known prompt injection phrasing, and output filters that mask common PII patterns or cap returned rows. Every decision is written to an append only audit trail.

AI Gateway: rules on prompts and responses

The AI Gateway (GA) sits between your application and the model provider. It checks prompts for direct and indirect prompt injection and jailbreak patterns, checks responses for PII leaving in model output, and can enforce an output schema. Monitor mode is the default everywhere: every interaction is evaluated and recorded while traffic passes unchanged. Enforce mode is switched on per tenant with explicit opt in. The gateway fails open by default, so a gateway error or timeout lets traffic through with an alert rather than breaking your application.

Evidence that enforcement happened

The docs say every guardrail decision is logged to the Safeguard audit stream, emitted as an OpenTelemetry span for your SIEM and counted on an Enforcement dashboard by policy, team and asset class. The webhook event catalog includes policy.violation (a BLOCK or WARN fired), policy.exception_granted, policy.exception_expired, asset.discovered and asset.ungoverned, which is enough to wire governance events into your ticketing and chat tools from the Webhooks page.

Step by step: rolling out governance in Safeguard

The order below follows the layers. Each step names the screen or command the docs show; where the docs show no command, we describe the outcome.

1. Write down your rules first, in plain words. List the five to ten rules that matter most, such as "no KEV listed critical vulnerabilities in production images", "every production workload has an owner" and "no agent may call a write tool on the billing MCP server". Mark which ones may never be waived. This is SSDF PO.1.1 and PO.4.1 in practice.

2. Connect your sources. Under Integrations, connect your Git provider, container registries, cloud accounts and model registries. Upload supplier SBOMs through Portal. Discovery starts enumerating as soon as a source is connected.

3. Fix ownership before you enforce anything. Open the Asset Discovery dashboard, review the UNGOVERNED assets and the ownership coverage metric, and assign owners, environments and sensitivity. Gates routed to nobody are noise.

4. Turn on AI agent discovery. Ask your Safeguard contact to enable it, set the organisation policy as an administrator, then ask people to allow it. From the CLI, the docs show:

   safeguard aidr collect status    # your organisation's setting, your choice, the last delivery
   safeguard aidr collect show      # print exactly what the next run would send (nothing is sent)
   safeguard aidr collect on        # read the notice and allow it
   

5. Set roles and keys. Assign Security Lead, Security Engineer, Developer and Auditor roles. Move CI to service tokens or workload identities, and give each CI integration its own organisation secret key with only the scopes it needs. For CI scans the docs ask for scans:trigger and scans:read, and the key can be locked to one project.

6. Connect assistants through the connector directory. In Claude, open the Safeguard entry in Claude's connector directory, select Safeguard and connect, then sign in to Safeguard, check the app name and the host the authorisation code will be sent to, and click Authorize access. The assistant now acts as that user with only the tools your tenant has enabled.

7. Create policies for your rules. In the Policies area, create a policy per rule with the builder, YAML or a plain English prompt, preview the matches, and leave each new policy on Warn or Notify to start.

8. Link policies to gates and watch outcomes. Link the policies to a release gate and expand the gate to see each policy's Action, outcome, matches and evaluation history. Fix the policies that return Error before anything else.

9. Make CI respect the gate. Add the CI step from your CI system's guide with safeguard ci scan --wait --fail-on-gate <gate> and store the key as SAFEGUARD_API_KEY. Pin the CLI version on the install line so a release does not change a build under you.

10. Move the rules you trust to Block, and publish the exception process. After a few weeks of Warn data, promote the policies with clean, explainable matches. Agree who may approve, the default expiry, and which rules are never waivable, and route policy.exception_granted and policy.exception_expired events to the security channel.

11. Put a guardrail in front of agent tool traffic. Register the MCP servers you run with Guard, bind a proxy URL to each agent and a policy, start with monitor rules, then deny the write tools. Start the AI Gateway in monitor mode and review its events before asking for enforce mode.

12. Review quarterly. Track the coverage metrics, active exceptions, and Guard's deny and monitor trends. A policy that blocks thousands of times a week needs auto fix or a better rule, as the docs themselves point out.

What the outcomes look like

On the Gates and Policies tables, the Outcome column shows Passed, Failed, Warning, Not evaluated or Error with the time of the last evaluation. In CI, a failed gate makes the scan step exit non-zero and print the Block policies that failed, while a Warning exits 0 and prints the warnings, so the build log records that a rule fired. For agent traffic, each Guard audit event records the agent, server, tool, action, matching rule and deny reason, risk scores and any redacted PII fields: the record you hand an auditor who asks what an agent did and why it was stopped.

Decision table: which control for which job

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

• It does not enforce at Kubernetes admission today. The guardrail docs say the admission controller is not published and warn against installing any chart that claims to be it. Use CI gates and registry checks until it ships.
• It does not fail your build from safeguard scan. The local scan reports findings without failing the build, and the CLI has no separate gate command. Fail CI with safeguard ci scan --wait --fail-on-gate, or gate on the files safeguard scan writes.
• It does not have a CLI command for listing assets or querying the asset graph. Use the Asset Discovery dashboard and the Search page.
• It does not discover every AI agent. AI agent discovery covers the supported agents listed in the docs, and activity for several of them is not supported yet. Agents not on the list are not detected.
• It does not set per user tool permissions for Safeguard's own MCP tools. Tool gating resolves per tenant. Per agent control is what Guard is for, on MCP servers you run.
• It does not replace your identity provider or your Git and cloud permissions. Safeguard governs access to Safeguard, to MCP traffic through Guard and to releases through gates. Who can push to main or deploy to production is still set in your own systems.
• It does not offer the /v1 REST API shown on some docs pages yet. Those pages carry a banner saying the endpoints are not available. Use the app, the CLI and CI instead.

Common mistakes

Enforcing before inventorying. Teams switch a policy to Block on day one and discover half their production images were never connected. Fix ownership and coverage first.

Starting every rule on Block. The first week of matches always includes rules written too broadly. Start on Warn or Notify, read the matches, then promote.

Treating "Not evaluated" as green. Safeguard deliberately shows Not evaluated, never Passed, for a gate nothing has checked. Configure CI to fail on it, which --fail-on-gate already does.

Approving exceptions with no expiry. An exception without an expiry date is a permanent policy change nobody reviewed. Set a default and make renewal a new decision.

Giving automation a person's key. A CI job running on an engineer's API key breaks when that engineer leaves, and acts with their full role meanwhile. Use service tokens, workload identities or a scoped organisation key.

Enabling every MCP tool at once. The default read only set exists for a reason. Enable write tools for the workspaces that need them, one at a time.

Leaving Guard without a default policy. Without a default policy, Guard monitors all traffic rather than enforcing anything. Create one and mark it default, and keep exactly one default per organisation.

Expecting the AI Gateway to block on day one. Monitor is the default. Enforce mode is opted into per tenant, after you have reviewed what it would have blocked.

FAQ

What is security governance in Safeguard?

It is the set of controls that go from knowing what you have to enforcing rules on it: asset discovery, identity and access (people, keys and AI agents), policies, gates and guardrails. All of them are available today (GA), and each produces audit records.

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

A policy evaluates your data and records findings. A gate combines the outcomes of its linked policies into one decision at a checkpoint. A guardrail enforces a rule where the risk appears, such as in CI, at a registry, at runtime or on an AI agent's tool call.

What actions can a Safeguard gate take?

The docs show three policy Actions: Block fails the gate, Warn passes it with a warning, and Notify passes it and sends a notification. Approval is handled through exception requests with a justification, an approver and an expiry date.

How do I fail a CI build when a Safeguard gate fails?

Run safeguard ci scan --wait --fail-on-gate <gate> in a shell step with a secret key stored as SAFEGUARD_API_KEY. It exits non-zero when the gate is Failed, Error or Not evaluated, and 0 when it is Passed or Warning.

Can Safeguard tell me which AI agents my developers use?

Yes, for the supported agents. AI agent discovery runs in the Safeguard CLI and Desktop app, reports each agent's permissions, MCP servers, skills and models, and never reads credential values. It is switched on per organisation and each person agrees on their own computer.

How does Safeguard control what Claude or ChatGPT can do in my tenant?

The assistant acts as the signed in user with that user's role, and each MCP tool has a per tenant feature flag. New workspaces start with a small read only set, and an administrator enables anything else.

How do I stop an AI agent from calling a dangerous tool on my own MCP server?

Put Guard in front of the server as a proxy, or embed the Guard SDK, and write a deny rule that matches the tool name and, if needed, the agent ID. Start with monitor rules to see the traffic before you deny anything.

Does Safeguard block Kubernetes deployments?

Not today. The docs say the admission controller is not published yet. Gate releases in CI and enforce registry checks instead.

Get started

Download the Safeguard apps and CLI at safeguard.sh/download, and read the full governance documentation at docs.safeguard.sh/docs.

Governance tells you where a vulnerable component is and stops it from shipping. The next question is how fast you can actually fix it, which is what the section below covers.

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 connects Claude to Safeguard's MCP server with OAuth and shows choosing which tools Claude can use. That is the identity layer in practice: an assistant that acts as a named user, with 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. The assistant reads a finding and its advisory, asks before any command that changes something, edits the dependency, runs the install and tests with approval, and pushes nothing. It shows the human approval step that keeps an agent inside the guardrails you set, and it ends with /permissions, /model and /scan ..

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

The third demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. The runner is also where AI agent discovery runs in the background once a person allows it.

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

Quick check

Sources

• Safeguard docs: Policies & Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Guardrails & Enforcement
• Safeguard docs: Asset Discovery
• Safeguard docs: AI agent discovery
• Safeguard docs: Agents & LLMs
• Safeguard docs: Tool availability & gating
• Safeguard docs: Claude
• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: Guard Policies
• Safeguard docs: Audit Trail & Alerts
• Safeguard docs: RBAC, Teams & Organizations
• Safeguard docs: Webhooks & Events
• Safeguard docs: AI Gateway (LLM Firewall)
• Safeguard docs: Mitigations
• Safeguard docs: CI/CD Integration
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-218 full text (PDF)
• NIST SP 800-207, Zero Trust Architecture
• OWASP Top 10 CI/CD Security Risks: CICD-SEC-1
• OWASP Non-Human Identities Top 10 (2025)
• OWASP LLM06:2025 Excessive Agency
• Model Context Protocol: Security Best Practices
• CISA Known Exploited Vulnerabilities Catalog
• CISA cybersecurity directives (BOD 26-04)

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