Live webinarWebinar with Jason Lee, Tue, Oct 13Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkRegister

Find every AI in your code.

Every model, agent, MCP server and guardrail in your code, catalogued in one scan.

checkout-apiAI-BOMDemo project
  • Shadowmcp://prod-postgresinfra/mcp.ts:42

    An agent tool on the production database, with no declared scope.

    url: "mcp://prod-postgres",

    Listed in the inventory and the Annex IV report, with its file and line.

Every AI component, with its file.

  • Models

    • openai/gpt-4o-mini
    • meta-llama/Llama-3.1-8B
    • models/local.gguf
  • Agents

    • LangChain AgentExecutor
    • CrewAI Crew
  • MCP servers

    • mcp://prod-postgres
    • mcp://github
  • Guardrails

    • Llama Guard 3
    • Guardrails AI

One model declared. The scan finds the rest.

What the team declared

  • Declared: openai/gpt-4o-minisrc/lib/chat.ts:23

What the scan found

  • Shadow: mcp://prod-postgresinfra/mcp.ts:42
  • Shadow: meta-llama/Llama-3.1-8Bmodels/local.gguf
  • Drift: extract-piilib/pii.ts:17
  • Missing: No guardrailapps/legacy-agent/
  • Governed: openai/gpt-4o-minisrc/lib/chat.ts:23

Run it where you ship.

Each scan publishes the inventory and an Annex IV report, with a CycloneDX export.

  1. Your pipelineA push, or a run of your CI.Triggered
  2. AI-BOM scanModels, data, prompts, agents, MCP servers and guardrails.Scanned
  3. InventoryEach item with its file and line.Flagged
  4. ReportEU AI Act Annex IV, NIST AI RMF, CycloneDX.Published

Start with one repository.

Connect GitHub, GitLab, Bitbucket or Azure DevOps, pick a repository, and the first scan starts.

In detail

Every AI component in the repository.
  • Models

    OpenAI, Anthropic and Google model names, HuggingFace IDs, local GGUF and ONNX weights.

  • Datasets

    Training, fine-tuning, evaluation and RAG corpora, referenced in code or config.

  • Prompts

    Versioned system and user templates shipped in the repository.

  • Agents

    LangChain, LlamaIndex, CrewAI, Semantic Kernel, AutoGen and custom ReAct loops.

  • MCP servers

    The tools your agents call out to.

  • Guardrails

    Llama Guard, NeMo, Guardrails AI, or none at all.

Run it where you ship.

Each scan publishes the inventory and an EU AI Act Annex IV report mapped to Regulation (EU) 2024/1689, with NIST AI RMF tags and a CycloneDX export.

.github/workflows/ai-bom.yml

- name: CybeDefend Security Scan
  uses: CybeDefend/cybedefend-action@v2
  with:
    pat: ${{ secrets.CYBEDEFEND_PAT }}
    project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
    branch: ${{ github.ref_name }}
    break_on_severity: high
Everything it checks

You can’t govern the AI you can’t see. Shadow AI is already in your repos.

Three reasons AI-BOM is the entry-point governance tool, not an afterthought.

  • Discovery first

    Every model, dataset, prompt, agent, MCP server and guardrail surfaced automatically.

  • EU AI Act Annex IV native

    Every Annex IV section has a corresponding emit rule. Article 11 documentation moves from a quarterly project to a CI artefact.

  • NIST AI RMF aligned

    Each component is tagged against the Govern / Map / Measure / Manage functions.

EU AI Act Annex IV evidence. One scan to ship it.

Each scan emits a full compliance report mapped to Regulation (EU) 2024/1689. Hand it to legal, your auditor or your customer's security questionnaire.

Annex IV evidence + NIST AI RMF mapping included in every scan.

  • EU AI Act Compliance Report

    One report per scan, mapped to Regulation (EU) 2024/1689, ready for legal and your auditor.

  • By risk category (Art. 5/6/50)

    Prohibited, High, Limited, Minimal.

Drop it in your pipeline

Add the cybedefend-action to your GitHub workflow, or call the CybeDefend CLI from any other pipeline.

What AI-BOM catches, what it does not.

What exactly does AI-BOM detect?
Models referenced by name (HuggingFace IDs, OpenAI / Anthropic / Google model strings, local .gguf / .onnx weights), datasets referenced in code or config, versioned prompts shipped in the repo, MCP server URLs consumed by your agents, LangChain and LlamaIndex graphs, agent orchestration frameworks (Semantic Kernel, AutoGen, CrewAI, custom ReAct), and guardrails libraries in use (Llama Guard, NeMo, Guardrails AI). Each item lands in the inventory with its source location, version pin, and a heuristic classification.
Is AI-BOM required by the EU AI Act?
Article 11 and Annex IV of the EU AI Act require a technical documentation pack for high-risk AI systems before they enter the EU market. That pack enumerates models, training data sources, intended use, performance metrics, and risk-management measures. AI-BOM produces the evidence in machine-readable form, so the documentation step becomes an export instead of a quarterly project.
How does it integrate into CI/CD?
Add the cybedefend-action to your GitHub workflow, or call the CybeDefend CLI from any other pipeline (GitLab CI, Jenkinsfile, Tekton). The scan runs on every push, the report is published as a build artifact, and the gate exits non-zero when a new prohibited or high-risk component lands without governance documentation.
What is the difference between AI-BOM and SBOM?
SBOM lists software components and CVEs. AI-BOM lists AI components and their AI-specific governance facets: training data origin, fine-tune lineage, prompt versions, agent capability scope, guardrails coverage, residual risk. They are complementary; CybeDefend produces both, and the AI-BOM output is also exportable as CycloneDX so it slots into your existing SBOM tooling.
Does AI-BOM train on our code?
No. Your code is never used to train a model. For a standard scan, the repository is read in a container that is destroyed when the scan ends, and the inventory keeps what it found: component names, versions, locations and risk categories.