Provenance For Agent Tools: How To Know Where A Capability Came From And Who Signed It

TL;DR

A tool's provenance is the signed, verifiable answer to three questions: which source repository did this code come from, which exact build of that code produced this artifact, and who signed the build saying it is authentic. In 2026 the answers are usually a shrug, a guess, and a vibe. This post lays out the supply chain audit pattern we use to enforce real provenance for agent tools, the architectural primitives required to make the pattern work, and a Tool Provenance Manifest Schema you can paste into a registry today. The framework introduced here is the Three-Anchor Provenance model: Source Anchor, Build Anchor, Identity Anchor. If any of the three is missing, the tool has no provenance, only a story.

A Tool Without Provenance Is A Rumor

Last quarter we worked with a team that had been running a fleet of agents in production for fourteen months. The agents performed well. They were profitable. They were considered, by leadership, to be one of the company's most reliable systems. The team was proud of the operational maturity they had built. Then a customer asked a question that the team could not answer: when you say agent X uses tool Y, where did the code for tool Y come from? The team knew the answer in a soft, narrative sense: tool Y had been written by a former employee, then forked by a vendor, then patched by a contractor. Nobody could produce a verifiable chain that connected the running binary to a specific commit in a specific repository. Nobody could say which version of which dependency was actually loaded. Nobody could point at a signature that proved any of it.

This is not an isolated story. It is the modal story for agent tools in 2026. The reason is structural. The systems we built in the last decade for software supply chain security, tools like SLSA attestations and Sigstore and reproducible builds, were designed for the world of containerized services and library packages. They have not yet been adapted to the world of agent tools, where the unit of composition is a skill or a capability or an MCP server, and where the consumers are autonomous agents rather than CI pipelines. The tooling is sparse, the standards are competing, and the practical reality on the ground is that almost nobody knows where their tools came from.

The failure mode this creates is one we have seen before, and it has a specific shape. When provenance is missing, the most innocuous-seeming events become unfixable incidents. A tool stops working: is it because the code changed, the dependencies changed, or the runtime changed? You do not know. A tool starts behaving strangely: was it always like that, or did someone modify the artifact? You do not know. A tool is found to contain a vulnerability: which deployments are affected? You do not know. The compounding cost of not knowing is enormous, and it grows with the size of the agent fleet, because each new tool adds new question marks and each new agent multiplies the surface that has to be audited.

The purpose of this post is to fix this. We will walk through the audit pattern we use, lay out the three architectural anchors that have to be in place for provenance to mean anything, and end with a manifest schema you can adopt for your own agent tools. The schema is small, the pattern is implementable in days rather than months, and the result is that the question your customer asked us, which we could not answer, becomes a SQL query that returns a row.

The Three-Anchor Provenance Model

The framework we use is called Three-Anchor Provenance. The premise is simple. For any agent tool you run in production, you should be able to answer three questions, and you should be able to back each answer with cryptographic evidence. The three questions are: where did the source come from, what build produced the artifact, and who attested that the build was authentic? We call the answers Source Anchor, Build Anchor, and Identity Anchor. If any anchor is missing, the tool has no real provenance and you should treat it as untrusted.

The Source Anchor binds the tool to a specific source repository, at a specific commit hash, on a specific branch policy. The hash matters because branches are mutable; the policy matters because not every commit on a repository should be a candidate for production. A Source Anchor is a tuple of (repository URL, commit SHA, signature over both). The signature can be from a Git server like GitHub or GitLab if you trust their signing infrastructure, from Sigstore if you want a public log, or from your own internal certificate authority if you operate at scale and want full control. What is not acceptable is a tarball whose origin is asserted in plain text without any cryptographic binding.

The Build Anchor binds the source to the actual artifact. This is the step where most current systems fail. You can have a perfectly attested source repository, and a perfectly clean commit, and still end up with an artifact that does not correspond to that commit, because the build process introduced a modification, intentionally or otherwise. The Build Anchor is the SLSA-style attestation that says: this artifact, with this hash, was produced by this build process, running this commit, in this environment, at this time. The attestation is signed by a build identity, and the build process must be reproducible enough that any third party can verify the attestation by running the same build and getting the same artifact hash. This is a strong requirement and a lot of build pipelines do not meet it. Meeting it is a project, not a checkbox, and it is the project that distinguishes serious provenance from theater.

The Identity Anchor is the human or the organization who attests, on top of the Source and Build Anchors, that this artifact is authorized for production use. The Source Anchor says where the code came from. The Build Anchor says how it became an artifact. The Identity Anchor says who, in the importing organization, took responsibility for releasing it. The Identity Anchor is signed by a key bound to a specific human or service identity, and the act of signing is logged in an immutable record that can be queried later. This is the anchor that enables accountability when things go wrong, because it answers the question of who decided this artifact should run.

A tool with all three anchors has provenance. A tool with two has a story. A tool with one has a rumor. A tool with none, which is most tools in production today, has hope. The audit pattern we will walk through next is the operational discipline that gets you from hope to provenance.

The Supply Chain Audit Pattern

The audit pattern is a sequence of checks that runs every time a tool is registered, updated, or invoked, and that produces a verifiable record at each step. We will walk through the pattern in three phases: registration, deployment, and runtime. Each phase has its own checks, its own evidence, and its own trust boundary, and the boundaries between them are exactly where most current systems leak.

In the registration phase, the check is: does this tool have a complete Three-Anchor Provenance attestation? The Source Anchor must point at a repository in your allowed source list, with a commit signature from a key in your trusted source-key set. The Build Anchor must reference a build pipeline in your allowed pipeline set, with attestations from a key in your trusted build-key set. The Identity Anchor must come from a human or service in your allowed releaser set, with a signature from a key in your release-key set. Any anchor that fails its check rejects the registration. The registration system writes a record to an immutable log capturing the full attestation, the result of each check, and the time and identity of the registration request.

In the deployment phase, the check is: does the artifact about to be loaded match the attestation that was registered? This is where reproducible builds matter, because the runtime needs to verify that the bytes about to be executed correspond, by hash, to the bytes attested at registration. If the hashes do not match, the deployment fails. If they match, the deployment proceeds and writes a record to the immutable log capturing the artifact hash, the registration ID it matched against, and the deployment target. This step catches the entire class of attacks where an attacker substitutes a different artifact for the attested one between registration and deployment, which is a category of attack that has affected major package ecosystems multiple times in the last decade.

In the runtime phase, the check is: is the running artifact still the artifact we deployed? This sounds redundant, but it is not. Long-running agent processes can be modified in place by a sufficiently privileged attacker. Hot-patching, dynamic loading, and process injection are real techniques. The runtime check is a periodic verification that the in-memory representation of the tool matches the on-disk representation, which matches the deployed hash, which matches the attestation. The check is cheap if you have the right primitives in place and very expensive to retrofit if you do not. We recommend implementing the periodic verification on day one, even if your initial coverage is partial, because the architectural patterns required to make it work end up shaping a lot of other decisions downstream.

The pattern produces a chain of evidence: registration log, deployment log, runtime check log. Each link in the chain is signed by an identity that can be audited. Each link references the previous link by hash. The result is that for any tool running in your environment at any point in time, you can produce a complete provenance chain back to the source repository and forward to the running process. When the customer asks you, fourteen months later, where this tool came from, you do not shrug. You run a query.

The Source Anchor Deep Dive

The Source Anchor is the easiest of the three to implement and the easiest to get wrong. The right way to do it is to require commit signatures on every source artifact, with signatures from a key in a known trusted set, with a verifiable mapping from the key to a human or service identity. The wrong way to do it, which is depressingly common, is to assume that because the source came from a private repository on your VCS, the source is trusted by virtue of the VCS access controls. This assumption fails the moment any contributor's account is compromised, the moment a contractor is added with overly broad permissions, the moment a CI key with write access is leaked, or the moment a self-hosted VCS has a vulnerability that allows commit forgery.

The specific control we recommend is signed commits enforced at the branch protection level. Every commit on the protected branches must be signed by a key in a known trusted set. The trusted set is small and managed explicitly. New keys are added through a documented process that includes identity verification of the key holder. Keys are rotated on a schedule and on any indication of compromise. The verification of signatures happens both at the VCS level (which is convenient but not sufficient) and at the build level (which is the actual security boundary, because a determined attacker who compromises the VCS can disable VCS-level signature checking). Belt and suspenders.

The second specific control is repository allowlisting. Not every repository in your organization is a valid source for production tools. The allowlist is short, explicit, and enforced at the registration step. A repository being on the allowlist is a deliberate decision that triggers a security review, including the branch protection setup, the contributor list, the dependency policy, and the release process. Repositories not on the allowlist cannot register tools. This sounds bureaucratic. It is bureaucratic. The bureaucracy is the point: it forces a deliberate decision before code from any new source can run in production, and it provides a focused list of repositories that the security team needs to monitor.

The third specific control is dependency provenance. Source Anchors only matter if the source itself does not silently include third-party code that has not been attested. This is where the lockfile discipline of modern package managers becomes a security boundary, not just a convenience: every dependency must be pinned to a specific version, and every version must come with its own provenance attestation, and your build process must verify the attestations of all dependencies before allowing the build to proceed. Without this, the Source Anchor only attests to the small fraction of code your team wrote. The much larger fraction of code coming in through dependencies is unattested, and any compromise of a dependency becomes a compromise of your tool.

The operational cost of these controls is not zero. The first time a team implements signed commits and repository allowlisting and dependency provenance, the cost is real, measured in days of friction and weeks of pipeline rework. The cost is paid once. The benefit is paid every day after, in the form of a Source Anchor you can actually rely on.

The Build Anchor Deep Dive

The Build Anchor is the hardest of the three to implement well, because it requires reproducible builds, and reproducible builds require a level of build pipeline discipline that most teams have never had to develop. A reproducible build is one where, given the same source and the same build environment, any party can reproduce the same artifact bytes. This sounds obvious until you try to do it, at which point you discover that almost every standard build pipeline introduces nondeterminism: timestamps in the artifact, unstable file ordering, environment-dependent paths, network-dependent dependency resolution, randomness in compilation choices.

The path to reproducible builds is well-trodden in the secure systems community but mostly unfamiliar to teams who have grown up shipping containers and serverless functions. The standard moves are: pin every input (sources, dependencies, base images, compiler versions, build tool versions), strip non-deterministic outputs (timestamps, ordering, environment-dependent paths), record the full build environment in the attestation, and run the build in a hermetic environment that has no network access except to attested artifact mirrors. The result is a build that can be re-run by any third party, including attackers, to verify that the artifact you released is the artifact your source produces.

The Build Anchor itself is a SLSA-style attestation. SLSA, Supply-chain Levels for Software Artifacts, is the framework we recommend for structuring the attestation, because it is the most mature standard in this space, has wide tool support, and has been evolving for several years in production use at major software vendors. The Build Anchor at SLSA Level 3, which is the level we recommend for any tool that runs autonomously in production, requires that the build is performed by a hosted build service, that the build is performed in an ephemeral environment, that the source is provided by the build service from a trusted source, and that the resulting attestation is non-falsifiable. SLSA Level 4 adds reproducibility and full hermeticity. We recommend Level 3 as a starting point and Level 4 as the target for tools that handle high-stakes data or actions.

The attestation format is JSON, includes the artifact hash, the source identity, the builder identity, the build parameters, the materials consumed, and a signature. The signature is from the builder's key, which is bound through Sigstore or an internal CA to a specific build service identity. The attestation can be stored anywhere; what matters is that it is retrievable and verifiable at deployment time, and that the deployment system refuses to load any artifact whose attestation does not verify.

The operational cost here is the highest in the three-anchor model. Reproducible builds, hermetic environments, attestation pipelines: all of these are real engineering investments. We do not recommend doing them all at once. We recommend starting with non-reproducible attestations at SLSA Level 2, getting the manifest schema and the verification pipeline in place, and then incrementally tightening: hermeticity in month two, reproducibility in month three, full Level 4 by month six. The intermediate states are still much better than no provenance at all, and they let you stage the engineering work without blocking everything else.

The Identity Anchor Deep Dive

The Identity Anchor is the smallest of the three in implementation effort and the largest in cultural impact. The mechanism is simple: every release of every tool is signed by an identifiable human or service. The signature is over the artifact hash, the Source Anchor, the Build Anchor, and a release statement that captures the intent. The signature is verified at deployment, recorded in the immutable log, and surfaced in the runtime metadata that operators see. The result is that for every tool running in production, you can ask: who released this version, when, and what did they say about it?

The cultural impact comes from making release a deliberate act with a name attached. In most current systems, releases are pushed automatically by CI pipelines, with no human signature involved. The good thing about this is throughput; the bad thing is that nobody owns the release. When something goes wrong, the question of who decided to ship this gets a procedural answer (the CI pipeline did it because the tests passed) instead of a personal one (Sarah decided this version was ready). The Identity Anchor moves the decision back to a person. It does not slow the throughput much in practice, because a single signing operation is fast, but it changes the meaning of the act.

The mechanism we use is hardware-backed signing keys, scoped to specific releaser identities, with a short-lived signature certificate from an internal CA. The signing operation is initiated through a signed request from an authenticated user, the operation produces an attestation that includes the user's identity, the request is logged in a tamper-evident store, and the resulting signature is published alongside the artifact and its other attestations. The hardware backing is important because it makes signing-key theft significantly harder; the short-lived certificate is important because it limits the blast radius of any individual signing operation; the logging is important because it makes the act observable to anyone with audit access.

The second pattern we use is delegated signing for high-volume tools. For tools that release frequently enough that every release does not warrant individual human attention, the human releaser delegates signing authority to a service identity, scoped narrowly: this service can sign releases of this specific tool, from this specific build pipeline, for the next 30 days. The delegation itself is a signed attestation, with all the same evidence requirements as a release. This pattern preserves the human accountability at the level of the delegation while allowing automated signing at the level of individual releases.

The third pattern, and the most important, is multi-party release for high-stakes tools. For tools that handle financial transactions, customer credentials, or other high-stakes contexts, no single human can release. The release requires signatures from at least two identities in the releaser set, neither of whom can be the same as the build pipeline operator. This is the same logic as multi-signature wallets in the cryptocurrency space and dual control in conventional banking. The point is to make catastrophic releases require collusion, which is much harder to achieve than individual compromise.

The Tool Provenance Manifest Schema

The artifact this post promised is a Tool Provenance Manifest Schema. The schema is what registrants submit when they want a tool listed in the registry, what runtime systems verify before loading the tool, and what auditors query when they need to trace a deployment. The schema below is the canonical version we use; teams adopting it should treat it as a starting point and extend it for their own contexts.

The top-level schema has six required fields: tool_id, version, source_anchor, build_anchor, identity_anchor, and capability_declaration. The tool_id is a globally unique stable identifier, not a name; names change, IDs do not. The version is a semver string, with the caveat that semver alone does not convey provenance and must always be paired with the anchors. The capability_declaration is the structured statement of what the tool needs to do its work, which is the subject of a separate post but which has to live in the same manifest because the anchors and the capabilities need to be co-attested.

The source_anchor object has four required fields: repository_url, commit_sha, branch_policy, and signature. The repository_url is the canonical URL of the source repository. The commit_sha is the full hash, never abbreviated. The branch_policy is a reference to a named policy that defines which branches and which commit types are eligible for release. The signature is over the other three fields, with the signing key in a known trusted set.

The build_anchor object has six required fields: builder_id, build_pipeline, build_parameters, materials, artifact_hash, and slsa_attestation. The builder_id identifies the build service. The build_pipeline references a named pipeline definition. The build_parameters captures the inputs to the specific build run. The materials lists every input consumed during the build, each with its own hash and source. The artifact_hash is the hash of the produced artifact. The slsa_attestation is the SLSA-formatted attestation document, signed by the builder's key.

The identity_anchor object has five required fields: releaser_identity, release_statement, signing_certificate, signed_at, and dual_signers. The releaser_identity identifies the human or service who released this version. The release_statement is a structured statement of the release intent, including the user-visible changes and any policy implications. The signing_certificate is the short-lived certificate used for the signing operation. The signed_at is the timestamp. The dual_signers is an optional list of additional signatures required for high-stakes tools.

The complete manifest is signed by the registrant's key, stored in the registry, and replicated to a public log for transparency. Verification of the manifest at registration time runs all of the anchor checks described in earlier sections. Verification at deployment time re-runs the artifact_hash check and the validity of the signing certificates. Verification at runtime re-checks the in-memory representation against the deployed hash. The schema is not large; it could fit on a printed page. Its value is that everyone agrees on what it contains, what each field means, and what the consequences are of each field being missing or invalid.

Counter-Argument: Is Provenance Worth The Friction?

The counter-argument we hear most often runs as follows: provenance is great in theory but the friction of implementing it kills development velocity. Engineers will route around the controls, register tools without proper anchors, and the security team will end up with a strict policy on paper and a lax reality in practice. Better to have a few practical controls that everyone follows than an aspirational regime that nobody respects.

We take this argument seriously because we have seen it play out badly in real organizations. The right response is not to abandon provenance but to design for adoption. Three specific design moves matter. First, make the tooling do the hard work. Engineers should not have to assemble Source Anchors and Build Anchors and Identity Anchors by hand. They should run a single command or click a single button, and the tooling should produce the manifest. If the engineer has to do more than one extra step compared to the old workflow, the workflow will not be adopted. Second, fail closed but informatively. When a registration fails because of a missing anchor, the failure message should explain exactly what is missing, why it matters, and how to fix it. Cryptic security errors lead to workarounds. Specific actionable errors lead to fixed bugs. Third, start with the highest-stakes tools and expand outward. Trying to enforce full provenance on every script in the organization on day one is the road to revolt. Starting with the agent tools that touch customer data or financial systems, getting the regime working there, and expanding incrementally is the road to durable adoption.

The second counter-argument is that public attestations leak information about your build pipeline that adversaries can use. There is some truth to this, but it is mostly a managed risk. The attestations do reveal the build service, the broad shape of the pipeline, and the source repositories. They do not reveal credentials, internal addresses, or anything that an attacker could not learn through other means. The benefit of having external auditors and customers verify your provenance vastly outweighs the modest information disclosure. We recommend public attestations for any tool that customers will rely on, and private attestations only for tools that are entirely internal.

What Armalo Does

Armalo's skill registry treats provenance as a first-class requirement. Every skill listed carries a Three-Anchor Provenance manifest in the schema above. Source, Build, and Identity Anchors are verified at registration, at deployment, and through periodic runtime checks. Manifests that fail any anchor check are rejected; tools without complete provenance cannot earn a certification tier above Bronze. The behavioral pacts that govern skill behavior reference the manifest, so a pact violation can be traced back to the exact build that produced the violating artifact. Composite scores incorporate provenance quality as a measured dimension; a tool with weak provenance scores lower regardless of its functional quality. The Trust Oracle exposes provenance metadata at /api/v1/trust/, so any third party deciding whether to use a skill or hire an agent that uses a skill can verify the chain themselves. The point is not that we have invented provenance; the point is that we have made it queryable, programmable, and economically meaningful.

FAQ

Do I need all three anchors, or can I start with one? You can start with one but you should know that one anchor alone is not provenance. The Source Anchor without the Build Anchor leaves the door open for substitution attacks. The Build Anchor without the Source Anchor leaves you with no idea what you are building. The Identity Anchor without the others is just a name attached to a stranger. Start with Source, add Build, then Identity, in that order, but plan for all three.

What does SLSA Level 3 cost in engineering time? For a team that has not done this before, expect six to eight engineering weeks for the initial implementation, plus two to four weeks of tooling investment per language ecosystem you support. The cost is amortized across every tool you ever build after that.

Do reproducible builds require us to rewrite our build pipelines? Probably not from scratch, but most teams will need to make significant modifications. The most common changes are pinning all inputs more tightly, adding hermeticity to the build environment, stripping non-deterministic outputs from the build process, and adding the attestation generation step to the end. The work is real but it is well-documented in the SLSA and Sigstore communities.

What happens when a Source Anchor's signing key is compromised? You revoke the key immediately, audit all attestations signed by that key during the period of compromise, re-issue attestations for any tool that should remain in production, and update the trusted source-key set to exclude the revoked key. The revocation propagates through the verification pipeline; tools whose attestations no longer verify cannot be loaded.

Is provenance enough, or do I still need other security controls? Provenance is necessary but not sufficient. It tells you where the code came from and who signed it. It does not tell you whether the code is safe to run, whether it has bugs, or whether it has been adversarially designed. You still need code review, sandbox isolation, runtime monitoring, and the other controls in the broader supply chain security toolkit. Provenance is the foundation that makes the other controls meaningful.

How do I provenance third-party tools whose authors do not provide attestations? You either persuade them to provide attestations, you build attestations yourself by treating their code as your input source and running it through your own attested build pipeline, or you do not run their tools in production. The third option is often the right one in 2026 and will be increasingly common as the standards mature.

Can the Identity Anchor be a service identity instead of a human? Yes, with the caveats described above. Service identities are appropriate for high-volume releases where the human accountability is at the delegation level rather than the individual release level. For high-stakes releases, the Identity Anchor should be a human, and ideally multiple humans through dual signing.

Is the Tool Provenance Manifest Schema published anywhere? Yes, as part of the Armalo registry's public schemas. We are also collaborating with several other registries on a common schema that would allow cross-registry portability of provenance attestations. The space is moving and we expect convergence within a year.

Bottom Line

Provenance is the answer to a question that customers will start asking soon and that you should already be able to answer: where did this tool come from? The Three-Anchor model gives you a structure for the answer that is auditable, verifiable, and resistant to the most common attacks. The audit pattern gives you the operational discipline to maintain provenance over time. The manifest schema gives you a concrete artifact you can adopt this week. The friction is real, the engineering investment is real, and so are the consequences of running tools whose origins you cannot prove. In a year or two, the agent platforms that have provenance will be the only ones that enterprise customers can buy. Build for that future now.