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.

[jim-schwoebel]

Love this, thanks for proposing

[ryjen]

A useful way to frame the boundary is that an ASBOM (card) can describe a principal (robot) and its security posture without becoming the authorization decision itself.

The card can say who the robot is, where it keeps its key, how long the key lasts, and whether it normally needs permission before doing something. But the card is not the permission itself.

For example:

“This robot normally needs permission before sending money.”

is useful descriptive, but it does not mean:

“This robot is allowed to send $100 right now.”

The exact action still needs to be authorized when it happens.

A useful separation is:

party
  = identity / actor description

principal posture
  = how the actor operates and holds credentials

authorization
  = whether this exact current action may execute

The four-axis principal decomposition looks useful, especially because it separates attribution, credential custody, credential lifetime, and consent posture instead of collapsing them into something like authenticated: true.

One semantic boundary may be worth making explicit:

principal** can describe identity, credential posture, and authorization/consent configuration, but the BOM declaration itself should not constitute current executable authority for a particular action.**

For example, an ASBOM could accurately declare:

principal:
  attribution: delegated-obo
  credential_storage: os-keychain
  credential_lifetime: short-lived-oauth
  consent_binding: per-action

That is valuable security and incident-response information. But it should not imply that a runtime request is currently authorized merely because the BOM says consent_binding: per-action, or because the referenced principal normally possesses a particular capability.

A useful interoperability test would keep the BOM constant while varying only the runtime authorization result:

same signed ASBOM
same model / harness / tool / principal posture

request A -> authorized -> effect admitted
request B -> not authorized -> effect denied

The BOM remains valid in both cases. The authorization decision is separate, action-specific state.

This distinction also matters for freshness. Credential lifetime and consent mode are useful declarations, but the actual credential may have expired, been revoked, or been narrowed, and the relevant policy state may have changed since the BOM was produced.

There may also be an opportunity to align the identity portion of principal with the CycloneDX 2.0 party model rather than introducing a second independent identity vocabulary. The party model already represents organization, person, system, and persona identities and their roles.

principal could potentially reference a party for who or what the principal is, while retaining the proposed runtime-specific axes for how that principal operates — attribution mode, credential custody/lifetime, and consent binding.

Conceptually:

party
  = identity / actor description

principal posture
  = runtime credential + attribution + consent characteristics

authorization decision
  = whether this exact current action may execute

Keeping those layers distinct would make ASBOM useful as a stable transparency and attestation artifact without accidentally turning it into a reusable authorization token.