Asset Discovery in Safeguard: What It Finds and How Enforcement Applies

Safeguard asset discovery (GA) continuously catalogs seven classes of software asset: source repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads. It joins them into one asset graph with an owner, environment and sensitivity on each, and flags anything that exists but is not governed. Enforcement then applies to those discovered assets through policies and gates (GA): each policy carries an Action of Block, Warn or Notify, a gate fails when a Block policy fails, and approval is handled through a time boxed exception workflow rather than a separate gate action.

Discovery tells you what you own and who owns it; policies and gates decide what may ship. This post walks through both as Safeguard's docs describe them on 25 October 2026, including what is not there yet.

Key takeaways

• Asset discovery (GA) covers repositories, container images, packages, AI models in model registries, SBOMs, vendors and runtime workloads, through agentless integrations, lightweight collectors and SBOM ingestion.
• AI agent discovery (GA) adds the AI coding agents on your people's computers, what each may do, and the skills, MCP servers and models they use. It is switched on per organisation and needs each person's consent.
• Agent identity (GA) tracks which agent holds what access, at what level.
• Policies, gates and guardrails (GA) are how enforcement reaches discovered assets. The policy Actions the docs show today are Block, Warn and Notify. Approval is an exception workflow with an approver, a justification and an expiry date.
• Shadow assets (a repository that is not connected, an image with no SBOM, a running image that is in no SBOM, a vendor API called from production but missing from TPRM) surface as UNGOVERNED and can drive automation such as a ticket or a deployment block until the asset is onboarded.
• CI enforcement runs through one step, safeguard ci scan --wait --fail-on-gate, once policy outcomes are on for your workspace.
• Limits: there is no CLI command for listing assets yet, the asset discovery REST endpoints are marked as not yet available, and the Kubernetes admission controller is not published.

The problem: an inventory nobody enforces against

Most organisations have some inventory: a CMDB, a spreadsheet, a list of repositories, a registry full of images. The trouble is that the list is stale, partial and disconnected from the controls that should act on it.

Three things tend to go wrong.

The inventory drifts. A new repository is never connected to scanning. An image lands in a registry with no SBOM. A production service starts calling a third party API procurement never reviewed. Each is an asset that exists but is not governed, and a quarterly review misses most of them.

Ownership is missing. A finding on an asset with no owner goes nowhere. Without an owner, environment and sensitivity on each asset, you cannot route findings or tell a production payments workload from a sandbox.

Inventory and enforcement live apart. The inventory knows the image exists, the scanner knows it has a critical vulnerability, and the pipeline knows neither. Unless the rule is evaluated against the inventory at the point where the image ships, the inventory is documentation, not control.

A newer version of the same problem sits on developer laptops: AI coding agents that run shell commands, edit files and call MCP tools, which few organisations can list, let alone govern.

What the standards ask for

• CIS Critical Security Controls, Control 1 and Control 2. Control 1 asks you to actively manage (inventory, track and correct) all enterprise assets, including those in cloud environments, so you know the totality of what needs protecting and can find unauthorised and unmanaged assets. Control 2 asks the same for software, so unmanaged software is found and prevented. CIS treats inventory and control as one control.
• NIST Cybersecurity Framework 2.0, Asset Management (ID.AM). The CSF 2.0 subcategories include ID.AM-02 (inventories of software, services and systems managed by the organisation are maintained), ID.AM-04 (inventories of services provided by suppliers are maintained) and ID.AM-08 (systems, hardware, software, services and data are managed throughout their life cycles). ID.AM-05 adds prioritising assets by classification and criticality.
• CISA Binding Operational Directive 23-01. For federal civilian agencies, BOD 23-01 requires automated asset discovery every 7 days and vulnerability enumeration across all discovered assets every 14 days. Its scope is IP assets on agency networks, not software, but it sets the benchmark: discovery is automated and recurring.
• NIST SP 800-218 (SSDF) task PS.3.2. The SSDF asks software producers to collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM. You cannot meet that for software you do not know you ship.
• NIST AI RMF, GOVERN 1.6. The AI Risk Management Framework playbook asks that mechanisms are in place to inventory AI systems, resourced according to organisational risk priorities. Models in registries, models on developer laptops and the agents that use them all fall under that heading.
• OWASP Top 10 for LLM Applications 2025, LLM06 Excessive Agency. OWASP's list names excessive agency, an LLM based system given more functionality, permission or autonomy than it needs, as a top risk. Knowing which agent holds which permission is the starting point for reducing it.

Together they say the inventory must be continuous, owned, prioritised and tied to control. That is the bar for any discovery tool, Safeguard included.

What does Safeguard asset discovery find?

Safeguard's asset discovery docs describe seven asset classes. Here is each one, where Safeguard gets it from, and why it matters for enforcement.

On top of those seven classes, AI agent discovery (GA) covers the computers your people work on. It runs inside the Safeguard CLI and the Safeguard Desktop app and reports the supported AI coding agents on each device, what each is allowed to do, the skills, plugins, MCP servers and models they use, the credentials they refer to (by name only), and their session activity. The results appear in the same Assets area of the app, under Assets › Inventory › Asset discovery.

If your question is mainly about AI models and SDKs in code, cloud AI endpoints and the AI-BOM itself, the companion post Find every AI model and SDK you ship with Safeguard AI-BOM discovery goes deep on that. AI-BOM discovery is generally available. This post stays on the estate wide inventory and on how enforcement reaches it.

How discovery works: three connection modes

The docs describe three ways Safeguard learns about assets. Most estates need all three, because each one sees something the others cannot.

Agentless integrations

You connect Safeguard to your Git provider, container registries, cloud accounts and model registries with OAuth or IAM roles. From then on, according to the docs, Safeguard continuously:

1. Enumerates new repositories, images and models as they appear.
2. Polls for pushes, tags, releases and deletions, so the inventory follows change rather than lagging behind it.
3. Cross references your CI/CD logs to detect shadow builds, meaning builds that produce artifacts outside the pipelines you know about.

Agentless integrations see only what you connect, which is one reason the shadow asset checks below exist.

Lightweight collectors

For the runtime side, Safeguard has a runtime collector you deploy where workloads run. The docs list three placements:

• Kubernetes clusters: a DaemonSet observes image pulls, workload manifests and admission events.
• Linux hosts and VMs: the collector captures package inventories, running containers and loaded shared libraries.
• CI/CD runners: the collector captures build time manifests and publishes them as runtime SBOMs.

The docs state that collectors send telemetry over mTLS and do not ship source code or binaries off the host.

SBOM ingestion

Vendor software, partner platforms and imported artifacts often cannot be scanned directly. For those, you ingest an SBOM. The docs list Portal upload (drag and drop CycloneDX or SPDX) as the path. Ingested SBOMs are normalised, de-duplicated, enriched with vulnerability data and joined into the asset graph alongside everything else.

The docs page also shows an API path for SBOM upload, but it carries a banner saying the /v1 REST endpoints on that page are not yet available. Use the Portal upload or the in-app flow for now. If you need the supplier side in more depth, see Supplier software risk under DORA, NIS2 and M-22-18 with Safeguard TPRM.

AI agent discovery on people's computers

The fourth source is new and works differently, so it is worth describing on its own. AI agent discovery runs in the Safeguard CLI and the Safeguard Desktop app on the computers your people use. It reads only each agent's own folders, runs as the signed in person (never as administrator), and sends nothing until the organisation has it on and the person agrees.

It reports agents and their permissions (shell, file edits, network, auto approved tools, permission mode), connected MCP servers and tools in use, installed skills and plugins with a hash of each definition, local and used models, credentials by name and kind only (values are never read), and session activity from the agents' own local files.

Supported agents include Claude Code and OpenAI's Codex CLI, along with several other coding agents listed in the docs. Activity reading is supported for some agents and not yet for others; the docs table says which, and each report states per agent whether sessions were read, not supported, or had no local files, so a gap never shows up as "nothing happened".

The asset graph: how discovered assets connect

A flat list of assets answers "what do we have". It does not answer "what is affected" or "who do I call". Safeguard stitches discovered assets into a typed graph. The relationships the docs describe are:

• A vendor provides an SBOM.
• An SBOM describes a container image.
• A container image runs in a Kubernetes workload.
• A repository builds a container image.
• A package belongs to a repository.
• An AI model uses a package.

Those edges let you ask questions that a list cannot answer. The docs give examples of the shape: which production workloads contain a given version of a given library, which vendors ship AI models with unsigned weights, which repositories publish containers that run inside a particular regulated boundary. You run graph queries from the Search page in the app. The docs also show a graph query API path, but it is covered by the same "not yet available" banner, so plan on the app for now.

The graph is also what makes enforcement precise: a production scoped rule needs to know which images are production and which packages each contains.

Ownership and tagging: the fields that route everything

Every discovered asset is assigned four fields, according to the docs:

Per the docs, these fields drive routing, so a finding in a production PCI workload pages different people than one in a dev sandbox.

CODEOWNERS inference is only as good as your CODEOWNERS files, and policies key on environment and sensitivity, so settle that vocabulary before writing policies.

Shadow asset detection: the UNGOVERNED status

The part of discovery most directly tied to enforcement is shadow asset detection. The docs describe Safeguard continuously looking for assets that exist but are not governed, with four examples:

1. A new repository in your organisation that is not connected to Safeguard.
2. An image in a registry with no SBOM.
3. A running container image that is not in any SBOM.
4. A vendor API being called from production but not listed in TPRM.

Shadow findings surface in the Asset Discovery dashboard with an UNGOVERNED status. The docs say they can drive automation, giving two examples: opening a Jira ticket, or blocking deployments until the asset is onboarded.

That is enforcement on discovered assets in its simplest form. Many teams start with tickets and move to blocking once the UNGOVERNED list is short.

Coverage metrics: measuring whether discovery is working

The Asset Discovery dashboard reports three headline coverage metrics, exposed as time series so you can track them over quarters:

• SBOM coverage: the share of running workloads with at least one fresh SBOM.
• Vendor coverage: the share of third party components covered by TPRM records.
• Ownership coverage: the share of assets with an identified owner.

They answer the auditor's question "how do you know your inventory is complete" with a trend rather than a claim.

How enforcement applies to discovered assets

Discovery is half the capability. The offering positions asset discovery and enforcement together for a reason: guardrails and enforcement act on the discovered assets, not just the inventory. Here is how that works in the product as the docs show it.

Policies, gates and guardrails: three terms, three jobs

Safeguard uses three related terms, and it helps to keep them separate.

• Policies (GA) are rules that evaluate your SBOMs and generate findings. A policy defines an acceptable risk threshold or a required control: no critical CVEs, no vulnerabilities above a CVSS score, no license outside an allow list, no abandoned packages, no components older than a set age.
• Gates (GA) are checkpoints that enforce policies. You link policies to a gate, and the gate's outcome follows from its policies. A gate can fail a CI job, block a deployment and require an approved exception to pass a failing rule.
• Guardrails (GA) are the broader enforcement layer: rules Safeguard enforces on your behalf at points in the lifecycle, from the IDE through CI to runtime. The guardrails docs describe them as rules that block, gate or auto remediate at the moment a risk appears, unlike a scanner that only reports.

Creating policies from plain English is also GA and is covered in From plain English security policy to release gates in Safeguard; this post focuses on how the same machinery reaches discovered assets.

Gate actions as the docs show them on 25 October 2026

Every policy carries one Action, and the Action decides what a failed policy does to the gate. The Policies & Gates docs and the Policy outcomes docs, both checked on 25 October 2026, show three Actions:

There is no separate "require approval" Action in the docs today. Approval is handled through policy exceptions: when a developer needs to ship past a failing Block policy, they request an exception with a business justification and an expiry date, and an approver decides. Some Safeguard materials list "require approval" next to block, warn and notify; the docs at write time implement it as the exception workflow described below, so that is what this post describes.

Notify has a useful detail. It does not repeat the same failure on every evaluation. You are notified when a policy goes from passing (or never evaluated) to failing, and again when a failing policy finds new matching issues. A policy that keeps failing with the same matches does not notify again. That keeps a Notify policy on a noisy asset class from turning into alert fatigue.

How a gate's outcome is decided

Policy outcomes are turned on per workspace by Safeguard. If your workspace does not yet show an Outcome column on the gates and policies tables, ask your Safeguard contact to turn it on; while it is off, policies and gates behave as before.

With outcomes on, each policy evaluation records one of four outcomes: Failed (the policy's starred search found matching issues), Passed (the search ran to the end and found none), Error (the policy could not be evaluated, with the reason shown) or Not evaluated (not yet run on this gate). An Error is never counted as a pass.

The gate's own outcome is then worked out in a fixed order:

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 the warning 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. That ordering is conservative on purpose: a broken policy cannot silently let a release through.

A policy runs its starred search each time Safeguard evaluates it on a gate: when the policy is linked to the gate, and again after new assessment data arrives for the product. For discovered assets, that second trigger is the important one. When a newly discovered image or a newly ingested vendor SBOM brings new assessment data into a product, the linked policies run again against it.

Where enforcement happens in the lifecycle

The guardrails docs list enforcement points across the software lifecycle. Here they are, with the honest status of each as the docs describe it on 25 October 2026.

The CI gate is where most teams will enforce on discovered assets today, because the CLI step is documented. Kubernetes admission control is not on the list: the docs say the admission controller is not published yet.

Built-in guardrails relevant to discovered assets

The guardrails docs list curated guardrails you can enable with one click. The ones that apply most directly to an inventory are:

• KEV in production: block images with any CVE on CISA's Known Exploited Vulnerabilities catalog.
• EO 14028 SBOM required: require a CycloneDX SBOM attestation signed in the last 90 days.
• License allow list: block deployment of any component with a license outside your allow list.
• Abandoned package: block deployment of a package with no commits in 365 days and a CVE open for more than 180 days.

Each depends on discovery: "KEV in production" is only as complete as your knowledge of what runs in production. The rule reaches as far as the inventory does.

Exceptions and breakglass

The docs describe the same exception model on the policies page and the guardrails page:

• An approver with the right role can grant an exception for a specific asset for a specific duration.
• Exceptions appear in the audit log and expire automatically.
• Emergency breakglass exceptions require two person approval and trigger alerts in the security channel.

The request flow on the Policies & Gates page is: click Request Exception, select the policy and finding, provide a business justification, set an expiration date, and submit for approval. A notification goes to approvers, an approver decides, and the audit trail records the result.

This is where approval lives today: moving past a failing Block policy is a recorded, time limited, named decision.

Procurement guardrails: enforcement on the vendor class

Vendors are one of the seven discovered asset classes, and the guardrails docs describe procurement guardrails through TPRM (GA):

• Require a signed SBOM from the vendor before contract signing.
• Block vendors whose SBOMs contain components with active critical CVEs.
• Require attestation of NIST SSDF practices for vendors handling regulated data.

Combined with the shadow check for unlisted vendor APIs, this catches the supplier nobody reviewed because nobody knew it was in use.

Observability: proving enforcement happened

The guardrails docs say every guardrail decision is logged to the Safeguard audit stream, emitted as an OpenTelemetry span for SIEM ingestion, and counted in an Enforcement dashboard that shows allow, warn and block trends by policy, team and asset class. The docs also say every guardrail produces a signed audit record so auditors can replay an enforcement decision.

The docs suggest that a policy firing Block thousands of times a week needs auto remediation or a refinement.

Agent identity: enforcement for the agent asset class

Agent identity (GA) answers a specific question: which AI agent holds what access, at what level. As organisations deploy agents against their own systems, "who did this, and was it a person or an agent" becomes an audit question rather than a curiosity.

AI agent discovery supplies much of the raw material. Opening an agent in Assets › Inventory › Asset discovery shows its access summary (shell, file edits, network, auto approved tools, permission mode, extra folders), the projects it worked in, the credentials it refers to by name, and its sessions. Opening a session draws the chain from prompt to agent to tools to sub-agents as a diagram and as a timeline. Opening a model shows where it lives and which agents used it and when.

That is an evidence base for OWASP's excessive agency concern. Pair it with MCP Guardrail (GA), which generates guardrail proxy URLs for MCP servers so agent tool traffic passes through a policy proxy; the details are in Put a policy proxy in front of MCP servers with Safeguard MCP Guardrail.

Agent discovery is visibility and evidence; stopping an action needs a control in its path.

Step by step: from first connection to enforced gates

Here is the full flow, in the order that tends to work, using only screens, settings and commands the docs show. Where the docs do not show a screen, the step describes the outcome instead.

1. Connect your Git provider. In Integrations, connect GitHub, GitLab, Bitbucket or Azure DevOps with OAuth. This is the foundation: repositories build images and own packages, and CODEOWNERS files feed owner inference. See also Repo connection, CLI or local runner.

2. Connect container registries, cloud accounts and model registries. Add each registry and cloud account with OAuth or an IAM role, and connect model registries where you keep models. From here Safeguard enumerates new images and models and polls for pushes, tags, releases and deletions. For images per environment, see Track container images per environment in Safeguard.

3. Deploy the runtime collector where workloads run. Put the DaemonSet on Kubernetes clusters, the collector on Linux hosts and VMs that matter, and the collector on CI/CD runners if you want build time manifests published as runtime SBOMs.

4. Ingest SBOMs for vendor and imported software. Use Portal upload for CycloneDX or SPDX files from suppliers. Each ingested SBOM is normalised, de-duplicated, enriched with vulnerability data and joined to the graph. Link it to the vendor record in TPRM. For SBOM formats, see SBOM generation and analysis in Safeguard.

5. Turn on AI agent discovery. Three parties act here. Safeguard enables the feature for your organisation (it is off by default). An administrator turns it on and chooses the policy: how file paths are shown, whether command lines and web search queries are collected, extra model folders, how often devices report, retention, enrollment (each person asked, or everyone enrolled with a notice) and whether people may opt out. Then each person allows it on their computer, after reading exactly what is collected: in Safeguard Desktop under Settings › Privacy › AI agent discovery › Allow AI agent discovery, or in the CLI:

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

   From then on it runs in the background while the Safeguard runner or Desktop is running, at the interval the organisation sets (15 minutes by default, per the docs). safeguard aidr collect off stops it and deletes what was sent from that computer.

6. Review the inventory in the app. Open the Asset Discovery dashboard for the estate wide view, and Assets › Inventory › Asset discovery for agents, with the Agents, Models, Skills & plugins, MCP servers and Devices tabs and filters for device, person and agent. The Assets module lists all discovered assets, filterable by asset type. There is no CLI command for listing assets or querying the asset graph yet, so this step happens in the app.

7. Fix ownership and tags before writing policies. Check ownership coverage. Assign owners by hand where CODEOWNERS and container labels did not produce one. Normalise environment and sensitivity values so production is always tagged the same way. Your policies will depend on these fields.

8. Work the UNGOVERNED list. For each shadow asset, decide: connect it, onboard it to TPRM, or retire it. Set the automation you want for new shadow assets. The docs give opening a ticket and blocking deployments until onboarding as examples; start with tickets if your list is long.

9. Create policies that target discovered assets. Per the Policies & Gates docs, go to Settings › Policies, click Create Policy, define conditions with the visual builder or YAML, set severity and Action, then save and enable. Start from a template where one fits (for example No Critical Vulnerabilities, License Compliance, EO 14028 Compliance or No Abandoned Packages), and enable the built-in guardrails above that match your rules.

10. Link policies to gates and choose each Action. On the gates view under Policies › Gates, link each policy and set Block, Warn or Notify. A sensible rollout is Notify first, then Warn, then Block once the policy's matches are understood and the owners are in place.

11. Fail CI on the gate. With policy outcomes on for your workspace, add one step to the pipeline:

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

    The step 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 (printing warnings and notified policies), and non-zero when the gate is Failed (printing the Block policies that failed), Error, Not evaluated, or not evaluated before --timeout, with a message saying why. --fail-on <severity> still works and can be combined with it. The CI/CD integration docs cover the key the pipeline needs.

12. Set up exceptions and approvers. Decide who approves exceptions for which asset classes and sensitivity levels, and agree on maximum durations. Make sure breakglass approvers know they are on the hook for two person approval in an emergency.

13. Watch the dashboards. Track SBOM, vendor and ownership coverage over time, and use the Enforcement dashboard to spot policies that fire too often. Expand a gate to see each linked policy's Action, outcome, effect on the gate, matches and evaluation history.

Which mechanism for which situation

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

Honest limits, as of 25 October 2026:

1. No CLI command for assets yet. The docs say there is no CLI command for listing assets or querying the asset graph. The CLI handles AI agent discovery collection and CI gating; inventory review happens in the app.
2. The asset discovery REST endpoints are not live. The asset discovery docs page carries a banner that every path under the /v1 REST API on that page returns 404 today and describes intended shape only. Do not build integrations against the SBOM upload or graph query paths shown there.
3. No Kubernetes admission controller to install. The docs say the admission controller is not published. Blocking at deploy time through admission control needs another mechanism for now. CI gates are the documented enforcement point.
4. No separate "require approval" gate Action. Gates use Block, Warn and Notify. Approval is an exception request with a justification and expiry, approved by a named person. If your process needs a gate that pauses for sign off, model it as Block plus an exception.
5. Policy outcomes are switched on per workspace by Safeguard. Until they are on, there is no Outcome column and --fail-on-gate is not available to you. Ask your Safeguard contact.
6. Discovery only sees what you connect. Agentless integrations cover the Git organisations, registries, cloud accounts and model registries you connected. A cloud account nobody connected is invisible until something else (a running image with no SBOM, a shadow build) points at it.
7. AI agent discovery needs consent and a supported agent. It runs only where the Safeguard CLI or Desktop app runs, the organisation has it on, and the person agreed or was enrolled. Agents not on the supported list are not detected, and session activity is not read for every supported agent.
8. Network asset discovery is out of scope. Safeguard discovers software assets. Scanning an IP range for every addressable host, as BOD 23-01 asks of federal agencies, is a network discovery job for a different tool.

Common mistakes

Writing policies before fixing ownership and tags. A production scoped Block policy with half the production assets tagged differently enforces on half the estate. Settle environment and sensitivity values first, then write policies.

Going straight to Block on day one. A new Block policy on a newly discovered estate fails many builds at once and gets switched off. Go Notify, then Warn, then Block.

Treating the UNGOVERNED list as a report. Shadow assets are the point of discovery. If nobody owns the UNGOVERNED list, it grows until it is ignored. Give it an owner and a weekly review.

Expecting a "require approval" Action. It is not in the Action list today. Build the approval path on exceptions, with clear approvers and maximum durations.

Turning on AI agent discovery without telling people. Explain what is collected before you switch it on (prompts and responses are off by default, credential values are never read). safeguard aidr collect show is a good thing to put in front of a privacy reviewer.

Forgetting exceptions expire. Exceptions end automatically. If a team's fix is not merged by the expiry date, the gate fails again. Set expiries that match a realistic fix date, not an optimistic one.

FAQ

What is asset discovery in Safeguard?

It is the generally available capability that continuously catalogs repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads, joins them into an asset graph with an owner, business unit, environment and sensitivity on each, and flags assets that exist but are not governed. Enforcement then applies to those assets through policies, gates and guardrails.

What gate actions does Safeguard support?

The docs checked on 25 October 2026 show three policy Actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification goes to your configured channels). Approval is handled through a policy exception workflow with a justification, an expiry date and an approver.

How does Safeguard find shadow assets?

It continuously looks for assets that exist but are not governed. The docs give four examples: a repository in your organisation that is not connected, an image in a registry with no SBOM, a running container image that is in no SBOM, and a vendor API called from production but not listed in TPRM. These show as UNGOVERNED in the Asset Discovery dashboard.

Can Safeguard block deployment of an asset it just discovered?

The docs say UNGOVERNED findings can drive automation such as blocking deployments until the asset is onboarded, and CI gates can fail a pipeline on a failing Block policy. The Kubernetes admission controller is not published yet, so blocking at the cluster admission step is not available today.

Does Safeguard have a CLI command to list assets?

Not yet. The docs say there is no CLI command for listing assets or querying the asset graph. Use the Assets module and the Search page in the app. The CLI does handle AI agent discovery (safeguard aidr collect) and CI gating (safeguard ci scan --fail-on-gate).

Does Safeguard asset discovery scan IP ranges for hosts?

No. It discovers software assets: repositories, images, packages, models, SBOMs, vendors and workloads. Network discovery of every addressable host, as CISA BOD 23-01 asks of federal agencies, needs a network discovery tool.

How is agent identity different from AI agent discovery?

AI agent discovery is how Safeguard finds agents on devices and what they can do. Agent identity is the governance view built on that: which agent holds what access, at what level, so you can answer whether an action came from a person or an agent and whether that agent should have had the access.

How often does Safeguard re-evaluate discovered assets?

Policies run when they are linked to a gate and again after new assessment data arrives for the product. AI agent discovery reports at the interval your organisation sets, 15 minutes by default per the docs. Agentless integrations poll for pushes, tags, releases and deletions continuously.

The next two sections are not specific to asset discovery, but they are what you do once discovery and gates have shown you which assets carry vulnerable components. Discovery tells you where the exposure is; the block below covers how to close it without waiting on an upstream release.

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 demos below are short interactive walkthroughs of real Safeguard surfaces. None of them is an asset discovery screen recording; each shows a surface you would use around discovery and enforcement.

The first shows Safeguard used from Claude after installing it from Claude's connector directory. Once your assets and gates are in Safeguard, you can ask which products have a failing gate, and the read-only gate and policy outcome tools answer where your MCP access settings allow them.

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

The second shows the Safeguard CLI at work in a terminal. Since CLI v11.10.0 it asks before any command that changes something, while read-only commands run without asking in the default Auto mode. The CLI is where both safeguard aidr collect for AI agent discovery and the safeguard ci scan --fail-on-gate gate step live.

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

The third shows the Safeguard Desktop app. Desktop is one of the two places AI agent discovery runs, and its Settings › Privacy screen is where each person allows it on their own computer.

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

To try it on your own estate, download Safeguard and follow the Safeguard docs to connect your first Git provider and registry. For an overview of every capability in one place, see What Safeguard does today, and for the background on why continuous discovery beats periodic inventory, see Continuous asset discovery versus quarterly inventory.

Quick check

Sources

• Safeguard docs: Asset Discovery
• Safeguard docs: AI agent discovery
• Safeguard docs: Guardrails & Enforcement
• Safeguard docs: Policies & Gates
• Safeguard docs: Policy outcomes and actions
• CIS Critical Security Control 1: Inventory and Control of Enterprise Assets
• CIS Critical Security Control 2: Inventory and Control of Software Assets
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST AI RMF Playbook: GOVERN
• OWASP Top 10 for LLM Applications 2025

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