Proposing ASBOM (Agentic-System Bill of Materials) — new CycloneDX BOM type + principal field

[mhupfauer]

Proposing a new CycloneDX BOM type — Agentic-System Bill of Materials (ASBOM) — alongside SBOM, ML-BOM, SaaSBOM, CBOM, HBOM, OBOM, and MBOM. ASBOM inventories the runtime composition of an agentic AI deployment: model + harness + skills + MCP servers + runtime + the identities under which each part executes. The schema addition this requires is one new field (principal).

Why a new BOM type, not just a profile

The agentic-AI ecosystem has rapidly moved to a place where capabilities (SKILL.md packages, MCP servers, plugins) are installable artifacts, hosts (Claude Code, Cursor, Gemini CLI, GitHub CLI) load them dynamically, and operating systems (Windows 11 Agent Workspace) now expose dedicated agent principals. The running composition of these parts — which model, in which harness, with which skills, in which runtime, under which credentials — is what determines an agentic system's effective authority and blast radius. It is the unit operators must audit, sign, and respond to in an incident.

None of the existing BOM types capture it:

• ML-BOM describes the model and its training lineage.
• SaaSBOM describes service surfaces, endpoints, and data flows.
• SBOM describes installed software components.
• None describe the running stack of identities — which is the level where agentic-AI governance, attestation, and incident response actually happen.

ASBOM is that BOM type. It is expressible entirely in CycloneDX 1.7 primitives (compositions, formulation.runtimeTopology, declarations, services.trustZone, components.type=machine-learning-model/platform/application) with one schema addition — the principal block proposed below.

The principal field (the one schema addition)

Today services.authenticated: bool + services.trustZone: string collapses four orthogonal axes into a single boolean. The proposed principal block separates them:

1. Attribution mode — none, delegated-ambient (skill uses host's gh auth), delegated-obo (RFC 8693 token exchange), pat (long-lived bearer), service-principal, agent-account-os (e.g., Win11 Agent Workspace). Determines who the downstream audit log records as actor.
2. Credential storage — none / in-memory / env-var / file / os-keychain / hardware-bound / broker. Determines exfiltration and off-device replay risk.
3. Credential lifetime — session / short-lived-oauth / long-lived-pat / perpetual. Determines duration of compromise.
4. Consent binding — none / per-grant / per-session / per-action. Determines whether a prompt-injected agent action is also a consented action.

Real systems mix these axes — e.g., an MCP server can run as a service principal (axis 1) holding short-lived OAuth tokens (axis 3) stored in OS keychain (axis 2) with per-action consent (axis 4). Conflating them loses the information operators need.

Worked diff in the draft shows two MCP servers that look identical today (authenticated: true, trustZone: internal) but resolve to wildly different governance postures once principal is populated — one is delegated-OBO with DPoP-bound short-lived tokens in OS keychain; the other holds a perpetual PAT in an env var.

The principal field is the motivation for ASBOM, but is itself generally useful for any composed system where components execute under distinct identities (CI pipelines with secrets, serverless function chains, multi-tenant SaaS). The primitive is not AI-specific; the motivating domain is.

Why this is the right moment

CycloneDX 1.7's extension of formulation to "any referenceable object … including the BOM itself" (description updated in commit f315e00) gives the right structural primitive for describing how an agentic system was assembled. declarations (with first-class assessors[].thirdParty) gives the third-party attestation surface. compositions with JSF signature gives the unit-of-governance. The pieces are in place; ASBOM is the opinionated capability that ties them to the agentic-AI domain.

Drafts

• ASBOM v0.1 specification — conformance rules, component taxonomy, composition pattern, attestation, signing, property-bag fallback
• Proposal: principal field — JSON Schema fragment, backwards-compat analysis, full four-axis decomposition, non-repudiation framing, worked diff examples
• Worked example ASBOM — valid CycloneDX 1.7: Claude Code + skill + MCP server + Win11 Agent Workspace, with signed fleet-admin and registry-operator attestations

Related work

• Blog post motivating the broader argument: The registry is the control plane
• Reference implementation seed — policy-aware skill install CLI that is the natural ASBOM producer at install time: vercel-labs/skills#1254

Asks

1. Is "ASBOM" the right framing, or should this land as a profile on top of existing BOM types? (My read: new BOM type, because the domain is distinct enough that operators need a recognizable category — but happy to be argued out of it.)
2. Is the four-axis decomposition for principal the right grain, or are some of these axes better collapsed / expanded?
3. Where should principal attach — component only, service only, both, or via definitions for reuse?
4. If accepted as a BOM type, should the ASBOM specification live in this repo (as Authoritative Guide / capability page) or as a downstream maintained spec?

Happy to split this into smaller proposals (principal field alone, ASBOM capability brand alone, axes as separate enums) if that's easier to land incrementally.