💡 Agent Configuration Runtime Provenance & CI Session SBOM Standard

[github-actions[bot]]

Summary

Capture a "software bill of materials" for the agent configuration active during each CI run — model version, skill set, MCP server list, AGENTS.md hash, CLAUDE.md hash, and permission grants — and attach it as a structured artifact. This provides the post-incident forensic trail needed to answer "what agent configuration was active when this change was made?" and supports compliance evidence for AI-assisted code changes. Unlike the existing lockfile idea (#1027, which detects configuration drift), this captures what was actually active at runtime.

Market Signal

Anthropic designated Fable 5.1 as a Covered Model on August 31, 2026, changing the data boundary for commercial deployments — demonstrating that model version matters for compliance, not just capability. The AGENTS.md specification (Linux Foundation Agentic AI Foundation, 60K+ open-source repos) is becoming the standard for declaring agent configuration, but no standard exists for capturing what was actually active at runtime. GitHub's Artifact Attestation feature provides the infrastructure for attaching cryptographically signed provenance data to workflow outputs — the SLSA framework extended to agent configurations. The Cloud Security Alliance research on Claude Code Action prompt injection (2026) recommends runtime provenance capture as a defense-in-depth layer for AI-assisted CI.

User Signal

• Idea 💡 Agent Configuration Content-Addressed Lockfile & Drift Detection Standard #1027 (Agent Configuration Content-Addressed Lockfile) declares what the configuration SHOULD be and detects drift. But drift detection answers "has the config changed?" — it doesn't answer "what config was running during PR feat: implement issue #1063 — Repin dev-lead caller stub: dev-lead/v1-ring0 -> dev-lead/v139-ring0 (orphaned channel family, 152 commits behind, #1592) #1087?"
• Bug canary gate counts engine-quota failures (Claude 429 session limit + dead Copilot fallback) as cum_fail — dev-lead next->ring0 is on a false REGRESSION; blocks #1592 #1057 (engine-quota failures miscounted as regressions) had no record of which Claude model version or configuration was active during the affected runs, complicating root cause analysis.
• The org tracks 7+ agent types, each potentially using different model versions, skills, and permissions. When a model migration occurs (e.g., Claude 4.5 → 4.6, or the Fable 5.1 data-boundary change), there's no way to audit which runs used which model after the fact.
• Idea 💡 Artifact Attestation and SLSA Build Provenance Org-Wide Enforcement #587 (Artifact Attestation and SLSA Build Provenance) provides the signing infrastructure but doesn't define an agent-configuration-specific attestation schema.

Technical Opportunity

The claude-code-action wrapper already mediates all Claude invocations and has access to the full configuration at runtime. A post-run step could: (1) hash AGENTS.md, CLAUDE.md, and any SKILL.md files; (2) capture the model ID from the API response; (3) list active MCP servers; (4) record granted permissions; and (5) emit a structured JSON artifact. GitHub's Artifact Attestation (SLSA) could sign this for tamper-evidence. Crucially, the SBOM schema should be auto-derived from the runtime state — not manually maintained — so new skills, MCP servers, or model versions appear automatically without schema updates.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires a post-run step in the claude-code-action wrapper. The runtime introspection (hashing config files, capturing model ID) is straightforward. The complexity is in defining a stable-but-extensible schema and integrating with Artifact Attestation for signing.
Impact	high	Provides the forensic trail for every agent-assisted change in the org. Enables compliance evidence for model-version tracking (critical post-Fable 5.1 data-boundary change). Supports anomaly detection: if an agent suddenly uses a different model or MCP server than expected, the SBOM records it.
Urgency	med	No active blocker, but the need increases with each model version migration and each new agent type added. The Fable 5.1 data-boundary change (Aug 31, 2026) makes model-version tracking a compliance concern today, not just a nice-to-have.

Adversarial Review

Strongest objection: The org has 7 agent types running across 3-4 repos. The maintenance burden of keeping the SBOM schema aligned with evolving agent configurations (new skills, new MCP servers, new model versions) is ongoing. If the schema falls behind, the SBOMs become incomplete and misleading — a false sense of security.

Rebuttal: The SBOM schema should be auto-derived, not manually maintained: the post-run step introspects the actual runtime state (hash the config files that exist, capture the model version from the response, list MCP servers from the connection log) rather than declaring a schema to validate against. This is the key difference from lockfile-based approaches (#1027). Auto-derivation means new skills or MCP servers appear in the SBOM automatically without schema updates. The schema defines the structure (field names, types), not the content (which files, which servers) — and the structure is stable even as content evolves.

Suggested Next Step

Define a minimal SBOM schema: {agent_type, model_id, model_version, agents_md_sha256, claude_md_sha256, skill_files[], mcp_servers[], permissions_granted[], run_url, timestamp, workflow_ref}. Implement a proof-of-concept post-run step in the claude-code-action wrapper that emits this as a JSON artifact attached to the workflow run. Validate on one agent type (dev-lead) for two weeks, then extend to the fleet. Phase 2: integrate with Artifact Attestation (#587) for cryptographic signing.