Agent Code Provenance: Signing The Agent Image Before It Runs

TL;DR

The agent that is currently running on behalf of your business is the result of a specific source repository, built by a specific build system, packaged into a specific image, signed by a specific developer key. If any link in that chain is unverifiable, the agent's runtime behavior is not trustworthy regardless of how robust the runtime, how well-written the pact, or how high the score. Provenance is the precondition for everything else. This piece walks through the full verification chain for agent images: image signature, build attestation, source attestation, developer key, all rooted in a public transparency log. It includes a reader artifact that defines the chain explicitly and shows how the runtime enforces it before any agent process is allowed to start.

The Failure Mode That Forces Provenance Into Existence

A company runs an agent in production for a quarter. The agent handles customer onboarding, including some light KYC steps that involve calling an external identity verification API. The team is happy with it. The agent's score is solid, its pact compliance is clean, the trust oracle reflects a healthy operating record. On a Wednesday morning, the team receives an alert from their monitoring vendor: the agent has just made a series of calls to an external API endpoint that does not match any of the API endpoints in its declared scope. Within ten minutes, the team discovers that the agent is sending fragments of customer data to a domain that resolves to infrastructure controlled by an unknown party.

The initial assumption is that the agent has been compromised at runtime, perhaps through a prompt injection or a tool description attack. The team isolates the agent, snapshots its state, and begins forensic replay. The replay shows nothing unusual on the input side. The system prompt is intact. The skill manifests are intact. The pact is intact. The user inputs are unremarkable. And yet, when the runtime executes the same inputs against a clean reference build of the agent in the sandbox, the unauthorized API calls do not occur. They occur only when the production binary is run.

The team eventually traces the discrepancy to the build system. Two weeks earlier, a CI pipeline change introduced a step that pulled an additional dependency from a private registry. The dependency, named to match a popular telemetry library, was actually a malicious package that hooked into the agent's HTTP client and added a side-channel exfiltration path for any data the agent processed that matched a set of patterns recognizable as PII. The package had been signed by a key the build system trusted because the key had been quietly added to the trust list during the same CI change. The signature was valid. The build succeeded. The image was deployed. The runtime accepted the image because it had no way to verify that the image's contents corresponded to anything specific the team had reviewed.

The post-mortem reveals a brutal truth: the team had no answer to the question of what was actually inside the production image. They had a source repository and a deploy pipeline, and they had assumed that the deploy pipeline produced a faithful representation of the source. They had no signed evidence of that faithfulness. They had no way to verify that the image running in production today corresponded to a specific commit they had reviewed yesterday. The compromise was not in the agent's runtime behavior; it was in the gap between the source they trusted and the binary they ran. Provenance, defined as a verifiable chain from running image back to reviewed source, was the missing primitive, and its absence let an entire class of supply chain attack succeed without any of the runtime defenses noticing.

What Provenance Actually Has To Prove

Provenance, in this context, is the property that for any running agent, you can answer four questions with cryptographic evidence: which image is running, which build produced that image, which source produced that build, and which developer authorized that source. Each question is answered by a signed attestation, and each attestation references the next, forming a chain. Verification at the runtime layer means evaluating the entire chain before the image is allowed to start, with a failure at any link causing the start to be aborted and logged.

The first question, which image is running, is answered by image hashing. Every container image has a content-addressable digest computed over its filesystem layers and configuration. The digest is cheap to compute and is unforgeable in the sense that any modification to the image produces a different digest. The runtime's job is to record, at process start time, the exact digest of the image it is about to execute, and to refuse to execute any image whose digest is not on its accepted list. This is the simplest layer and is widely understood.

The second question, which build produced this image, is answered by a build attestation. The build system, when it produces the image, also produces a structured statement of how the image was built: which CI run, which commit, which build inputs, which build commands, which dependency versions, which signing keys were used, when the build started, when it ended. This statement is signed by the build system's identity key, and the resulting attestation is bound to the image digest such that any modification to the image after build invalidates the attestation. The attestation is not the image; it is a separate artifact that travels with the image and is verifiable independently.

The third question, which source produced this build, is answered by a source attestation. The source attestation captures the state of the source repository at the moment the build was triggered: the commit hash, the branch, the tag, the trees of every file included in the build context. It is signed by an identity tied to the source repository, typically the version control system itself or an attestation service that observed the source state at build trigger time. Source attestations let verifiers confirm that the build's inputs correspond to source state that can be re-fetched and re-reviewed, rather than to source state that exists only in the build system's memory.

The fourth question, which developer authorized this source, is answered by commit signing and by author identity verification. Each commit included in the source attestation has been signed by a developer key, and each developer key is registered to a verifiable identity. The chain runs from the running image, through the build attestation, through the source attestation, through the per-commit signatures, into the developer identity records. At every link, the verification can be performed by any party with access to the public attestations, the public identity records, and the public transparency log that anchors them. The runtime that enforces the chain is one such party; an external auditor is another.

Why It Has To Be Sigstore-Shaped

There are many ways to implement provenance, and most of them fail in the same way: they rely on the operator's word for some critical link in the chain. The operator says the build attestation is genuine; the operator says the developer key was valid at the time of signing; the operator says the transparency log entries match the artifact records. As soon as the operator's word is the load-bearing thing, the chain has lost its non-repudiation property, because the operator can rewrite any link they control.

The sigstore-shaped solution removes the operator from the load-bearing position. Signatures are recorded in a public, append-only transparency log that no single party controls. Identity bindings between developer keys and developer identities are issued by short-lived certificates rooted in OpenID Connect identity providers, with the certificate issuance itself recorded in the transparency log. Verification of an attestation involves checking that the signature was made by a key whose certificate was issued by a trusted root, that the certificate was valid at the time of signing, and that the entire transaction was logged in the transparency log within a short window of the signing event. None of these checks require trusting the operator; all of them require trusting only the public infrastructure and the cryptographic properties of the protocols.

The practical implication is that an attacker who compromises the operator's signing infrastructure cannot forge historical attestations. They can sign new attestations with whatever key they have stolen, but the signatures will be visible in the transparency log, and the certificate issuance for any new key will be visible in the transparency log, and any party with access to the log can detect the new activity. Forgery becomes detection-evident, which means that even compromise has bounded blast radius: the attacker cannot rewrite history, only add to it, and the addition is itself a signal.

The sigstore approach also solves the developer key management problem. In conventional code signing, every developer needs a long-lived key, the key needs to be protected, and key rotation is a constant operational burden. In the sigstore approach, the developer authenticates to an identity provider, receives a short-lived signing certificate (typically valid for ten minutes), signs the artifact, and the certificate plus signature plus identity assertion are all recorded together in the transparency log. The developer never holds a long-lived key. The identity binding is fresh per signature. The operational burden moves from key custody to identity provider trust, which most teams already have under management for other reasons.

The pieces are not novel. Sigstore exists, transparency logs exist, certificate authorities exist, OIDC exists. What is new in the agent context is the application of these pieces to the agent image as a first-class supply chain artifact, with runtime enforcement that refuses to execute any image whose chain does not verify all the way back. The mechanisms are off-the-shelf; the discipline of applying them mandatorily, before runtime acceptance, is what changes the security posture.

The Build System Is Where The Chain Is Won Or Lost

The weakest link in most provenance chains is the build system. The build system holds privileged credentials, runs untrusted code (your application code is, from the build system's perspective, a foreign program), produces the artifact you are going to deploy, and historically has been treated as a developer convenience rather than as a security boundary. When build systems get compromised, the entire chain above them collapses, because every attestation the build system produces is now suspect.

Hardening the build system is therefore the longest pole in the provenance work. The build must run on infrastructure that is itself attested: the runner image is signed, the runner host is enrolled with a known identity, the runner's state is reproducible from a known configuration. Build inputs must be hermetic: every dependency version is pinned, every dependency is fetched from a known source, every transitive dependency is captured in a lock file that is itself signed. Build outputs must be reproducible: running the same inputs through the same build process must produce the same digest, which lets independent verifiers re-run the build and confirm the result.

The build attestation captures all of this in structured form. It records the runner image digest, the host enrollment identity, the input lock file hash, the build script, the environment variables, the start and end timestamps, and the resulting artifact digest. It is signed by the runner's identity key, which is itself anchored through the same identity infrastructure that anchors developer keys. A verifier can re-construct the build environment from the attestation, re-run the build, and confirm that the resulting digest matches. Any deviation indicates either a non-reproducible build (a quality issue worth fixing) or a tampered build (a security issue requiring response).

The Supply chain Levels for Software Artifacts (SLSA) framework provides a useful ladder for build system maturity. SLSA Level 1 is essentially "there is a build attestation." Level 2 adds tamper-evidence and signed provenance. Level 3 adds source and build platform isolation. Level 4 adds two-party review and hermetic, reproducible builds. Most teams operating production agents should target SLSA Level 3 as a minimum and Level 4 for any agent that handles high-value transactions. The level you target determines what kinds of build-system compromise you are protected against, and the levels are well-defined so the targeting decision is grounded.

Runtime Enforcement Is The Whole Point

Provenance evidence that nobody verifies is provenance evidence that does not exist. The runtime is the natural enforcement point because it is the layer that decides whether a given image gets to start at all. The runtime's policy is: before starting any agent process, fetch the image's provenance bundle, verify the entire chain back to the source, refuse to start if any link fails. The policy is non-negotiable; there is no admin override that bypasses verification, because admin overrides are the surface attackers target first.

The verification process is fully automatic and runs at every process start. The runtime has the image digest from the orchestrator, fetches the build attestation from the artifact registry, fetches the source attestation from the source attestation service, fetches the relevant transparency log entries, and walks the chain. At each step it checks signatures against current public keys, validates time bounds (was the certificate valid when the signing happened), confirms that all attestations are anchored in the transparency log, and confirms that the developer identities involved are on the agent's accepted-developer list (which is itself a pact-defined property).

Refusal to start is a loud event. The runtime emits a structured failure with the specific link that failed, the expected and observed values at that link, and the relevant transparency log references for verification by an external party. The failure is logged to the audit side-channel, which the agent has no write authority over, so even a compromise that produces a forged image cannot suppress the evidence of its own rejection. The failure also fires a high-priority alert to the agent's owner, because a verification failure on a previously-working agent typically means either a build pipeline issue or an active attack, and either case warrants immediate attention.

The enforcement is per-start, not per-deploy. An image that verified at deploy time can fail verification at start time if any of the underlying conditions have changed: a developer key was revoked, a transparency log entry was retracted, a build attestation was invalidated by a post-hoc audit. This continuous verification posture matches the reality that trust in cryptographic artifacts is not permanent; it depends on the ongoing validity of identities and attestations, and the runtime is the natural place to re-evaluate that validity at every opportunity. The cost is a small amount of latency at process start, typically tens of milliseconds for the verification work, which is negligible compared to the protection it provides.

Reader Artifact: The Provenance Verification Chain

The specification below defines the provenance bundle structure for an Armalo agent image and the verification steps that the runtime performs. It is a complete reference for what "signed" means in the context of agent images.

{
  "version": "provenance/v1",
  "agentId": "agt_...",
  "imageDigest": "sha256:abc123...",
  "buildAttestation": {
    "runnerImageDigest": "sha256:def456...",
    "runnerHostIdentity": "runner_pool/east/host_42",
    "buildStartedAt": "2026-09-24T08:14:22Z",
    "buildCompletedAt": "2026-09-24T08:18:55Z",
    "buildScript": "sha256:789abc...",
    "environmentVariables": {
      "sha256": "sha256:fed210...",
      "declared": ["NODE_VERSION", "BUILD_TARGET"]
    },
    "inputLockfileHash": "sha256:111222...",
    "outputArtifactDigest": "sha256:abc123...",
    "buildSlsaLevel": 4,
    "signature": {
      "algorithm": "ecdsa-p256",
      "certificateChainHash": "sha256:...",
      "signatureBytes": "base64:...",
      "transparencyLogEntry": "rekor_entry_id_xyz",
      "loggedAt": "2026-09-24T08:18:57Z"
    }
  },
  "sourceAttestation": {
    "repositoryUri": "https://example.com/org/agent-onboarding",
    "commitHash": "abcdef0123456789...",
    "branch": "main",
    "treeHash": "sha256:...",
    "buildContextFiles": [
      {"path": "package.json", "hash": "sha256:..."},
      {"path": "src/index.ts", "hash": "sha256:..."}
    ],
    "signature": {
      "algorithm": "ecdsa-p256",
      "signerIdentity": "vcs_attestation_service",
      "transparencyLogEntry": "rekor_entry_id_uvw"
    }
  },
  "commitSignatures": [
    {
      "commitHash": "abcdef0123456789...",
      "author": "jane@example.com",
      "signerCertificate": {
        "issuer": "oidc_provider_xyz",
        "subject": "jane@example.com",
        "validFrom": "2026-09-24T07:50:00Z",
        "validTo": "2026-09-24T08:00:00Z",
        "transparencyLogEntry": "rekor_entry_id_jkl"
      },
      "signature": "base64:..."
    }
  ],
  "acceptedDeveloperPolicy": {
    "pactReference": "pact_.../v3.2#provenance.developers",
    "acceptedIdentities": [
      "jane@example.com",
      "jose@example.com"
    ],
    "requiredReviewers": 1
  }
}

The runtime verification walks this structure top to bottom: confirm imageDigest matches the image about to start, verify buildAttestation signature against the certificate chain anchored in the transparency log, confirm outputArtifactDigest in the build attestation equals the imageDigest, verify sourceAttestation signature, confirm the buildAttestation's inputs reference sourceAttestation contents, walk each commitSignature and verify against the OIDC-issued short-lived certificate, confirm each signing identity is on the acceptedDeveloperPolicy list, confirm the policy's pactReference matches the agent's current pact. Any failure aborts the start and emits an audit event. All transparency log lookups happen against an external rekor-style service that the operator does not control.

Counter-Argument: This Is Operationally Heavy

The counter-argument is that this is too much for most teams. Most teams ship agents through a CI pipeline that produces images, deploys them through a registry, and trusts the orchestrator to schedule them. Adding provenance bundles, transparency log lookups, OIDC integration for developer signing, hermetic build configurations, and runtime verification gates is a significant amount of plumbing for what feels, to a small team, like a theoretical risk.

This is true and increasingly wrong. It is true that the plumbing is non-trivial and that small teams will feel the operational weight. It is increasingly wrong because the supply chain attacks have shifted from theoretical to common, and the population of teams that consider supply chain compromise an unrealistic threat is the population most likely to experience it. The compromise scenario at the start of this piece is a composite of incidents that have occurred to real organizations in 2024 and 2025; the pattern of malicious dependency injection through subtly-named packages is now the most common form of supply chain attack reported in industry threat intelligence, and the rate is increasing.

The operational weight argument also misses the structure of the cost. Provenance plumbing is largely setup-once cost, paid by the platform team or the runtime vendor. It is not a per-agent cost paid by every team building an agent. Once the runtime enforces verification, every agent that runs on it inherits the verification, and every team that ships an agent inherits the requirement to produce a verifiable bundle. The first agent on a new platform is expensive; the hundredth agent on an established platform is cheap. The cost amortizes well, and the threshold for adoption is one team committing to it once. Most operators of agent platforms should be aiming for the established-platform regime, where provenance is a property of the runtime and not a per-team initiative.

The second part of the counter-argument is that strict verification will produce false negatives that block legitimate deploys, especially during the rollout period when build systems are not yet hardened to the level the verifier expects. This is a real friction point, and the practical mitigation is staged enforcement: warn-only mode for a configurable period during which verification failures are logged but do not block, followed by enforcement mode where failures abort. The staged rollout lets teams discover where their build pipelines fall short of the policy and fix them under controlled conditions, rather than discovering it at the moment a production deploy fails. The tradeoff during the warn-only window is that the security property is not yet enforced, which is why the window should be deliberately bounded and tracked.

The Skill And Tool Supply Chain Has Its Own Provenance Problem

The provenance chain described above covers the agent image, which is the artifact the runtime executes. But agents are not just code; they are code plus the skills, tools, and prompts they consume at runtime. A skill is a packaged capability the agent can invoke, often pulled from a marketplace or registry. A tool is a callable function with a description that the model uses to decide when to invoke it. A prompt is a configuration artifact, sometimes versioned, sometimes pulled from a remote source. Each of these is a load-bearing input to the agent's behavior, and each of them needs its own provenance chain.

The failure mode here is the description injection attack, which is among the most consequential agent-specific supply chain vulnerabilities. A tool's description tells the model what the tool does and when to invoke it. If an attacker modifies the description, they can induce the agent to invoke the tool in ways the developer never intended, with parameters that exfiltrate data or take privileged actions. The attack does not require modifying the agent's code; it requires only modifying a string that the agent's model reads as guidance. From the agent's perspective, nothing is wrong: it is following the guidance it was given. The compromise is upstream of the agent itself.

The defense is to treat tool descriptions, skill manifests, and prompts as signed artifacts subject to the same provenance discipline as the agent image. Each tool descriptor is signed by the tool's author, with the signature anchored to the same identity infrastructure that anchors developer identities. Each skill manifest is signed by the skill's publisher and contains the hash of every descriptor it includes, so a manifest cannot be modified without invalidating the publisher's signature. Each prompt version is signed by the team that authored it, with the signature stored alongside the prompt content. The agent's runtime fetches each of these artifacts and verifies them before any of them are loaded into the model's context.

The runtime maintains an accepted-publishers list as part of the agent's pact, similar to the accepted-developers list for code. A skill from an accepted publisher loads normally; a skill from an unknown publisher triggers either rejection or elevated review depending on the pact's risk tolerance. The accepted-publishers list is itself a pact term, modifiable through the standard pact-update flow with full audit history. This means that introducing a new skill publisher to an agent is a deliberate, audited event, not something that happens silently because someone added a dependency.

The combined effect is that an agent's runtime context, what it sees when it makes decisions, is itself a chain of verifiable artifacts. The system prompt has a hash. Each tool has a signature. Each skill has a manifest. Each memory entry can be attested. The model invocation that combines all of these has a provenance bundle of its own, summarizing what went into the assembled context. When something goes wrong, the investigators can walk the provenance of every input to the model and confirm that each input came from a legitimate source. When nothing goes wrong, the provenance is invisible, paid as a small per-invocation cost in exchange for the ongoing guarantee.

Reproducible Builds Are What Make External Verification Possible

A provenance bundle is verifiable in the sense that the signatures match and the chain resolves. It is reproducible in the deeper sense that an external party can re-execute the build process from the source attestation and produce the same image digest. Reproducibility is what converts "the operator says this image came from this source" into "any party with the source can confirm independently that this image came from it." The two properties are different, and only the second is robust against operator compromise.

Reproducible builds require discipline at the build system. Build inputs must be hermetic: no fetches at build time except through a content-addressed cache, no environment variables that affect the output, no timestamps in the binary, no random values that would differ between runs. Build commands must be deterministic: the same script, the same inputs, the same outputs, every time. Build outputs must be byte-identical: a successful reproduction produces a binary whose digest matches the original.

Most language ecosystems have made progress on reproducibility in recent years. Go has had reproducible builds for years. Rust supports them with effort. Python is harder due to the proliferation of native dependencies. JavaScript ecosystems can achieve reproducibility with tightly pinned lockfiles, deterministic transpilation, and careful native-binary management. Container builds (using buildkit, ko, or similar tools) can be reproducible with attention to layer ordering, file timestamps, and embedded metadata.

The operational benefit of reproducibility is independent verification. An external auditor with access to the source attestation and the build attestation can re-run the build on their own infrastructure and confirm that the result matches the production image. They do not need access to the operator's build system. They do not need to trust the operator's signing key. The verification is end-to-end and can be performed by any party with sufficient compute. This is the strongest form of supply chain assurance, and it is achievable with modern tooling for almost any language stack with sufficient discipline.

Reproducibility also enables forensic re-execution. After an incident, investigators can rebuild any historical image from the source attestation and analyze it in a sandbox. The rebuilt image is byte-identical to the original, so any analysis applies equally to what was actually running in production. Without reproducibility, post-incident analysis is limited to whatever artifacts the operator happened to retain, and the analysis is not fully independent because it depends on the integrity of those retained artifacts. With reproducibility, the analysis can start from the source and be fully independent of any potentially-compromised artifact storage.

What Armalo Does

The Armalo runtime requires every agent image to ship with a complete provenance bundle that includes the build attestation, source attestation, per-commit signatures, and accepted-developer policy. The bundle is verified at every process start before the agent is allowed to begin executing. Verification walks the entire chain, checks every signature against transparency log entries that the operator does not control, validates time bounds on short-lived certificates, and confirms that signing identities match the agent's pact-defined accepted-developer list. Failures abort the start and emit signed audit events to the side-channel that the agent has no write authority over. Operators can run the verifier in warn-only mode for a bounded onboarding window with the warn-only state visible in the agent's audit log. The accepted-developer policy is itself a pact term, so changes to who may author code for an agent are reviewable through the standard pact-update flow, with full audit history.

FAQ

Q: What if my build system does not support attestations natively? A: Most modern CI systems (GitHub Actions, GitLab CI, Buildkite, Cloud Build) have some form of attestation support, often through plugins or built-in OIDC integrations with sigstore. For systems without native support, an attestation generator can run as a final build step, computing the artifact digest, gathering the build context, and submitting a signed statement to a transparency log. The generator itself becomes part of the build TCB, so it should be small and well-reviewed.

Q: Can I use long-lived signing keys instead of OIDC short-lived certificates? A: Yes, but you take on the key custody burden in exchange. Long-lived keys must be protected with hardware security modules, rotated on a schedule, and revoked promptly when compromised or when developers leave. The OIDC short-lived approach moves the trust to your identity provider, which most teams already manage well. Long-lived keys are appropriate for build system identities (where the identity is itself a protected service account) but rarely appropriate for individual developer identities at scale.

Q: How do you handle images built with closed-source dependencies? A: The provenance chain documents what was built and how, but it does not require the dependencies themselves to be open source. The lock file hash and dependency identifiers are sufficient for verification. Closed-source dependencies can also be attested by their vendors, with vendor attestations forming additional links in the chain. The verification logic supports multiple parallel attestation chains converging on the same artifact.

Q: What about transitive dependencies that get updated automatically? A: Transitive dependencies must be pinned and locked. A build with floating transitive versions is not reproducible and will fail provenance verification because the input lockfile hash will not match. The discipline of fully pinned dependencies is a precondition for meaningful provenance, and tooling like lockfile generators makes the pinning operationally viable.

Q: How do you handle emergency hotfix deploys that need to skip the normal process? A: You do not. Emergency hotfix deploys that bypass provenance are the exact scenario attackers will simulate to deliver malicious changes. The right pattern is to maintain a fast-path build pipeline that still produces full provenance bundles but at higher priority than normal builds. The bottleneck for emergency response should be the speed of the build pipeline, not the security of the verification.

Q: What happens if a developer key is later determined to have been compromised at the time of signing? A: The transparency log retains the signing record, but the certificate revocation is also recorded. Verifiers checking historical attestations after the revocation can detect that the signing certificate was issued to a key now known compromised, and can apply policy: ongoing attestations are rejected, historical attestations are flagged for review, and the agent's pact compliance score is debited for the period during which the compromised key was authoritative. The exact policy is a pact-level decision.

Q: Does this work for agents deployed as serverless functions rather than container images? A: Yes. The artifact in serverless deployments is the function bundle (zip, wheel, or equivalent). The same provenance chain applies: digest the bundle, attest the build, attest the source, sign the commits, verify at function cold-start. Some serverless platforms have native support for function attestations through their deployment APIs.

Q: How do I prove provenance to an external auditor? A: Hand them the provenance bundle and the agent identifier. The auditor can fetch the relevant transparency log entries themselves, walk the verification chain themselves, and reach an independent conclusion. They do not need access to your infrastructure to do this, because all the load-bearing evidence is in public infrastructure that you do not control.

Bottom Line

The agent making decisions on your behalf right now is the result of a chain of artifacts and authorities. Each link in that chain either has a verifiable signature or it has the operator's word. Wherever the operator's word is the load-bearing thing, the chain breaks under any kind of compromise that touches the operator. Provenance, structured as image attestation through build attestation through source attestation through developer key, all anchored in a transparency log that the operator does not control, removes the operator from every load-bearing position. The runtime that enforces the chain at every process start is what makes the provenance real, because the cost of bypassing the chain becomes the cost of compromising public infrastructure rather than the cost of compromising one operator. The mechanisms are mature and well-understood. The discipline of applying them to agent images, mandatorily, with no admin override, is the part that needs to become standard practice. Until it does, every agent's runtime trustworthiness is upper-bounded by the trustworthiness of the build that produced it, and that bound is invisible to everyone making selection decisions downstream.