Discover — the AI Bill of Materials
Every scan builds an AI-BOM: a live inventory of how AI is wired into your code. It answers the question every security leader is now asking — "what AI is actually in our engineering estate, and which of it did we never approve?"
Added value
| Without Discover | With Discover |
|---|---|
| Spreadsheets of “known” AI tools | Automatic inventory from every scanned repo |
| Shadow MCP / keys found in incidents | Shadow AI counted and named before the incident |
| Manual EU AI Act / NIST inventory | Exportable AI-BOM (API + CycloneDX 1.6 ML-BOM) |
| Agents as tribal knowledge | Agents as linked artifacts (code · prompts · tools · owner) |
What Unveilr discovers
| Asset kind | What it is | Detected from |
|---|---|---|
| AI tools | Copilot, Cursor, Claude Code, Aider, Continue, Windsurf, Cline | .cursor/, .github/copilot-*, CLAUDE.md, .claude/, .aider*, .continue/, … |
| MCP servers | Model Context Protocol servers your agents use | mcp.json, .mcp/, mcpServers blocks in configs |
| Agents | Autonomous agents wired into the repo | agent configs / SDK usage |
| Model references | claude-*, gpt-*, Bedrock/OpenAI/Anthropic model IDs | source + config |
| Prompt files | System prompts and instruction files | prompts/, *.prompt, system_prompt* |
| AI services | Hosted providers/endpoints (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex, Groq, Cohere, …) | endpoint URLs, cloud IaC (Bedrock/SageMaker/Azure OpenAI/Vertex) |
| AI keys | Provider credentials referenced in config | .env, CI YAML, Dockerfiles (OPENAI_API_KEY, ANTHROPIC_API_KEY, …) |
| Dependencies | Packages — including hallucinated and typosquatted ones | package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml |
Shadow AI
Anything discovered in a repo that isn't centrally governed is shadow AI — an unapproved MCP server, an agent with tool access, a provider key no one signed off on. Unveilr flags these so you can bring them under governance instead of banning experimentation.
Discovery reads usage signals — env-var names, endpoints, resources,
config. It records the fact that (say) OPENAI_API_KEY is used; it does not
capture or upload the secret value. Leaked secret values are caught separately
by Guard.
See it — per repo (developer loop)
unveilr scan
AI-BOM (10 assets)
ai_tool 1 · mcp_server 1 · model_ref 1 · ai_service 3 · ai_key 5 · dependency 6
unveilr scan --json emits the full inventory for pipelines and the IDE
extension. No account required — see Developer experience.
See it — across your whole org
Upload scans from every repo (unveilr scan --upload or CI upload), then:
- AI Inventory (
/inventory) — org-wide rollup by kind, providers, shadow count - Repositories (
/repos) — per-repo BOM and scan history - Identity Graph (
/identity) — how agents, tools, and identities connect - Agents (
/agents) — discovered agents ready for Govern
Console path: /inventory
Capture: asset counts by kind, provider breakdown, shadow-AI highlight; show
Download CycloneDX if visible.
Story it tells: “Board-ready AI inventory, generated from engineering reality.”
Console paths: /repos and /repos/[id]
Capture: list with finding counts; detail with AI-BOM table + ingest / CycloneDX.
Story it tells: “Every repo is a governed AI unit of work.”
Console path: /identity
Capture: graph linking agents ↔ MCP tools ↔ identities.
Story it tells: “Blast radius is visible, not guessed.”
The same data is available from the API:
curl -H "authorization: Bearer $TOKEN" https://your-instance/v1/aibom
curl -H "authorization: Bearer $TOKEN" \
https://your-instance/v1/aibom/cyclonedx # org-wide CycloneDX 1.6
curl -H "authorization: Bearer $TOKEN" \
https://your-instance/v1/repos/$REPO_ID/aibom/cyclonedx
Why this matters
- Regulatory inventory — EU AI Act and NIST AI RMF expect an AI system inventory. This is it, generated automatically.
- Shadow-AI governance — see what developers adopted before it becomes an incident.
- Foundation for Guard / Govern / Prove — you can only govern and prove control over AI you can see.