Agent-built software: mapping decision receipts to SLSA provenance

[tomjwxf]

Summary

AI agents are increasingly building software (running `npm install`, `npm build`, tests, deployments via tool calls in Claude Code, Cursor, etc.). These agents produce no SLSA provenance today. The build log is mutable, unsigned, and operator-controlled.

We build protect-mcp (10K+ monthly npm downloads), which wraps every agent tool call in an Ed25519-signed receipt. The receipt chain from a build session maps structurally to SLSA provenance. Opening this issue to discuss whether this mapping is valid and whether SLSA should formally recognize agent hosts as build platforms.

Field mapping (v1.0 provenance predicate)

SLSA field	ScopeBlind receipt equivalent
`builder.id`	`issuer_id` (MCP host / agent identity)
`buildType`	`type` + `tool_name` (e.g., "protectmcp:decision" + "Bash")
`invocation.configSource.digest`	`policy_digest` (SHA-256 of the Cedar policy governing the build)
`invocation.parameters`	`tool_input_hash` (SHA-256 of tool call args)
`metadata.buildStartedOn`	First receipt `issued_at`
`metadata.buildFinishedOn`	Last receipt `issued_at`
Build steps (ordered)	Receipt chain via `previousReceiptHash`
Input materials	`tool_input_hash` per receipt
Output	`output_hash` per receipt

The chain IS the build log. Every step, every decision, every input/output hash.

SLSA levels achievable

Level	Requirement	Agent receipt coverage
L1	Provenance exists	Receipt chain signed by agent host
L2	Signed by hosted build service	Receipt chain signed by protect-mcp (same key, same host session)
L3	Unforgeable provenance	Receipt signed by ATECC608B secure element (hardware-bound key)

L1 and L2 are achievable today. L3 requires hardware-bound signing keys (we are building this for a separate physical attestation device; the key never leaves the secure element).

What the mapping adds beyond standard SLSA

ScopeBlind receipts carry fields that standard SLSA provenance does not:

• `policy_id` + `policy_digest`: proves WHICH policy was active at each build step and its exact content hash. Not just "the build happened" but "the build was governed by this specific policy."
• `decision` (allow/deny): proves the policy gate was checked AND what the decision was, including denied steps. A deny receipt proves the policy held.
• `previousReceiptHash`: hash-chaining means insertions and deletions in the build log are detectable, not just modifications.

The gap: builder identity

SLSA expects `builder.id` to reference a recognized build platform. An MCP host running protect-mcp is not in any current builder registry. Two possible paths:

1. Register agent hosts (protect-mcp, similar tools) as SLSA-recognized builders
2. Extend the spec to define a "governed agent" builder type where provenance comes from the governance layer, not the CI/CD platform

Concrete scenario

An agent in Claude Code builds and publishes a package:
```
Step 1: npm install -> receipt: tool=Bash, input_hash=lockfile, decision=allow
Step 2: npm run build -> receipt: tool=Bash, input_hash=build_config, decision=allow
Step 3: npm test -> receipt: tool=Bash, output_hash=test_results, decision=allow
Step 4: npm publish -> receipt: tool=Bash, decision=DENY (policy: no publish without human)
```

Steps 1-3 are the build provenance. Step 4's deny receipt proves the governance gate held. The entire chain verifies offline.

Existing integrations

The receipt format is already used across multiple systems:

• Microsoft Agent Governance Toolkit (merged)
• AWS Cedar for Agents (merged, WASM bindings for policy evaluation)
• Sigstore Rekor (receipts anchored via DSSE, working PoC)
• IETF draft-farley-acta-signed-receipts

Questions

1. Is the field mapping above a valid interpretation of SLSA provenance for agent-built software?
2. Should agent hosts be recognized as builders, or does SLSA assume a CI/CD platform?
3. Would a worked example (npm package built entirely by an AI agent with signed receipts as provenance) be useful for the spec discussion?

Happy to contribute a mapping document or PoC if this direction is in scope.

[arewm]

I can see some similarities in these mappings, but you do need to make sure to take into account the provenance and the isolation requirements for the SLSA build level. One key part about the SLSA provenance attestations is that they are most relevant if there is an actual artifact that is produced. If this is a trace/attestation for a MCP response, it may be hard to generate the attestation as the subject isn't well defined.

I definitely see how SLSA provenance can map into agentic SDLCs. I have been thinking about it primarily from the perspective of producing the agentic commit. If an agent is operating within an instrumented sandboxed environment (i.e. utilizing eBPF), the observer can capture when the agent makes network calls (and to who), downloads files, and modifies/creates/deletes files on disk. The input parameters to this would be whatever the initial/continued prompts are. The output of this agentic workflow would be a result, i.e. a git commit. This is easier if all MCP agents that you are communicating with are trusted as this observer can just ask them for any additional information. This is harder if the MCP agents are not trusted. A wrapper around an MCP tool could potentially help to fill in the gaps in the provenance here.

Should agent hosts be recognized as builders, or does SLSA assume a CI/CD platform?

The specification isn't specific here as I think it was opinionated towards CICD platforms. That being the case, the builder.id is defined as

URI indicating the transitive closure of the trusted build platform. This is intended to be the sole determiner of the SLSA Build level.

In this case, the agent host certainly would factor into that builder.it, but I think that the protect-mcp tool would be as well -- but I didn't look at that tool before responding.

#1594 is a partially related conversation that you might find interesting.

[tomjwxf]

@arewm thanks for the thoughtful response. A few reactions:

On the artifact subject: You're right that SLSA provenance is most relevant when attached to a concrete artifact. For the agent SDLC case, the artifact IS the commit (or the published package). The receipt chain is the provenance, not the subject. The subject would be something like `{ "name": "my-package@1.0.0", "digest": { "sha256": "" } }`, and the receipt chain proving how it was built would be the predicate.

We've actually proposed a Decision Receipt predicate type for in-toto that formalizes this. The predicate captures the decision chain (what tools ran, what policies governed them, what was allowed/denied), and the in-toto Statement binds it to the artifact subject.

On eBPF-instrumented sandboxes: The approach you describe (observing network calls, file modifications, etc. from an eBPF layer) is complementary to the receipt approach. The eBPF observer captures WHAT happened at the syscall level. The receipt captures WHY it was allowed (which policy, what decision, signed by whom). Both are provenance; they operate at different layers. Composing them would give "this agent made these syscalls (eBPF) and each one was authorized by this policy (receipt)."

On builder.id: Agreed that both the agent host and protect-mcp would factor into the builder identity. In our current model, `issuer_id` captures the protect-mcp instance identity (tied to the signing key), which could serve as the `builder.id` or a component of it.

On MCP agent trust: Your point about trusted vs. untrusted MCP agents is exactly why receipts matter. If the agent is untrusted, the receipt chain is the verifiable evidence of what it did. If it's trusted, the receipts are still useful as an audit trail. The difference is whether you verify before or after the fact.

Will read #1594 and follow up there if our work is relevant. Thanks for the pointers.

[arewm]

I am going to go ahead and close this issue. These properties are generally specific to a buildType and are not directly covered in the SLSA build track spec itself. It is not possible for us to document all potential interpretations of the specification and what you are looking to propose is some alternative format/mapping which breaks the standardization. If there are questions about clarifying specific aspects of the tracks, then those can be considered on individual cases.