Find Every AI Model and SDK You Ship with Safeguard AI-BOM (Early Access)

Safeguard finds the AI you ship by inventorying it from three places: AI SDK imports and model files in your code, managed inference endpoints in your cloud accounts, and unsanctioned AI tools in connected SaaS. It assembles the results into an AI bill of materials (AI-BOM) that the docs say is emitted in CycloneDX ML-BOM format and the SPDX 3.0 AI profile. AI-BOM discovery is early access: an administrator switches it on through a feature flag, and coverage depends on which sources you connect.

An AI inventory sits under several obligations at once (EU AI Act technical documentation, the NIST AI RMF inventory subcategory, the G7 minimum elements for an SBOM for AI), and each Safeguard piece that feeds it has its own maturity level. This post covers the requirements, the formats, the product flow as the docs describe it, and the gaps you still own.

Key takeaways

• AI-BOM discovery (early access) inventories AI SDK imports (openai, anthropic, langchain, transformers, llama_index), model weight files, prompt templates, notebooks and MCP server configuration in code; SageMaker, Bedrock and Vertex AI endpoints through cloud connectors; vector databases; and shadow AI in connected SaaS.
• AI agent discovery (early access) runs inside the Safeguard CLI and the Safeguard Desktop app (early access, beta) on your people's computers. It reports which AI coding agents are installed, what each may do, which MCP servers, skills and models they use, and what they did. Safeguard enables it per organisation, an administrator turns it on, and each person agrees on their own machine.
• Model scanning (GA) covers LLMs and SLMs pulled from Hugging Face or supplied directly, plus agent skills and agent configurations. The Hugging Face integration is the clearest way in today.
• AI-SPM model artifact scanning (early access) inspects pickle, PyTorch, safetensors, GGUF and ONNX files statically, without loading them, and maps findings to CWE entries.
• Asset discovery (GA) covers repositories, images, packages, SBOMs, vendors, workloads and AI models from model registries, and flags assets that exist but are not governed.
• Agent identity (GA) tracks which agent holds what access, at what level. MCP Guardrail (early access) keeps agent records with status, risk and anomaly scores for traffic it proxies.
• Compliance and GRC suite (GA) includes an EU AI Act framework whose scan requirements read your product's software inventory. Policies, gates and guardrails (GA) apply to discovered assets.
• An inventory is not a conformity assessment. The docs also say there is no CLI command for listing, verifying or exporting AI-BOMs yet.

The problem: you cannot document AI you cannot see

Most engineering organisations ship AI in more ways than anyone has written down. A product team adds the anthropic Python SDK to summarise tickets. A data team fine-tunes an open model and stores the weights in a bucket. A platform team creates a managed inference endpoint. Developers run coding agents on their laptops, connect them to MCP servers, and download quantised models into a local runtime.

A traditional SBOM shows little of that. A dependency scanner sees the openai package as just another package. It does not record which model the code calls, what data flows to it, or which agent on which laptop holds a token for it. So when an auditor asks "which AI systems do we run and what are they built from", the answer is often a spreadsheet that was correct last quarter. You cannot assess the risk of a model you do not know is in production, and you cannot write the technical documentation the EU AI Act requires for a high-risk system if you cannot enumerate its components.

What the EU AI Act expects you to know

The EU AI Act (Regulation (EU) 2024/1689) puts the inventory question at the centre of its documentation duties. Three provisions matter most for an AI-BOM.

Article 11, technical documentation. For a high-risk AI system, the provider must draw up technical documentation before the system is placed on the market or put into service, and keep it up to date. The documentation has to demonstrate that the system meets the requirements in Chapter III, Section 2, and "contain, at a minimum, the elements set out in Annex IV" (Article 11(1), as shown on the European Commission's AI Act Service Desk). The Service Desk marks passages amended by the Digital Omnibus on AI, including a simplified documentation form for SMEs and small mid-caps, so read the current text there rather than an older copy.

Annex IV, the content of that documentation. Annex IV is where an AI-BOM earns its keep. Point 1 asks for a general description, including how the system interacts with hardware or software "including with other AI systems, that are not part of the AI system itself" (1(b)), the versions of relevant software or firmware (1(c)), and the forms in which the system is placed on the market, such as downloads or APIs (1(d)). Point 2 asks for a detailed description of the system's elements, including "recourse to pre-trained systems or tools provided by third parties" and how they were integrated or modified (2(a)), the system architecture and how software components build on or feed into each other (2(c)), data requirements including the provenance of training data sets (2(d)), and the cybersecurity measures in place (2(h)).

Put plainly: if you cannot list the models, SDKs, third-party AI services, datasets and versions inside a high-risk system, you cannot complete Annex IV.

Article 53, general-purpose AI models. Article 53 binds providers of general-purpose AI models, not most teams that call them. Those providers must keep model documentation for the AI Office (53(1)(a), content in Annex XI) and give integrating AI system providers the information in Annex XII (53(1)(b)). For a buyer, 53(1)(b) is the provision that obliges your model provider to give you documentation you can attach to your inventory entry.

When this applies. Per Article 113 on the Service Desk (with Digital Omnibus amendments), Chapter V on general-purpose models has applied since 2 August 2025. The high-risk requirements apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Those dates have moved before; confirm them when you plan.

What NIST AI RMF 1.0 and NIST AI 600-1 expect

The NIST AI Risk Management Framework (NIST AI 100-1, January 2023) is voluntary, but many US organisations and auditors use it as the reference vocabulary. Four subcategories map directly to an AI inventory:

• GOVERN 1.6: mechanisms are in place to inventory AI systems, resourced according to organisational risk priorities.
• GOVERN 6.1: policies and procedures address AI risks associated with third-party entities.
• MAP 4.1: approaches for mapping the technology and legal risks of an AI system's components, including third-party data or software, are in place, followed and documented.
• MANAGE 3.2: pre-trained models used for development are monitored as part of regular AI system monitoring and maintenance.

The Generative AI Profile (NIST AI 600-1, July 2024) makes GOVERN 1.6 concrete. GV-1.6-001 says to enumerate generative AI systems for the inventory. GV-1.6-003 lists what an entry should consider, including data provenance, known issues from sources such as CVE and NVD, and "underlying foundation models, versions of underlying models, and access modes." GV-1.6-002 asks you to define inventory exemptions for generative AI embedded in application software, which means a written position on AI inside the products you buy.

What ISO/IEC 42001 expects

ISO/IEC 42001:2023 specifies requirements for an AI management system, and a management system needs a defined scope: you cannot scope AI you have not found. We could not retrieve the ISO page while writing this, so we do not quote its clauses or Annex A controls; read the standard itself before mapping controls to it.

What the G7 minimum elements for an SBOM for AI add

In May 2026, CISA and the other G7 cybersecurity agencies (Germany's BSI, Italy's ACN, France's ANSSI, Canada's CSE, the UK NCSC and Japan's NCO, with the European Commission) released Software Bill of Materials for AI: Minimum Elements. It builds on the G7 shared vision of June 2025, says the elements are not mandatory, and adds them on top of the general SBOM minimum elements because AI systems are also software systems.

It groups the elements into seven clusters: Metadata, System Level Properties, Models, Datasets Properties, Infrastructure, Security Properties, and Key Performance Indicators. The Models cluster asks for name, identifier, version, timestamp, producer, description, hash value and algorithm, properties, input and output properties, training properties, licence and external references. The System Level Properties cluster includes "System data flow", whose examples include the APIs of external services the AI system uses. So a model you only call over an API still belongs in the record. (When we fetched CISA's landing page on 23 October 2026, its heading read "for SI" while the body and the BSI document say "for AI"; the document is the authority.)

What is an AI-BOM, and how do CycloneDX ML-BOM and the SPDX 3.0 AI profile differ?

An AI-BOM is a structured inventory of the AI components in a system and how they relate: models, datasets, AI frameworks and SDKs, external AI services, agents and the tools they reach, with the provenance, versions, licences and hashes needed to trust them. It extends an SBOM rather than replacing it. Two open formats carry AI-BOM data today.

CycloneDX ML-BOM. CycloneDX has a machine-learning-model component type, a data component type, and a modelCard object that the 1.6 schema says "SHOULD be specified" for model components. The model card holds modelParameters (approach, task, architecture, datasets, inputs, outputs), quantitativeAnalysis (performance metrics) and considerations (users, use cases, technical limitations, ethical, environmental and fairness considerations). External APIs your system calls fit the services element, which carries provider, endpoints, authentication, trust boundary and data flow.

SPDX 3.0 AI profile. SPDX 3.0 (current release 3.0.1) defines an AIPackage class, a subclass of Software Package, with properties such as typeOfModel, domain, hyperparameter, metric, informationAboutTraining, limitation, modelExplainability, safetyRiskAssessment, standardCompliance, energyConsumption, autonomyType and useSensitivePersonalInformation. It requires suppliedBy, releaseTime, downloadLocation, packageVersion and primaryPurpose, and for profile conformance every AIPackage needs exactly one concluded and one declared licence relationship. A separate Dataset profile covers data.

The G7 document is format neutral, and Safeguard's docs say its AI-BOM is emitted in both. Pick the format your auditors and customers already consume. For more background, see AI bill of materials explained and Do you need an ML-BOM, or is an SBOM enough?.

Where Safeguard looks

Safeguard's AI inventory is built from several capabilities, each with its own maturity label. It helps to see them side by side before the walkthrough.

Code, cloud, SaaS and vector stores

The code surface is the most direct signal for "which AI do we ship". Each discovered asset is catalogued with type, name, source, format and metadata, and the assets for a product are assembled into an AI-BOM: a tenant and organisation scoped snapshot at a point in time. An import tells you an SDK is present and which provider it talks to; if your code picks the model name at runtime from configuration, check what the AI-BOM shows before you rely on it for Annex IV point 1(c).

Cloud connectors catch the SageMaker, Bedrock or Vertex AI endpoint a platform team created in a console and never committed, but only in accounts you connected. Shadow-AI detection sees what flows through the SaaS integrations you authorised, not a tool someone bought on a personal card. Vector stores matter because they often hold the retrieval data that shapes a system's outputs, the kind of data provenance Annex IV point 2(d) asks about.

The computers your people use: AI agent discovery

AI agent discovery is a separate, early access capability that runs inside the Safeguard CLI and the Safeguard Desktop app. It reads each supported agent's own configuration and session folders. For Claude Code, that includes files such as ~/.claude/settings.json and project .claude/settings*.json, which Anthropic's Claude Code docs describe as the user and project settings files that carry permission rules and defaults. For the OpenAI Codex CLI, it includes ~/.codex/config.toml, which OpenAI's Codex docs describe as the user-level configuration file. The docs page lists several other coding agents and editor extensions, along with local model folders for Ollama, LM Studio, the Hugging Face cache and Jan. Agents not on the list are not detected.

Per device and per person, it reports the agents installed and what each may do (shell commands, file edits, network access, auto-approved tools, sandbox and permission mode); the MCP servers each connects to; installed skills, plugins, rules and sub-agent definitions, each hashed so it can be scanned later; local model files with format, size, parameter count and quantisation; credentials by name and kind only; and activity from the agents' own session files, as a chain from prompt to agent to tool calls and sub-agents.

Session coverage differs by agent. The docs say Claude Code and Codex sessions are read from local files, while several other agents show "Not supported yet" for sessions. Each report says per agent whether sessions were read, not supported, or had no local files, so a gap is not shown as "nothing happened".

Step by step: switch on discovery, review what it found, get the AI-BOM out

The steps below follow the Safeguard docs. Where the docs do not show a screen or command, we describe the outcome instead of inventing one.

Part A: AI-BOM discovery across code, cloud and SaaS (early access)

1. Ask for the engine to be enabled. The docs say AI-BOM discovery is part of the AI-SPM engine and is admin-toggleable through the ff.aispm feature flag, enforced server-side. Because it is early access, start by asking your Safeguard contact to confirm it is available for your organisation.

2. Connect the sources you want covered. Discovery runs across connected repositories, cloud accounts and SaaS integrations. Each one you leave out is a blind spot, so decide coverage deliberately: which source control organisations, which cloud accounts (the ones that hold SageMaker, Bedrock or Vertex AI workloads), and which SaaS integrations.

3. Let the standard scan flow run. Once enabled, the docs say discovery runs "through the standard scan flow". You do not run a separate AI-BOM command. Discovered assets are catalogued with type, name, source, format and metadata, then assembled per product into an AI-BOM snapshot.

4. Connect Hugging Face for model scanning (GA). Open Integrations, choose the Project/Product tab and click Connect on the Hugging Face card. For public models, choose Public, enter a name, paste a model URL such as https://huggingface.co/<owner>/<model>, click Add, then Next. For private and gated models, choose Private, paste a Hugging Face user access token, verify it, then select the models and revisions to scan, review and connect. The docs recommend a fine-grained read-only token limited to the models or organisation you want scanned, and rotating it at least every 90 days. Safeguard only reads; it never pushes commits or edits model cards.

   If you want to check the token before pasting it, the docs show Hugging Face's own CLI:

   hf auth login --token "$HF_TOKEN"
   hf auth whoami
   

   Each selected model is scanned when you connect it, and an AI inventory entry is recorded. There are no webhooks for this integration; to rescan new revisions, set a schedule under Integrations › Scheduled or rescan by hand.

5. Scan local model directories where the docs show it. The AI-BOM and Model Security page shows one CLI command for model files:

   safeguard aisec scan --dir ./models
   

   The docs describe it as scanning a directory of model files for unsafe deserialization or embedded code. Treat the depth of these checks as part of the early access AI security work and confirm format coverage with your Safeguard contact.

6. Review the inventory and the findings it feeds. Discovery is an inventory pass, so its main output is the AI-BOM, not findings. The docs say model assets are handed to AI-SPM model scanning (findings land in the unified findings model), shadow-AI services surface for governance review, and visibility gaps lower your AI-visibility posture score.

Part B: AI agent discovery on your people's computers (early access)

7. Have Safeguard enable the feature. The docs name the feature inventory:ai_agent_discovery, off by default and switched on per organisation by Safeguard.

8. Set the organisation policy. An administrator turns it on and chooses how file paths are shown, whether command lines and web search queries are collected, extra model folders, how often devices report (15 minutes by default), retention (30 days for activity by default), and whether enrolment is per person or organisation-wide with a notice.

9. Each person allows it on their computer. In Safeguard Desktop: Settings › Privacy › AI agent discovery › Allow AI agent discovery. In the CLI, with these commands from the docs:

   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
   safeguard aidr collect            # collect and send once now
   safeguard aidr collect off        # stop, and delete what was sent from this computer
   

   Running show first is a good habit during rollout: people see exactly what would leave their machine.

10. Review it in the app. Open Assets › Inventory › Asset discovery. The tabs are Agents (each agent on each device, its access summary, models, skills and MCP servers), Models (local model files and remote models agents used), Skills & plugins, MCP servers, and Devices. You can filter by device, person and agent. Opening an agent shows its access summary, projects, credentials by name, and sessions; opening a session draws the chain from prompt to agent to tools to sub-agents as a diagram and a timeline.

Part C: put the inventory to work

11. Turn on the EU AI Act framework in Compliance (GA). The EU AI Act framework page says the framework is on in your workspace unless you switch it off in Compliance › Manage. Each product scan checks scan requirements against the product's software inventory, including EU-AIA-11 (technical documentation of system elements, tied to Article 11 and Annex IV), EU-AIA-11V (version traceability), EU-AIA-15 (cybersecurity and integrity), EU-AIA-25 (value chain responsibilities), EU-AIA-12 (record-keeping foundations) and EU-AIA-13 (transparency to deployers). The Controls tab adds catalog controls such as EUAI-ART53 (general-purpose model obligations) and EUAI-SBOM (document AI model and component supply chain), which you evidence with tests, uploads, policies or attestations. See continuous compliance in Safeguard for how evidence works.

12. Apply policies and gates to what you found (GA). Asset discovery's enforcement half is the point: Safeguard applies guardrails and enforcement to discovered assets, not only inventory. A gate can block, warn, notify or require approval at a checkpoint. The AI-specific policy fields available to you depend on what your tenant exposes, so build policies from the fields you can see in the app rather than from a sample you found elsewhere.

13. Get the AI-BOM out. The docs say the AI-BOM is emitted in CycloneDX ML-BOM format and the SPDX 3.0 AI profile, and that it is queryable in the app. They also say, plainly, that there is no CLI command for listing, verifying or exporting AI-BOMs yet, and the docs do not show a dedicated export screen. In practice, open the product's AI inventory in the app and use the export the app offers for it; if your tenant does not show one, ask your Safeguard contact for the ML-BOM or SPDX AI output for that product. Do not script against REST endpoints for this until the docs list them as available.

How does Hugging Face model scanning (GA) differ from AI-SPM artifact scanning (early access)?

Both look at model files. They differ in where they sit and how mature they are.

Model scanning (GA) is the capability the offering catalogs as scanning LLMs and SLMs pulled from Hugging Face or supplied directly, plus agent skill definitions and agent configurations with their tool access. The Hugging Face integration is its most concrete form: you pick models and revisions, Safeguard downloads their files for the scan (it does not keep the weights), and it records the results and an AI inventory entry. The integration docs describe the scan as looking for security issues "such as unsafe serialization formats and embedded code".

AI-SPM model artifact scanning (early access) is the feature-flagged engine that scans model artifacts as they are ingested through your registries and pipelines. Its docs describe format-specific static analysis that never loads the model:

• Pickle (.pkl, .bin, PyTorch state dicts): flags code-execution instructions such as imports of os, subprocess or eval, and load-time steps that run code during deserialization, mapped to CWE-502 (unsafe deserialization) and CWE-94 (code injection).
• PyTorch .pt and .zip archives: unpacks the archive and inspects each embedded component for the same patterns.
• safetensors: confirms the file is a tensor-only artifact.
• GGUF: validates the container so malformed or tampered files are caught before use.
• ONNX: inspects the graph without executing it, flagging custom or non-standard operators and embedded code-execution steps (CWE-94), and external-data references whose path escapes the model directory (CWE-22, path traversal).

Why the format matters is not a Safeguard claim; it comes from the frameworks themselves. PyTorch's torch.load documentation warns that it uses an unpickler under the hood and says "Never load data from an untrusted source." Hugging Face describes safetensors as a format for storing tensors safely, as opposed to pickle. A format check tells you whether loading a file can run code; it does not tell you whether the model behaves well.

Use the Hugging Face integration now for Hub models, and plan AI-SPM for the registry and pipeline path once it is enabled for you. For how these fit with runtime controls, see AI-SPM, AI Gateway and AI-BOM.

How does agent identity show which agent holds what access?

Agent identity (GA) is Safeguard's answer to a question auditors increasingly ask: when an action happened, was it a human or an agent, and what was that agent allowed to do? The offering describes it as tracking which agent holds what access, at what level.

From AI agent discovery (early access), each agent on each device carries an access summary: whether it can run shell commands, edit files or reach the network, which tools are auto-approved, its sandbox and permission mode, and extra folders it can reach. You also see the credentials it refers to, by name and kind (for example, an ANTHROPIC_API_KEY environment variable or a Codex login file being present), and the MCP servers it connects to. That is "what access, at what level" for coding agents on workstations.

From MCP Guardrail (early access), Safeguard keeps agent records for traffic that flows through its proxy. The Servers and Agents docs say each agent record has a status (active, blocked or quarantined), a running risk score and anomaly score, request and blocked-request counters, and a last-seen time. Agents are registered explicitly; the docs say Guard does not automatically detect new agents on the network, and MCP servers are registered explicitly too. Alerts and audit trails then reference agents and servers by registered name and ID. The companion post Put a policy proxy in front of MCP servers covers that flow.

Together they show what an agent is configured to do on a laptop and what it attempted through a governed MCP path.

Do you need an AI-BOM entry for a model you only call through an API?

Yes. The model's weights are not in your repository, but the dependency is real, and every framework above expects you to record it.

• EU AI Act, Annex IV: point 1(b) asks how the system interacts with other AI systems that are not part of it, and point 2(a) asks about recourse to pre-trained systems or tools provided by third parties.
• NIST AI 600-1, GV-1.6-003: inventory entries should consider underlying foundation models, their versions, and access modes. "Access mode: hosted API" is an answer.
• G7 SBOM for AI minimum elements: the System data flow element lists the APIs of external services the AI system uses.

What the entry should hold is different from a model you host. You will not have a weight hash. You should have the provider, the model identifier and version string you request, the SDK and its version, the endpoint or region, what data you send, the provider's documentation under Article 53(1)(b) if it is a general-purpose model, and the contractual terms that govern retention. In CycloneDX, an external AI API fits naturally as a service with its provider, endpoints and data flow, linked to your application component. In SPDX 3.0, you would describe it with relationships from your package to an AIPackage that records suppliedBy and packageVersion.

On the Safeguard side, AI-BOM discovery's code surface recognises the SDK imports for the major providers, and AI agent discovery's Models tab lists remote models agents used. Neither replaces a human confirming which model version a production system calls.

What discovery misses

Every inventory has edges. Knowing them is what makes the inventory defensible.

• Personal accounts and unmanaged devices. AI agent discovery runs only where the Safeguard CLI or Desktop app runs, the organisation has it on, and the person has agreed or been enrolled. An agent on a personal laptop is invisible. Shadow-AI detection sees tools that come through SaaS integrations you connected, not a consumer subscription on a personal card.
• Unsupported agents and server-side agents. Agents not on the supported list are not detected, and some listed agents report configuration but not sessions. Agents running as production services are visible to MCP Guardrail only when registered and routed through it.
• Models embedded in vendor products. If a product you buy uses a model internally, nothing in your code or cloud reveals it. Ask vendors for an SBOM or AI-BOM, record your position as NIST GV-1.6-002 suggests, and track it in TPRM (GA), which can request SBOMs from vendors but cannot make a vendor disclose what it will not.
• Sources you did not connect, and runtime choices. A cloud account nobody connected is a blind spot. An import scan sees the SDK; if the model is chosen at runtime, confirm the entry against configuration.

What Safeguard does not do

Honest limits, so you can plan around them.

1. It does not make you compliant with the EU AI Act. An inventory and a set of scan requirements are inputs to your technical documentation and conformity assessment, not the assessment. Classification of your system as high-risk, your risk management system under Article 9, human oversight, accuracy testing and the declaration of conformity remain your work, and in some cases a notified body's.
2. AI-BOM discovery, AI agent discovery and AI-SPM are early access. They are switched on per organisation through feature flags, depth varies, and coverage depends on the sources you connect. Ask for a scoped demo on your own repositories and cloud accounts before you commit to dates.
3. There is no CLI command for listing, verifying or exporting AI-BOMs yet, per the docs, and the REST endpoints on the asset discovery page are marked as not yet available. Plan exports through the app and your Safeguard contact.
4. It does not see what it is not connected to. Personal accounts, unenrolled devices, unconnected cloud accounts, unsupported agents and AI inside vendor products need other controls: procurement rules, device management, vendor questionnaires and contracts.
5. It does not judge model quality or behaviour. Format scanning tells you whether loading a file can run code. It does not evaluate accuracy, bias, or whether a model is fit for its intended purpose, which Annex IV point 2(g) expects you to test and document.
6. It does not read prompts or credential values by default. Prompt capture needs Safeguard, the administrator and each person to opt in, and credential values are never read. Good for privacy; some investigations will need other sources.
7. It does not write your model cards or your Article 53 documentation. If you are a general-purpose model provider, Annex XI and Annex XII content is yours to produce.

Requirement versus what Safeguard does versus what you still own

Common mistakes

Treating the SBOM as the AI-BOM. A package list that includes transformers says nothing about which model loads, where its weights came from, or what data trained it. Keep the SBOM and add the AI-specific record.

Inventorying only what is in Git. The endpoint created in a cloud console, the model in a bucket and the agent on a laptop are all outside the repository. Connect cloud accounts and roll out agent discovery, or document why you have not.

Skipping API-only models. "We do not host any models" is a common and wrong answer to "which AI do we use". Record the provider, model version and access mode.

Rolling out agent discovery without telling people. The product supports per-person consent and shows exactly what it would send. Use that. Publish your collection policy, run safeguard aidr collect show in a team meeting, and let people see the notice before you switch on organisation-wide enrolment.

Assuming a passed format scan means a safe model. A tensor-only safetensors file cannot run code at load time. It can still be the wrong model, a poorly performing one, or one with an unacceptable licence.

Planning around early access features as if they were GA. Scope the pilot, confirm coverage for your tenant, and keep a manual fallback for anything an auditor will ask about.

Writing the documentation once. Article 11 says technical documentation must be kept up to date. A one-off spreadsheet decays; a scheduled inventory with version history does not.

FAQ

What is an AI-BOM?

An AI bill of materials is a structured inventory of the AI components in a system: models, datasets, AI SDKs and frameworks, external AI services, agents and their tools, with versions, provenance, licences and hashes. It extends an SBOM with the AI-specific facts an SBOM has no fields for.

Is Safeguard AI-BOM discovery generally available?

No. AI-BOM discovery is early access, enabled through the ff.aispm feature flag by an administrator. AI agent discovery and AI-SPM model artifact scanning are also early access. Model scanning through the Hugging Face integration, asset discovery and agent identity are GA.

Does Safeguard export a CycloneDX ML-BOM or SPDX AI profile?

The docs say the AI-BOM is emitted in CycloneDX ML-BOM format and the SPDX 3.0 AI profile and is queryable in the app. They also say there is no CLI command for exporting AI-BOMs yet, so plan exports through the app or your Safeguard contact.

Does AI agent discovery read my prompts or API keys?

Not by default. It collects tool names, order, timing, counts, models and token counts. Prompts, responses and full tool inputs are only collected if Safeguard enables prompt capture, an administrator turns it on, and the person separately agrees, and then they are masked and truncated. Credential values are never read; credential files are only checked for presence.

Which coding agents does AI agent discovery support?

The docs list Claude Code and the OpenAI Codex CLI among several supported agents and editor extensions, plus local model folders for Ollama, LM Studio, the Hugging Face cache and Jan. Session activity is supported for some agents and marked "not supported yet" for others. Agents not on the list are not detected.

Do I need an AI-BOM for the EU AI Act?

The AI Act does not use the term, but Article 11 and Annex IV require high-risk system documentation that enumerates software versions, third-party pre-trained systems and data provenance. An AI-BOM is the practical way to keep that part current. General-purpose model providers have separate duties under Article 53.

How is an AI-BOM different from NIST AI RMF's AI inventory?

GOVERN 1.6 asks for an organisation-level inventory of AI systems. An AI-BOM describes the components of one system. The inventory tells you which systems exist; each AI-BOM tells you what one is built from.

What does the Hugging Face integration need?

A model URL for public models, or a Hugging Face user access token with read access for private and gated ones. The docs recommend a fine-grained read-only token limited to the models you want scanned, rotated at least every 90 days. Safeguard never writes to Hugging Face and does not store model weights.

An AI-BOM shows you which SDKs, frameworks and model runtimes you ship, and those are ordinary open source dependencies with ordinary vulnerabilities. When one of them has a known issue, the same remediation and Gold flows that handle the rest of your dependency tree apply, so the inventory turns into fixes rather than a list.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

None of these demos shows AI-BOM discovery itself. They show the surfaces that discovery runs in and the way you work with Safeguard from an assistant, which is how you would use the inventory day to day.

The first is a real Safeguard Desktop app session. The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit, and it ends with an upgrade done and tests passing. AI agent discovery runs inside this same Desktop app (early access, beta), and its consent switch lives under Settings › Privacy.

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

The second is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and approve each command as it edits package.json, runs npm install and npm test, and prints a summary without pushing anything. The safeguard aidr collect commands in this post run from the same CLI, so this is a fair picture of the tool your developers would enrol with.

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

The third connects Claude to Safeguard: you install Safeguard from Claude's connector directory, sign in with OAuth, and choose which Safeguard tools Claude can use. Once your AI inventory is in Safeguard, this is how a governance lead could ask questions about it from an assistant they already use. Safeguard is listed in the Claude directory as a community connector; see Safeguard in your IDE and in the Claude and ChatGPT connector directories.

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

To try the CLI or Desktop app, start at safeguard.sh/download, and read the docs at docs.safeguard.sh/docs. Related reading: What Safeguard does today, Safeguard AI Gateway (early access), and AI-BOM and EU AI Act Article 10.

Quick check

Sources

• Safeguard docs: AI-BOM Discovery
• Safeguard docs: AI-BOM and Model Security
• Safeguard docs: AI agent discovery
• Safeguard docs: Asset Discovery
• Safeguard docs: AI Security Posture Management (AI-SPM)
• Safeguard docs: Hugging Face integration
• Safeguard docs: Servers and Agents (Guard)
• Safeguard docs: EU AI Act framework
• AI Act Service Desk: Article 11, Technical documentation
• AI Act Service Desk: Annex IV, Technical documentation
• AI Act Service Desk: Article 53, Obligations for providers of general-purpose AI models
• AI Act Service Desk: Article 25, Responsibilities along the AI value chain
• AI Act Service Desk: Article 113, Entry into force and application
• NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0
• NIST AI 600-1, Generative Artificial Intelligence Profile
• CISA: Software Bill of Materials for AI, Minimum Elements
• BSI: Software Bill of Materials for AI, Minimum Elements (G7, PDF)
• CycloneDX: Machine Learning Bill of Materials (ML-BOM)
• CycloneDX 1.6 JSON schema
• SPDX 3.0.1 specification: AI profile
• SPDX 3.0.1 specification: AIPackage class
• PyTorch docs: torch.load
• Hugging Face docs: Safetensors
• Anthropic: Claude Code settings
• OpenAI: Codex config basics

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