Is namespaced properties on formulation.workflow the right carrier for AI-agent provenance?

[tomjwxf]

Question prompted by the growing share of lockfiles that are now generated by AI agents (Claude Code, Cursor, autonomous CI pipelines calling npm install / pip install via tool calls). The resulting BOM records what got resolved. The open question is how to record who (which agent, under which Cedar or similar policy) in a way CycloneDX parsers already understand.

Having read through the 1.6 spec, the primitives already present seem to cover most of it:

• formulation[].workflows[] is the documented home for "how this BOM came to be" (build steps, task types, timing). This fits agent-driven resolution directly; treating the npm install call as a build step is a natural mapping.
• properties[] on workflow entries (and at top level) is a namespace-scoped property bag where vendor-specific metadata rides without extending the spec.
• signature (JSF) already covers cryptographic attestation of BOM contents.

The specific dimension that feels missing, if I am reading correctly, is agent identity + policy digest as vocabulary on workflow entries. Concretely, a workflow entry would carry properties like:

"properties": [
  { "name": "agent.policy_id",       "value": "dev-safe@v3" },
  { "name": "agent.decision",        "value": "allow" },
  { "name": "agent.chain.sequence",  "value": "47" },
  { "name": "agent.chain.prev_hash", "value": "sha256:a8f3..." }
]

Which is already valid CycloneDX 1.6. The question is whether the working group sees value in a small vocabulary convention for this pattern (a reserved namespace or documented property names for agent-attested builds) so multiple tools emit consistent metadata and downstream consumers know how to parse it.

Adjacent prior art I found in existing discussions: #618 (capturing generation environment for reproducibility). The agent-provenance question sits alongside that but narrows specifically to the "who ran this" dimension rather than "on what OS/arch."

Reference implementation, purely to show the shape (NOT a proposed spec change):

https://github.com/ScopeBlind/sb-runtime/tree/main/examples/cyclonedx-integration

That example takes a BOM plus a signed receipt (Ed25519 + JCS, instance of the IETF draft-farley-acta-signed-receipts format) and attaches the receipt via existing CycloneDX 1.6 fields. Output validates against the stock 1.6 schema unchanged. Published as an example, not a format proposal.

What I am asking the working group

1. Does carrying agent-attestation metadata on formulation.workflow.properties feel like the intended use of those fields, or is there a better-fitting structure I am missing?
2. Is there appetite for a small vocabulary convention for agent-provenance properties (reserved namespace, documented names), or is vendor-namespaced (com.scopeblind:...) fine indefinitely?
3. Is this the kind of thing that would land better at the CycloneDX working group meetings rather than here? Happy to take it there instead.

Thanks for the project. The fact that agent-attestation already fits cleanly into existing 1.6 fields is actually the most useful finding from the exercise.

[stevespringett]

I think what you're looking for is being designed by the Blueprints and the Threat Modeling working groups.

I assume your definition of provenance aligns with the OWASP, MITRE, and English dictionary definitions of the word? But I need to clarify since you're referring to formulation. If you're talking about SLSA Provenance-like meaning, then that's different.

In CycloneDX v2.0, you should be able to describe every actor (components, services, humans, organizations, agents, etc) and all of the behaviors and interactions - both observed and declared. If an actor performs a series of behaviors, you'll be able to describe the formulation (the precise steps the actor took) in order to perform their task.

[tomjwxf]

@stevespringett thanks for the pointer, Blueprints and Threat Modeling are the right WGs and glad they are the right home for this.

To clarify which sense of "provenance" I had in mind: closer to the SLSA sense than the OWASP / MITRE / dictionary sense. Specifically, the operationally-useful subset of "who produced this artifact, under what policy, with what evidence, verifiable after the fact by someone who does not trust the producer." My question was narrower than formulation's full scope: not "what steps were taken to produce the BOM" but "who was authorized to take those steps, and can a downstream party cryptographically confirm that authorization without trusting the producer."

The observation that prompted the question: for AI-agent-produced BOMs specifically (lockfiles from npm install where the actor invoking the resolver is an LLM with a policy gate), there is a narrow identity + policy-decision evidence layer that rides well on formulation.workflow.properties today but has no documented vocabulary. SLSA provenance covers the build-platform half; what agent-based workflows add is the per-tool-call authorization decision the policy gate made during the build.

On v2.0 "describe every actor (components, services, humans, organizations, agents, etc) and all of the behaviors and interactions, both observed and declared": that is the right home for this, and the actor plus declared-vs-observed decomposition answers most of what the narrower question was probing. Agent actors with declared policy plus observed decisions is the shape.

Happy to take this to the Blueprints or Threat Modeling WG meetings rather than continuing here. Is the right next step to show up on the WG agenda (or ping the chairs), or submit a discussion note in advance? If there is a meeting agenda URL or chair contact I should loop in on, happy to take it to the right room.

Thanks for the redirect.

[0xddneto]

This maps to AIPOU's recent interop work: keep the agent/work receipt outside the core format, but let the BOM/workflow record carry stable digest-bound references.

AIPOU is not trying to redefine CycloneDX provenance. It records a human/agent work unit with wallet authorization, nonce/replay checks, local hashes instead of raw prompts/outputs, provider/model/client metadata, and an Ed25519 collector signature. Optional validator-approved claims/rewards are a later layer and should not be implied by a BOM field.

For CycloneDX, the useful subset seems to be:

• actor/agent identity: who or what produced/modified the artifact;
• policy/authority fact: what pre-action permission existed;
• work receipt reference: external workReceiptId, digest, URI, and validation status;
• evidence boundary: whether the fact is chain-derived, issuer-asserted, attested point-in-time, etc.

AIPOU's external evidence link prototype is scheme-neutral and uses SHA-256 digests so protocols can reference each other without absorbing trust models:
https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/external-evidence-links.md

My instinct: CycloneDX should not store the whole AI work receipt unless it becomes native vocabulary; it should carry an external evidence reference with digest, scheme, and validation semantics.