Skip to content

Agentic System BOM

Why this page exists. Enterprise buyers can approve agentic remediation faster when they can inspect the system like a supply chain: which agents exist, what they can touch, which MCP connectors they use, which policies constrain them, and which evidence proves current state.

The product bet

SecurityRecipes is strongest as the secure context layer between agents and enterprise remediation work. The existing control plane tells an agent what it may do. The gateway policy enforces that scope. The identity ledger binds action to non-human principals. The readiness scorecard decides what can scale.

The Agentic System BOM makes that system inspectable. It turns the control artifacts into a single generated inventory that an AI platform team, GRC reviewer, procurement security team, or acquirer can load without reading the whole site.

That matters because agentic systems are not one binary. They are a changing composition of models, prompts, skills, workflows, tools, MCP servers, policies, identities, evidence, and evals. A serious buyer will ask:

  • Which agents and identities are part of the system?
  • Which MCP namespaces and connectors can they reach?
  • Which workflows are scale-ready or pilot-guarded?
  • Which source artifacts prove the current state?
  • Which changes force review before the system can keep running?

The BOM answers those questions in one machine-readable file.

What was added

The BOM layer lives in three artifacts:

  • data/assurance/agentic-system-bom-profile.json - the source profile for positioning, standards alignment, required component types, and drift triggers.
  • scripts/generate_agentic_system_bom.py - a dependency-free generator and validator with --check mode for CI drift detection.
  • data/evidence/agentic-system-bom.json - the generated BOM that joins workflow, policy, identity, connector trust, assurance, red-team, and readiness evidence.

Run it locally from the repo root:

python3 scripts/generate_agentic_system_bom.py
python3 scripts/generate_agentic_system_bom.py --check

The local MCP server exposes the same bundle through recipes_agentic_system_bom.

What is inside the BOM

SectionPurpose
bom_summaryCounts for workflows, agent classes, identities, MCP namespaces, connectors, evidence, evals, drift triggers, and readiness decisions.
components.workflowsPer-workflow BOM rows with agents, identities, MCP namespaces, policy decisions, readiness score, red-team coverage, and evidence counts.
components.agent_classesAgent-host inventory with workflow coverage and model-change controls.
components.agent_identitiesNon-human identity contracts, delegated scopes, explicit denies, runtime contracts, and owners.
components.mcp_connectorsMCP namespaces, trust tiers, transports, access modes, data classes, required controls, evidence counts, and owners.
components.policy_componentsControl-plane, gateway, identity, and readiness policy surfaces.
components.evidence_artifactsSource-controlled and generated artifacts with canonical SHA-256 hashes.
components.knowledge_sourcesPrompt, remediation, control-plane, and assurance roots used by agents and generators.
components.evaluation_drillsWorkflow-specific red-team drills tied to attack families and expected policy decisions.
update_triggersThe changes that force BOM regeneration or manual review before scale.

Drift triggers

The BOM treats these changes as first-class inventory events:

TriggerWhy it matters
agent_changedAgent hosts, tool authority, or runtime sandboxes can change behavior without workflow text changing.
model_changedModel family, context window, reasoning mode, budget controls, and provider contracts affect safety and cost.
mcp_server_changedMCP endpoints, transports, auth models, and capabilities are production control surfaces.
tool_changedTool descriptions and schemas are prompt-layer input and supply-chain surface.
policy_changedGateway defaults, gate phases, approvals, branch scope, and kill signals define enforcement.
identity_contract_changedDelegated authority, explicit denies, token rules, and reviewer pools define blast radius.
red_team_scenario_changedEval coverage is part of the promotion decision, not a one-time test.
readiness_model_changedScore weights and thresholds decide what can scale.

Industry alignment

The BOM is mapped to current primary references:

How to use it

For AI platform intake, start with bom_summary and components.workflows. They show which workflows are scale-ready, pilot-guarded, or blocked, plus the agents and MCP namespaces involved.

For access recertification, filter by agent_class or namespace through MCP:

recipes_agentic_system_bom(agent_class="codex")
recipes_agentic_system_bom(namespace="repo.contents")
recipes_agentic_system_bom(workflow_id="vulnerable-dependency-remediation")

For procurement or diligence, attach the BOM with the assurance pack, gateway policy, connector trust pack, identity ledger, red-team drill pack, and readiness scorecard. The BOM is the inventory; the other packs are the proof behind each row.

For CI, run the generator in --check mode after every workflow, policy, connector, identity, red-team, readiness, or assurance change. If the BOM is stale, the build should fail before the site publishes.

CI contract

The generator fails if:

  • Source artifact hashes drift from generated evidence.
  • Required component lists are missing or empty.
  • A workflow references an MCP namespace without connector trust.
  • A workflow namespace lacks a gateway policy decision.
  • A default agent lacks an identity contract.
  • An active workflow has too few red-team drills.
  • Required drift triggers are missing.
  • The checked-in BOM is stale in --check mode.

That is the enterprise-ready bar: the inventory changes when the system changes, and the site cannot claim inspectability with stale evidence.

See also