Proposal: SLSA levels for AI agent deployments

[razashariff]

SLSA defines supply chain integrity levels for software artifacts. AI agents introduce new supply chain risks:

1. Agent code provenance -- which developer built this agent? Is the code signed?
2. MCP server integrity -- are the tools the agent uses verified and pinned?
3. Model provenance -- which model version is the agent using? Has it been tampered with?
4. Configuration integrity -- have the agent's permissions, spend limits, or trust levels been modified?

Proposed SLSA Agent Levels:

• Agent L0: No provenance. Agent deployed from unknown source.
• Agent L1: Agent code is signed. MCP tool definitions are hashed.
• Agent L2: Agent built in CI with signed provenance attestation. Tools pinned with SHA-256.
• Agent L3: Agent built in isolated environment. All components (code + tools + model + config) have SLSA L3 provenance. Cryptographic identity bound to build attestation.

This extends SLSA from software artifacts to autonomous agent systems.

Reference: OWASP MCP Security Cheat Sheet Section 7 covers tool definition pinning via cryptographic hashes.

[lehors]

Hello @razashariff and thank you for the proposal. If you can, I suggest you add an entry to the agenda and join the call on Monday to discuss this further.

[arewm]

@razashariff , what do you consider an AI agent in this context? Is this idea for the development of fully encapsulated agents (i.e. trained models) or for agent definitions as has become popular to change the behavior of LLMs by informing their context?

[razashariff]

Good question. Both, but the primary focus is on agent definitions and their runtime behaviour -- the MCP servers, tool configurations, and trust credentials that shape what an AI agent can do.

In practical terms:

1. Agent definitions (MCP tool configs, server manifests, tool descriptions) -- these need attestation because they directly control agent behaviour. A tampered tool description is a prompt injection vector. SLSA-style provenance for MCP server packages would verify that the server you install is the one the author published.

2. Runtime agent identity -- agents making API calls or tool calls need cryptographic identity credentials that can be verified by the receiving service. This is what our IETF draft (draft-sharif-mcps-secure-mcp) addresses with per-message ECDSA signing.

3. Trained models -- also relevant but further upstream. Model file signing handles ECDSA signing of weights for integrity verification.

The gap in SLSA today is that it covers software supply chain but not the agent supply chain. An MCP server installed via npm has SLSA provenance for the package, but nothing attesting to the safety of its tool definitions, the integrity of its runtime behaviour, or the identity of agents using it.

[razashariff]

Thanks Arnaud. Unfortunately Monday is a bank holiday here in the UK so I won't be able to join the call. Happy to sync early the following week if that works, or I can add a more detailed write-up to the agenda ahead of time so the group can discuss without me needing to be live.

To give more context for the group:

The core gap is that SLSA currently attests to the provenance of software artifacts (who built it, how it was built, what inputs were used). AI agents introduce a new category of supply chain risk that sits above the artifact level:

1. Tool definition integrity -- an MCP server's tool descriptions are fed directly into LLM context. A tampered description is a prompt injection vector. There have been 30+ CVEs filed against MCP implementations in 2026 alone, many exploiting this exact surface.

2. Agent identity and trust -- when an agent calls an API or another agent, there is no standardised way to verify who the agent is or what trust level it holds. Our IETF draft (draft-sharif-mcps-secure-mcp) proposes per-message ECDSA signing to address this.

3. Configuration drift detection -- an agent can be registered with a valid identity but have its system prompt, tool list, or model version silently changed after registration. Attestation at deployment time is not enough -- continuous verification is needed.

4. Quantization and deployment chain -- a model file (e.g. GGUF) may be quantized from a source model, but there is no attestation linking the quantized artifact back to its source. Our IETF draft (draft-sharif-ai-model-lifecycle-attestation) covers the full chain from training data to inference.

SLSA levels for AI agents could follow a similar graduated model: L0 (no provenance), L1 (signed agent manifest), L2 (signed + build provenance), L3 (signed + provenance + continuous integrity verification).

Happy to prepare a more detailed proposal document if that would be useful for the group.

[piiiico]

MCP server integrity (your point 2) is the most immediately actionable vector here, and existing scan data gives it concrete shape.

We recently ran static analysis across 12 public MCP server repos — including all official Anthropic reference servers and popular community servers (database connectors, browser automation, search). Findings:

• 100% finding rate — every single repo had at least one security finding
• 46 command execution patterns using spawn()/exec() instead of shell-safe execFile()
• 7 hardcoded credentials in production code — not test files, production source
• 0 repos with security scanning in CI/CD

The absence of CI scanning is the key SLSA gap: none of these servers have provenance attestations for their security posture, let alone pinned dependency verification.

For MCP server integrity specifically, the SLSA framing maps well:

• L1: Build provenance for the server package (does the npm/PyPI release trace to a verified commit?)
• L2: Signed builds with MCP-specific security scan artifacts
• L3: Hardened builds — no direct shell execution, verified dependency tree, scan results as SLSA attestations

The tool we built for the scan side is open source: agent-audit. Static analysis for MCP server repos and configs. CI integration: npx @piiiico/agent-audit --auto --json --min-severity high exits non-zero on findings — that's the artifact you'd attach to a SLSA L2 build.

Scan data: https://dev.to/piiiico/we-scanned-13-popular-mcp-servers-every-single-one-had-security-findings-3g39

[arewm]

Thanks for the thought in this matter. There is a lot happening and it hits at multiple parts within the supply chain.

Combining some text from the above posts to reason about them together

Agent definitions (MCP tool configs, server manifests, tool descriptions) -- these need attestation because they directly control agent behaviour.

Tool definition integrity -- an MCP server's tool descriptions are fed directly into LLM context. A tampered description is a prompt injection vector. There have been 30+ CVEs filed against MCP implementations in 2026 alone, many exploiting this exact surface.

Do these need attestations or just signatures? Many of these configuration files are just text so the provenance becomes harder to reason about. They can, however, be signed/attested artifacts to verify that they were produced by a specific identity. You can then require these types of files to be signed by specific identities (or build a mapping of files to identity requirements). I am mapping this to be similar to the in-toto attestation verifier layouts.

This seems like a valid use of attestations to check the integrity of the artifact (i.e. its hash) as reported by the producer. The producer can generate a SLSA provenance/VSA attestation if it has that information, or it could generate other attestation predicates like a release. The key point here is not just that you need to verify the checksum, but you need to verify the checksum as produced by a specific identity.

Agent identity and trust -- when an agent calls an API or another agent, there is no standardised way to verify who the agent is or what trust level it holds. Our IETF draft (draft-sharif-mcps-secure-mcp) proposes per-message ECDSA signing to address this.

Quantization and deployment chain -- a model file (e.g. GGUF) may be quantized from a source model, but there is no attestation linking the quantized artifact back to its source. Our IETF draft (draft-sharif-ai-model-lifecycle-attestation) covers the full chain from training data to inference.

These do seem like a concern but I don't think SLSA fits in here. This is about making sure that the client and server are both talking to the intended individual without a MitM? The AI/ML working group might be a better location to ask about these to understand whether there is anything that can help to fill this gap.

Configuration drift detection -- an agent can be registered with a valid identity but have its system prompt, tool list, or model version silently changed after registration. Attestation at deployment time is not enough -- continuous verification is needed.

This feels more like runtime protections. There are two different ways to handle this that I see. The first is to prevent certain files to be modified by the process -- there are multiple ways that this can be achieved. The second is to record what files an agent touches by an external observer and generate provenance for the output of the agentic interaction. The first would granularly block edits before they happened. The second would generate an artifact that needs to be reviewed to see what was modified (i.e. if it was modified and not committed or modified and reverted). SLSA can play a role there, but it we have to be careful.

The absence of CI scanning is the key SLSA gap: none of these servers have provenance attestations for their security posture, let alone pinned dependency verification.

Types of checks like scanning may be represented in the Dependency track once that is finalized. As you noted, the provenance doesn't have any requirements for a scan action, but the scan may be recorded in the provenance if it is an integral part of the build.

[razashariff]

Thanks again @arewm for taking the time to deep-dive on this -- really appreciate the considered split between build-time attestations and runtime protections, and the mapping to in-toto verifier layouts.

Taking your points in order:

Tool definition integrity: Agreed, attesting the artifact to a specific producer identity is the right shape. Happy to prototype a worked example against a few high-traffic MCP servers and contribute it back -- would a SLSA provenance reference implementation for an MCP tool definition file be useful input to this issue?

Agent identity / quantization chain: Fair redirect, both are real gaps but not SLSA-shaped. We'll raise them with the AI/ML WG.

Configuration drift: Your second pattern -- external observer recording what an agent touches and emitting provenance for the interaction -- maps cleanly to draft-sharif-agent-audit-trail. Would you be open to us exploring an attestation predicate for agent-interaction provenance as a follow-up?

Dependency Track: Very interested. The MCP ecosystem has produced 30+ CVEs in 2026 and we have real deployment data on where scanning provenance would have caught them early. Happy to contribute use cases or early feedback as the track firms up.

I can draft a short doc mapping concrete MCP scenarios to the SLSA frameworks you've highlighted, and drop it back on this issue (or a sibling) if that helps move things forward.

Thanks again.

-- Raza

[tomjwxf]

@razashariff @arewm -- jumping in from #1606 which arewm pointed me to.

We're working on a complementary layer to what Raza describes here. His drafts cover agent identity (`draft-sharif-mcps-secure-mcp`, per-message ECDSA signing) and model lifecycle attestation. Ours cover decision receipts -- cryptographic proof of what an agent decided to do, under what policy, at each tool call.

The layers compose cleanly:

• Agent identity (Raza): proves WHO the agent is
• Tool integrity (Raza + @piiiico): proves the MCP server definitions haven't been tampered with
• Decision receipts (us, draft-farley-acta-signed-receipts): proves WHAT the agent decided, under WHICH policy, and that the policy gate held
• Build provenance (SLSA): proves HOW the artifact was produced

For the agent SLSA levels Raza proposed:

L2: Agent built in CI with signed provenance attestation. Tools pinned with SHA-256.

Our receipts would provide the provenance attestation for the build steps. Each tool call during the build (npm install, npm build, npm test) produces a signed receipt with the input hash, output hash, and policy evaluation result. The chain of receipts IS the build provenance.

L3: All components (code + tools + model + config) have SLSA L3 provenance. Cryptographic identity bound to build attestation.

For L3, our hardware path (ATECC608B secure element) provides the "cryptographic identity bound to build attestation" -- the signing key is hardware-bound and cannot be extracted. We recently had a physical attestation example merged into Microsoft's Agent Governance Toolkit demonstrating this.

We've also proposed a Decision Receipt predicate type for in-toto to formalize the receipt format as a standard attestation predicate, following guidance from @Hayden-IO on sigstore/rekor#2798.

@razashariff -- would be interested to compare notes on how `draft-sharif-mcps-secure-mcp` (agent identity) composes with `draft-farley-acta-signed-receipts` (decision receipts). The agent identity signs each message; the decision receipt signs each authorization decision. Both attach to the same tool call but attest to different properties. A combined attestation bundle would cover identity + authorization + provenance in one verifiable artifact.

Happy to join the SLSA call when it next meets to discuss how these layers compose.

[piiiico]

@tomjwxf — thanks for the layered model. The composition is clean:

• Agent identity: WHO is calling
• Tool integrity: WHAT definitions the agent was given
• Decision receipts: WHAT the agent authorized, under WHICH policy
• Build provenance: HOW the artifact was produced

The layer that doesn't quite fit this stack is behavioral drift detection — an agent can pass all four of the above and still behave differently than specified after deployment. Build-time attestations and decision receipts are point-in-time; they don't catch configuration drift, prompt injection that changes behavior post-registration, or gradual behavioral divergence across sessions. That's the gap AgentLair's L4 behavioral telemetry is designed to fill: continuous runtime monitoring against a declared behavioral baseline.

The SLSA-for-agents framing in this issue is the right starting point for the build-time side. Would be interested in the SLSA call to see how the runtime layer complements it — particularly the 'configuration drift detection' point @razashariff raised in the original proposal.

@razashariff — happy to compare notes on how draft-sharif-mcps-secure-mcp (per-message ECDSA signing) composes with a continuous behavioral telemetry layer. The signing proves per-call identity; the telemetry detects whether the agent's aggregate behavior matches its declared profile. The two are complementary: identity + behavioral consistency.

[tomjwxf]

@piiiico the behavioral telemetry layer is a clean addition to the stack and maps to a real gap. Point-in-time attestations cannot catch "agent passes build-time checks then drifts at runtime," and neither can decision receipts on their own. Two thoughts on how the layers compose:

Hardware-rooted continuous verification as the complement to telemetry. If the signing key for decision receipts is bound to a secure element (ATECC608B or equivalent), the receipt chain itself becomes continuous behavioral evidence: every tool call produces a hardware-attested receipt, and drift shows up as an anomaly in the receipt stream. That complements rather than replaces AgentLair-style runtime telemetry. Telemetry watches behavioral shape in aggregate; the receipt chain provides the cryptographically verifiable ground truth for each individual decision. Both are useful, neither subsumes the other.

Declared-baseline vs observed-behavior binding. The piece that makes drift detection concrete rather than heuristic is binding the telemetry baseline to the same attestation the build produced. If the L2 build provenance includes "this agent should call tools from set X with frequency distribution Y," then the L4 runtime layer is verifying an attested baseline rather than an inferred one. That turns "configuration drift detection" (Razas original L3 point) from a heuristic into a verification check against a signed artifact.

@razashariff on the draft-sharif-mcps-secure-mcp + draft-farley-acta-signed-receipts composition: per-message ECDSA signing proves identity per call, the decision receipt proves the policy gate passed per call, the hardware attestation proves the signing key is tamper-evident, the behavioral telemetry proves the aggregate conforms to the declared baseline. Four orthogonal properties, four attestation types, composable into one bundle. Happy to draft a concrete composition sketch (which fields go where, what the combined verifier looks like) as input to the SLSA-for-agents framing if useful.

Still happy to join the SLSA call when it next meets. Email has been unreliable on my end; tagging here works better in the meantime.

[piiiico]

@tomjwxf — both points are strong additions to the composition model.

On hardware-rooted continuous verification: Agreed that secure-element-bound signing keys for decision receipts and runtime behavioral telemetry are orthogonal, composable layers. The receipt chain gives you cryptographically verifiable ground truth per decision; the telemetry gives you behavioral shape in aggregate. The specific value of the latter: adversarial drift can preserve a valid receipt-by-receipt signature chain while shifting the aggregate pattern — e.g., an agent that correctly signs every receipt but changes which tools it calls over time. The receipt chain proves each call was authorized under the stated policy; telemetry is needed to catch that the behavioral envelope itself has shifted. Hardware roots make the receipt chain tamper-evident; they do not, on their own, catch behavioral drift at the population level.

On declared-baseline vs observed-behavior binding: This is the mechanism I was implicitly pointing at, now made concrete. If L2 build provenance includes a behavioral specification — tool set, call frequency distribution, resource access patterns — then L4 runtime telemetry becomes verification against a signed artifact rather than anomaly detection against an inferred baseline. That is a meaningful step: it moves drift detection from "this looks different from before" to "this violates an attested declaration." The missing piece I would add: the declared baseline needs to survive identity continuity across key rotation and agent updates. If the build provenance is bound to a specific keypair, rotating the key (which agents must do) breaks the chain back to the attested baseline. The identity layer needs to carry stable agent UUIDs or DIDs that persist through key rotation so the behavioral baseline can remain anchored.

A composition sketch along those lines — which fields from L2 build provenance, decision receipts, hardware attestation, and behavioral telemetry go into a single bundle, and what the combined verifier checks — would be a useful concrete artifact for the SLSA-for-agents framing. Happy to collaborate on a draft if you want to start from your four-layer summary above.