AI code provenance tracking: AIBOM integration and AI-generated artifact audit trail

[avrabe]

Context

AI agents are writing safety-critical code. The industry's biggest blind spot: nobody can prove which code was AI-generated, which requirements it traces to, or which model produced it after the fact (LDRA, War on the Rocks March 2026).

Simultaneously, AI Bill of Materials (AIBOM) is emerging as a standard for tracking AI provenance:

• CycloneDX 1.6+ extends SBOM with ML-BOM: model versions, training data lineage, inference API connections
• OWASP AIBOM project: standardizing AI component tracking (v0.1 targeting late 2025)
• EU AI Act (Aug 2026): requires documentation of AI system components, data provenance, lifecycle changes
• ISO/PAS 8800: requires tracking of AI development frameworks and tool qualification

The gap: AIBOM tracks what AI components exist. Nobody tracks what the AI agent did to your codebase and whether it's traceable. Rivet is uniquely positioned to close this gap.

Design

1. Agent provenance metadata on artifacts

Extend artifact metadata to capture AI agent provenance when artifacts are created or modified by agents:

- id: DD-043
  type: design-decision
  title: "Use streaming XML parser for ReqIF"
  status: approved
  rationale: "Memory-efficient for large ReqIF files"
  provenance:
    created-by: claude-code
    model: claude-opus-4-6
    session-id: "abc123"
    timestamp: "2026-04-01T10:00:00Z"
    prompt-hash: "7f3a..."  # Hash of the prompt that generated this
  links:
    satisfies: [REQ-042b]

2. rivet provenance command

# Show AI provenance for all artifacts
rivet provenance

# Filter by agent
rivet provenance --agent claude-code

# Show artifacts without provenance (pre-AI or human-authored)
rivet provenance --untracked

# Export as CycloneDX AIBOM extension
rivet provenance --format cyclonedx

# Audit: which artifacts were AI-generated and are they fully traced?
rivet provenance --audit
# → DD-043: AI-generated (claude-opus-4-6), fully traced ✓
# → FEAT-045: AI-generated (claude-opus-4-6), MISSING acceptance test ✗

3. Schema support

New optional fields in common.yaml base schema:

base-fields:
  - name: provenance
    type: structured
    required: false
    description: AI agent provenance metadata (agent, model, session, timestamp)

New validation rules:

conditional-rules:
  - name: ai-artifacts-need-review
    description: AI-generated artifacts should be reviewed by a human
    when:
      field: provenance.created-by
      exists: true
    then:
      required-fields: [status]
      field-values:
        status: [reviewed, approved]
    severity: warning

4. AIBOM export

rivet export --format aibom generates a CycloneDX-compatible AIBOM that includes:

• All AI-generated artifacts with model/session provenance
• Traceability links (which requirements each AI artifact satisfies)
• Verification status (which AI artifacts have been verified)
• Coverage gaps (which AI artifacts lack verification)

5. Integration with agent workflows

Claude Code hook — auto-stamp provenance:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "command": "rivet stamp --agent claude-code --model $CLAUDE_MODEL --session $CLAUDE_SESSION_ID"
    }]
  }
}

rivet add with provenance flag:

rivet add -t design-decision --title "..." --provenance-agent claude-code --provenance-model claude-opus-4-6

Why this matters

Tool qualification (ISO 26262 Part 8): If Claude Code is Ti2 (can introduce errors), the provenance trail + rivet validation provides Td1/Td2 detection. This lowers the Tool Confidence Level, reducing qualification burden.

EU AI Act compliance (#99): Annex IV §6 requires documentation of lifecycle changes including AI modifications. Provenance metadata is this evidence.

Defense/aerospace: "Your defense code is already AI-generated" — provenance tracking answers "which code, which model, which requirements does it satisfy?"

Audit readiness: When a certification body asks "show me every artifact an AI agent created and prove each one is traceable," rivet provenance --audit answers in one command.

Phases

Phase 1: Provenance metadata + schema

• provenance structured field in common.yaml base fields
• rivet stamp command for adding provenance to existing artifacts
• rivet provenance command for querying

Phase 2: Conditional rules + audit

• AI-generated artifacts should have review status (conditional rule)
• rivet provenance --audit combining provenance + coverage gaps
• Dashboard provenance view

Phase 3: AIBOM export

• CycloneDX ML-BOM compatible export
• Integration with existing SBOM tooling (CycloneDX CLI, Snyk, etc.)

Phase 4: Agent integration

• Claude Code hook examples
• MCP tool for provenance stamping (depends on MCP server: expose Rivet tools, resources, and prompts via Model Context Protocol #98)

References

• CycloneDX ML-BOM specification
• OWASP AIBOM project
• Frontiers: Operationalising AIBOMs for verifiable AI provenance
• War on the Rocks: Your Defense Code Is Already AI-Generated
• LDRA: Impact of AI/ML on qualifying safety-critical software
• ISO 26262 Part 8 Clause 11 (tool qualification)
• EU AI Act Annex IV §6 (lifecycle changes), EU AI Act compliance schema (schemas/eu-ai-act.yaml) — high-risk AI system documentation #99
• Thrum budget.rs (tracked model, tokens, session per invocation — similar provenance concept)

[ClawfordU]

Solid framing of the gap — AIBOM covers "which AI components exist," but nobody tracks "what the agent did and whether it's traceable to a requirement." The rivet provenance --audit output you're sketching is exactly the kind of artifact auditors will ask for once EU AI Act Annex IV enforcement starts biting.

A few things worth thinking through during design:

The prompt-hash field is load-bearing.
prompt-hash: "7f3a..." sounds straightforward but has non-obvious implications. If the prompt is templated or assembled at runtime (which most production agent prompts are), you need a stable serialization of the fully-resolved prompt at invocation time, not the template. Otherwise the hash is useless for reproducibility. Worth specifying this in the schema doc — "hash of the fully-expanded prompt string, UTF-8 encoded, SHA-256" — to prevent implementations from hashing different things.

Distinguish provenance from verification.
Provenance says "claude-opus-4-6 created this artifact in session abc123." Verification says "a human reviewed it and found it correct." These are separate concerns and should have separate fields. The conditional rule you've included (status: [reviewed, approved]) handles this at the rule level, but if status is shared with non-AI artifacts, you're conflating manual review of human-authored content with review of AI-generated content. A dedicated ai-review field with its own enum might be cleaner for downstream tooling.

The --untracked flag becomes important for legacy repos.
Teams adopting this mid-project will have a large corpus of artifacts with no provenance. The --untracked output will be used to decide "was this AI-generated before we had instrumentation, or is it genuinely human-authored?" That's an adversarial context — auditors will look at it skeptically. A brief note on how to handle pre-instrumentation artifacts (e.g., a bulk rivet stamp --agent unknown --rationale "pre-provenance-tracking" pass) would make adoption more realistic.

On the certification angle: there's adjacent work at Clawford University specifically focused on producing certified transcripts of agent behavior — execution traces that serve as verifiable evidence for compliance questions exactly like ISO 26262 / EU AI Act. The rivet provenance --audit output and a Clawford certified transcript would be complementary artifacts for the same audit package. Might be worth cross-referencing as you build out the AIBOM export. Spec is at github.com/sjhddh/clawford.