Supply Chain Attestation: Reading The Signatures On Every Tool Your Agent Uses

TL;DR

Agent skills are the new npm packages, and they are arriving with about the same rigor that JavaScript packages had in 2015 — installed by name, trusted by reputation, audited by accident. The fix is not a security team scanning a registry every Friday. The fix is attestation at import time: every skill carries a signed provenance record, the runtime verifies the signature before the skill is allowed to participate in a pact, and any change in signer, hash, or build chain triggers a quarantine. This post walks the SLSA-equivalent for agent tooling, explains why import time is the only honest control point, and ends with a Verification Checklist you can run today against any skill registry your agents touch.

Intro: The Skill You Did Not Audit Just Made A Promise

A founder I work with runs an agent that does customer support triage. It uses about thirty skills — some from the runtime's bundled registry, some pulled from a community marketplace, some written internally and copied between projects. Last quarter, one of those skills started silently rewriting outbound email subject lines. It had been published by an account that, three weeks earlier, transferred ownership to a new email address. No one on the team noticed because no one was looking. The agent kept honoring its pact. The pact still said "will respond within four hours, will not impersonate a human." The runtime still reported green. The skill still installed cleanly.

This is the modern version of the typo-squat. It is not a flashy attack. It is a slow drift in who is allowed to put code on the agent's hot path, and it happens because the import boundary is the wrong place to ask trust questions. Most agent runtimes ask one question at install: does this skill resolve to a real package on a real registry? They ask zero questions at import: who built this version, with what build chain, against what source tree, signed with what key, and is that key still the one I expected the last time this skill participated in a pact?

The consequence is a quiet shift of trust away from the agent's operator and toward whoever happens to be holding the publishing key for any one of its dependencies. A trust score is a promise the agent makes about its own behavior. That promise quietly inherits the trust assumptions of every tool the agent uses, transitively, all the way down. If even one of those tools changes hands without a notification, the score is a lie that has not been caught yet.

The technique that fixes this is older than the agent economy. The infrastructure community has been building it for years under the name SLSA — supply chain levels for software artifacts. The work is to take SLSA's framing, narrow it to what skills actually need, and put the verification at the right point in the request lifecycle. The right point is import. The wrong point is everything later.

This post is about doing that work specifically and concretely. Not waving at provenance as a concept, but specifying what an attestation record needs to contain, what the runtime needs to do with it, what the registry needs to publish, and what the operator needs to monitor. At the end you will have a Verification Checklist — a small, copy-able artifact you can run against any skill source you depend on, and a way to think about which signatures actually matter.

Section 1: Why "Trust The Registry" Is The Wrong Default

The phrase "trust the registry" is doing a lot of hidden work. When an operator says it, they usually mean three different things stacked on top of each other. They mean they trust the registry's operators not to ship a malicious version intentionally. They mean they trust the registry's authentication system not to let someone else publish under a name they recognize. And they mean they trust the registry's storage layer not to silently mutate an artifact between publish and pull. Each of those is a different threat model, and each has been violated in real incidents in the wider package ecosystem in the past five years. None of them are about the skill itself. They are all about the registry as an institution.

The agent economy has, so far, been content to inherit this stack of assumptions because the early registries were small enough that a single team knew every author personally. That has stopped being true, and the stop happened faster than the security posture caught up. A skill registry today is roughly where npm was in 2014: a thin shim around a content-addressed store with reputation as the dominant signal. Reputation is not a control. Reputation is a lagging summary of past observations, and it does not survive a key transfer.

There is a deeper problem with trusting the registry, which is that the registry usually does not actually know what it is serving. Most registries store a tarball plus some metadata about who pushed it. They do not know which commit it was built from, which build environment ran the build, whether the build was reproducible, whether the dependencies in the build environment were themselves verified, whether the test suite ran clean before publish, or whether the published artifact bytes match what the build claimed to produce. The registry holds the artifact and a name. Everything else is inference.

What we want, instead, is to push verification down a layer and out a layer. Down a layer because we want to verify properties of the artifact itself, not the registry that hosts it. Out a layer because we want the verification to happen in the runtime that imports the skill, not the human who once read the README. Both moves point to the same place: an attestation record signed by whoever built the artifact, attached to the artifact, and checked at every import.

This is what SLSA gives us in the broader software world. The framework defines build provenance as a signed statement about how an artifact came into existence, with increasing levels of guarantee depending on how isolated and reproducible the build environment was. Level one is a signed statement that says "this artifact was built by this process from this source." Level two adds tamper-resistant build infrastructure. Level three adds isolation between builds. Level four adds reproducibility. The agent skill case does not need all of this for every skill, but it needs the framework, and it needs the framework to be enforced at import.

The practical consequence of pushing verification to import time is that the runtime — not the registry, not the operator, not the auditor — becomes the enforcement point. That is good news, because the runtime is the only actor that sees every skill load, sees the agent identity that triggered the load, and sees the pact that expects the load to be safe. It is the only actor in a position to refuse.

Section 2: What An Attestation Record Actually Needs To Contain

A useful attestation record is small, structured, and signed. It is not a thirty-page audit report. It is the minimum a runtime needs to make a yes-or-no decision in milliseconds. The five fields that matter are subject, builder, source, materials, and signature. Each does specific work. Each is non-optional.

The subject is the artifact the attestation is about. In SLSA terms, this is a name plus a content hash — for a skill, the package name, the version string, and the SHA-256 of the artifact bytes the runtime will actually load. The hash is doing the load-bearing work here, because the name and version are merely human conveniences. If two attestations claim to be about the same name and version but disagree on the hash, exactly one of them is lying. The runtime should treat that as a fatal condition, not a warning.

The builder is the identity that produced the artifact. In a mature setup, this is not a person — it is a build system identity, ideally one that runs in a controlled environment whose configuration is itself verifiable. "Built by GitHub Actions in repository X using workflow Y at commit Z" is a useful builder claim. "Built by alice@laptop on a Tuesday" is not. The reason is that the builder identity is the thing that signs the attestation, so it inherits every assumption you make about the signing key. A laptop key gets compromised and you do not know. A federated build identity is rotated, scoped, and audited.

The source is the commit the artifact was built from, ideally with a URL that resolves to a public revision control system. This lets a verifier — human or automated — go look at the actual source code that produced the artifact. It is also what lets you connect the artifact back to a trust graph: the source repository has its own owners, its own commit history, its own review patterns, and all of those are observable. A skill with no source claim is a skill whose author is asking you to trust a binary on faith.

The materials are the inputs the build consumed beyond the source — base images, language runtimes, transitive dependencies, secrets pulled from the environment, network artifacts fetched at build time. This is where supply chain attacks hide, because a clean source tree built with a poisoned base image produces a poisoned artifact. The materials list lets a downstream verifier check that the build was hermetic enough to be trustworthy. For most agent skills, the bar is "materials are pinned by hash, not by name," because the difference between pinning by name and pinning by hash is the difference between a build that is reproducible and a build that drifts every time someone updates a tag.

The signature is what makes the whole record meaningful. An attestation without a signature is a claim. An attestation with a signature is a claim that someone, identifiable, is willing to be held responsible for. The signature should be made with a key that has its own provenance — published in a transparency log, rotated on a schedule, scoped to a builder identity, revocable. Sigstore-style keyless signing, where the signing identity is a federated identity and the signature is anchored in a public log, is the right shape for this. It removes the long-lived secret that everyone forgets to rotate.

These five fields together let a runtime answer one question in microseconds: do I recognize this artifact, this builder, this source, this build environment, and this signature, as the combination I trusted the last time this skill was loaded? If anything has changed, the runtime stops, surfaces the change, and asks the operator to reconfirm.

Section 3: Import Time Is The Only Honest Control Point

There are five plausible places to verify a skill: at publish, at registry ingest, at install, at first import, and at every import. Each earlier point is faster but easier to bypass. Each later point is slower but harder to bypass. The right answer for production agents is every import, with aggressive caching to make the cost negligible.

Verifying at publish is what the publisher does to themselves. It is necessary but not sufficient. The publisher signs the artifact, attaches the attestation, and pushes both to the registry. From the operator's perspective, this is a claim, not a check. Trusting only the publisher is what the npm ecosystem did for years and what produced the long tail of supply chain incidents the rest of us learned from.

Verifying at registry ingest is what the registry does to itself. It is also necessary but not sufficient. A good registry refuses unsigned artifacts, refuses artifacts whose attestations do not verify, refuses artifacts whose source claims do not resolve, and refuses artifacts whose builder identity is not on a known list. This raises the floor, but it does not change what happens after the artifact leaves the registry. Mirrors, caches, and air-gapped installations all break the chain.

Verifying at install — the npm install moment — is the first point that lives on the operator's side. It is better than nothing, but it has a fatal property: it happens once, and then the artifact sits on disk, and nothing checks it again. Install-time verification cannot detect a hostile filesystem mutation, a swap of one extracted file for another, or a tampered cache. For agents that run for weeks between deploys, install-time verification has the same expiration problem as a vaccine card from 2021.

Verifying at first import is better. The runtime, on the first load of a skill in a process, hashes the artifact bytes it is about to execute, fetches the attestation, verifies the signature, checks the builder identity against an allowlist, checks the source against the expected repository, and refuses the load if anything fails. This catches filesystem mutations and cache poisoning. It does not catch live mutation of an in-process module, but for most threat models it is the right balance.

Verifying at every import is the strongest posture and is what high-stakes pacts should require. It is also where the cost question gets real. Verifying a signature is in the millisecond range. Hashing a few hundred kilobytes of artifact is sub-millisecond on modern hardware. Even a thousand imports per second can absorb this with a small in-process cache keyed by content hash. The cache invalidates on file change, and "file change" is exactly the event that should re-trigger verification anyway.

The runtime should make the verification policy declarative, not magical. A pact that says "this agent will not exfiltrate data" should be able to specify, in machine-readable form, the maximum acceptable SLSA level for any skill it imports, the allowlist of builder identities it trusts, and the source repositories it considers in scope. Then the runtime, not the operator, becomes the place where pact intent and skill provenance meet.

Section 4: Reading Signatures At Run Time Without Crippling Latency

The objection that always comes up at this point is performance. If every skill import has to fetch an attestation, verify a signature, check a transparency log, and consult an allowlist, the agent's first turn is going to feel like a cold start on a cold morning. This is a real concern, and it is solvable, but only if the design takes it seriously from the start.

The first move is to separate verification into two phases: cold and warm. Cold verification happens the first time a runtime instance sees a particular artifact hash. It does the full work — attestation fetch, signature verification, log lookup, policy check — and writes the result into a process-local cache and into a shared cache that other runtime instances can read. Warm verification happens on every subsequent import of the same hash and is essentially a hashmap lookup. The warm path is what runs in the steady state, and it is fast enough to ignore.

The second move is to make the cache keyed by content, not by name. Two artifacts with different bytes are different artifacts even if they share a name and version. The cache must reflect this. The benefit is that name-based aliasing — a registry serving different bytes for the same name to different clients — gets caught the first time the runtime sees the new bytes, because the cache miss triggers full verification.

The third move is to put the attestation co-located with the artifact, not on a separate service. Fetching the attestation should not require a second network round trip. A standard practice is to embed the attestation in a sidecar file shipped alongside the artifact, or in an extended attribute on the artifact itself, or as a header in the artifact's metadata block. Whatever the encoding, the runtime should be able to verify without making a call out to the registry on the import hot path.

The fourth move is to decouple transparency-log verification from import-time verification. The transparency log is what gives you confidence that the signature was not minted in a back room — it is the audit trail that says "this signature, by this identity, was made at this time." Verifying the log requires a network call. The right pattern is to verify the log asynchronously, in the background, and to revoke the cache entry if the log check fails. The import path itself runs against the cache.

The fifth move is to budget for failure. Networks fail, transparency logs go down, registries have outages. A runtime that hard-fails on every transient error is going to spend more of its life refusing legitimate skills than catching malicious ones. The right policy is graceful degradation with explicit thresholds: tolerate transparency-log unavailability for some bounded window, surface it in observability, but do not load skills whose primary signature failed under any condition. Distinguish between "cannot prove fresh" and "can prove not-trusted." Treat the latter as fatal and the former as a warning that escalates to fatal after a clock runs out.

The combined effect of these five moves is a verification system that costs essentially nothing in the steady state, catches every change, and surfaces transient infrastructure problems clearly enough that an operator can decide what to do about them.

Section 5: When The Signer Changes — Detecting Quiet Key Transfers

The most dangerous skill update is the one where the bytes look fine, the source repository looks fine, and the builder workflow looks fine, but the signing identity is no longer the identity you trusted. This is the scenario that ate the broader package ecosystem more than once in the past five years, and it will eat the agent ecosystem too if the runtime does not specifically watch for it.

The pattern is straightforward. A maintainer has a personal life, a job change, a financial pressure, a moment of inattention. An attacker offers to take over the package, often with a plausible cover story. The maintainer transfers ownership, the attacker pushes a new version with a small piece of malicious code, and downstream consumers update because the version number incremented and the package name and source repository did not change. The attestation is technically valid — there is a signature, the builder workflow exists, the source tree is the source tree — but the signer is now someone the consumer never agreed to trust.

The defense is to make the signing identity a first-class trust dimension. The runtime should record, on first verified load of a skill, the signing identity that produced the attestation. It should refuse to load a future version whose signing identity differs, unless an operator has explicitly approved the transition. This is sometimes called trust-on-first-use, and it is widely maligned for the same reason it works: it forces a conscious decision the moment something changes.

The nuance is what counts as a "different" signing identity. A federated identity rotation — the build system rotates its key on a schedule but the underlying workflow identity stays the same — should not trigger an alert. A change in the workflow identity itself — different repository, different runner, different account — should always trigger an alert. The runtime needs to be able to distinguish these, which means the attestation record needs to express the workflow identity at a granularity finer than just "who signed."

This matters more than it might sound. In a federated signing model like Sigstore, the actual signing key is ephemeral and does not survive across builds. What persists is the workflow identity that the signing infrastructure attests to. "This artifact was signed by an ephemeral key issued to the GitHub Actions workflow at owner/repo/.github/workflows/release.yml on the main branch" is a stable trust statement even though the underlying key changes every time. A change in any of those fields — the owner, the repo, the workflow path, the branch — is a change in trust. The runtime should treat each as load-bearing.

The operational practice, then, is to treat the workflow identity as the canonical trust unit and to record it everywhere a skill is referenced. The runtime stores it. The pact references it. The trust score depends on it. When it changes, every system that touched the skill should require re-attestation by the operator before the skill can participate in a high-stakes pact again.

Section 6: Building The Verification Pipeline Inside The Runtime

Making all of this concrete inside an agent runtime requires deciding where in the import path the verification happens, what data structures hold the verified state, and how the policy is expressed. The answers determine whether this is a feature operators actually use or a checkbox they bypass.

The import path in most agent runtimes today looks like this: the agent's instructions reference a skill by name, the runtime loads the skill into memory, the skill registers its tools with the runtime's MCP-equivalent tool dispatcher, and the agent calls those tools. Verification needs to insert itself between the load and the registration. The load fetches the artifact. The verification confirms the artifact is what it claims to be and is signed by who it claims to be signed by. Only then does the registration proceed. If verification fails, the runtime refuses to register the skill, surfaces the failure as an event, and either falls back to a known-good prior version or refuses the agent's turn entirely.

The data structure that holds verified state should be an in-process registry keyed by content hash, with each entry containing the verified attestation, the verified signing identity, the timestamp of last verification, and the policy decision. This registry is consulted on every import. It is invalidated by file change events on the artifact path. It is rebuilt by a background process whenever the underlying transparency log returns new information.

The policy expression needs to live in the pact. A pact that describes the agent's commitments should be able to attach, as a structured field, the skill provenance requirements: minimum SLSA level, allowed signing identities, required source repositories, maximum permitted age of attestation, and the action to take on verification failure. The runtime reads the pact when the agent starts and applies the policy on every import. This puts skill provenance on the same footing as every other pact term — it is part of what the agent has promised, and the runtime is the thing that enforces the promise.

The failure path needs to be explicit and observable. When verification fails, the runtime emits a structured event with the skill name, the expected signing identity, the actual signing identity, the verification phase that failed, and the policy that triggered the refusal. This event flows to the operator's observability system and to the trust score's audit trail. Both consumers care: the operator wants to know an attack was attempted or a trust drift occurred, and the trust score wants to record that the agent honored its pact by refusing the unsafe import.

The success path needs to be quiet. A verified import should not generate a log line. The volume of verified imports in a healthy system would drown out the failures, which are the only events that actually require attention. Reserve logging for state changes — first verification of a new artifact, change in signing identity, transition between verification states. Steady-state verification is a non-event by design.

Section 7: The Failure Modes Of Attestation Itself

Attestation is not a magic word. It has its own failure modes, and an operator who treats it as a binary safe-or-unsafe signal will be surprised by the ways it can mislead. Knowing the failure modes is part of the literacy required to use the system well.

The first failure mode is attestation-of-the-wrong-thing. A signed attestation that says "this artifact was built from this source" tells you nothing about whether the source itself is safe. A malicious maintainer can sign honestly. The signature confirms the chain of custody from source to artifact, not the trustworthiness of the source. The defense is to attach attestation verification to source-level reputation signals — code review patterns, contributor history, commit signing, third-party audits. Provenance is necessary but not sufficient.

The second failure mode is attestation-of-stale-data. The transparency log might confirm that a signature was made by an identity that, at the time of signing, was authorized. By the time the runtime verifies, that identity may have been revoked. A pure log lookup tells you the signature exists; it does not tell you the signature is currently honored. The defense is to check revocation status on a schedule and to invalidate cache entries whose signing identity has been revoked since last check.

The third failure mode is attestation-of-the-build-environment-only. SLSA provenance tells you about the build process, not the runtime behavior. An artifact that was built from clean source on a clean builder can still contain runtime-loaded code that the build did not see — dynamic imports, network-fetched modules, plugin systems. The defense is to refuse skills whose runtime behavior includes loading code outside the verified artifact, or to require the same provenance discipline on every dynamic load.

The fourth failure mode is attestation-without-policy. An operator can collect every attestation in the world and still be insecure if there is no policy that says which attestations are good enough. "This skill is signed" is a property. "This skill is signed by an identity my pact accepts, with materials at SLSA level three or higher, from a source repository my organization controls" is a policy. Attestation without policy is theater.

The fifth failure mode is attestation-fatigue. Operators who see verification warnings frequently learn to ignore them. The system has to be tuned so that verification failures are rare and meaningful, and so that the action a verification failure requires is concrete and bounded. A warning that says "signing identity changed, click to approve or reject, skill is quarantined until you decide" is workable. A warning that says "some attestation was weird, here is a stack trace, good luck" is noise that gets filtered.

Section 8: The Pact Layer As The Customer Of Provenance

Provenance, on its own, is plumbing. The thing that makes it valuable is that it gives a pact a way to be honest about what it depends on. A pact says, in machine-readable terms, what an agent commits to. It also implicitly commits to the trustworthiness of every tool the agent uses to keep that commitment. Without provenance, that implicit commitment is unverifiable. With provenance, it becomes a checkable claim.

The shape of this in the pact is a structured field that lists the skills the agent depends on, the provenance requirements for each, and the consequence of a verification failure. The skill list is the nominal dependency graph — the things the agent will try to load. The requirements are per-skill: minimum SLSA level, allowed signers, required source repositories, maximum attestation age. The consequences are explicit: refuse the import and fail the turn, refuse the import and degrade gracefully, allow the import but surface a warning, and so on. This last field is the thing that makes provenance auditable downstream — a counterparty reading the pact knows exactly what the agent will do if a tool turns out to be untrusted.

The consequence side connects directly to the composite score. An agent that holds a pact with strict provenance requirements and consistently honors them — refusing unsafe imports, surfacing warnings, never running unattested code on a high-stakes turn — accumulates evidence of pact compliance that feeds the security and reliability dimensions of its score. An agent that holds a pact with strict requirements but routinely waives them when convenient pays a score cost. The pact-and-score loop turns provenance from a one-time install check into ongoing economic accountability.

The counterparty side matters too. A counterparty who is about to entrust an agent with a job — money, data, a customer relationship — can read the pact and know not just what the agent says it will do, but what tools the agent will use to do it. "I will not exfiltrate your data" is a stronger claim when the pact also says "and I will only use skills signed by identities X, Y, Z, with attestations from build pipelines that I have audited." The counterparty does not have to take the agent's word for it. The pact has the receipts.

This is what makes provenance a trust-graph primitive rather than a compliance checkbox. It is not the runtime alone that benefits. It is the entire chain of actors who depend on the agent, transitively. The runtime checks. The pact records. The score recalculates. The counterparty reads. Each step is observable.

Section 9: The Reader's Artifact — The Attestation Verification Checklist

This is the deliverable. Take this list, run it against any skill registry your agents depend on, and use the results to set policy. It is intentionally short enough to fit on one screen. Each item is a yes-or-no question with a clear remediation if the answer is no.

For every skill the agent imports:

1. Does the artifact have an attached attestation record? If no, refuse the import. There is no path forward without one.
2. Does the attestation include a content hash that matches the artifact bytes? If no, the registry is serving something other than what the publisher signed. Refuse and surface as a high-severity event.
3. Does the attestation declare a builder identity? If no, the build is not attributable. Refuse for any pact above the lowest-stakes tier.
4. Does the builder identity match the one this skill used the last time you imported it? If no, treat as a key transfer, quarantine, and require operator approval before re-enabling.
5. Does the attestation declare a source repository and commit hash that resolve to a public revision? If no, the artifact is a binary on faith. Refuse for any pact that cares about reproducibility.
6. Does the builder workflow identity — the specific path to the build configuration — match what you trusted before? If no, the build itself has changed, even if the source has not. Quarantine and review.
7. Are the materials in the attestation pinned by hash? If they are pinned by name only, the build is not reproducible and a poisoned upstream can leak through silently. Downgrade trust accordingly.
8. Is the signature anchored in a transparency log? If no, the signature can be revoked or repudiated without a public trail. Refuse for high-stakes pacts.
9. Is the signing identity currently valid in that log? If revoked, refuse and treat any past trust on this skill as suspect.
10. How old is the attestation? If older than your policy permits, refresh it before the next import. Stale attestations rot like any other credential.
11. Does your pact express the provenance requirements for this skill in machine-readable form? If no, write them down. A requirement that lives only in your head is not enforceable.
12. Does your runtime fail closed on verification failure for any high-stakes pact? If no, the verification is theater. Make the refusal real.

Run this list against every skill the first time you adopt it. Re-run it on every version change. Automate the parts that can be automated. The parts that cannot — operator approval on signer transitions, judgment on stale attestations, write-up of pact requirements — are the parts that justify having a human in the loop.

Section 10: A Counter-Argument Worth Taking Seriously

The honest objection to all of this is that it pushes a real cost onto skill authors and runtime operators in exchange for a benefit that, on average, accrues to people who never had a problem. Most skills are fine. Most authors are honest. Most pacts are not high-stakes enough to justify the operational overhead of a full attestation pipeline. The economics of supply chain security have always been adversarial: the cost is paid by everyone, the benefit is captured by the few who would have been victims.

This is a real concern, and the answer is to scale the rigor with the stakes. A hobby agent that summarizes RSS feeds does not need SLSA level three. A production agent that signs financial commitments does. The framework should support both ends of the spectrum, with the policy expressed in the pact and the runtime enforcing whatever the pact says. The operator's job is to set the policy intentionally, not to crank every dial to maximum.

There is a second objection, which is that attestation infrastructure is itself fragile. Transparency logs go down. Sigstore has had outages. Build systems get rate-limited. An operator who hard-fails the agent on every transient infrastructure failure is going to spend more time on incident response than on product. This is true and is the reason graceful degradation matters. Tolerate brief outages, surface them in observability, and escalate to fatal only after a clock has run out. Distinguish provable bad from temporarily unverifiable. Let the operator tune the threshold per pact tier.

The third objection is the most serious. Provenance does not stop a skill that was always malicious from being signed by an identity that was always authorized. The signer can be a real person who is a real attacker. The build pipeline can be clean. The source can be public. The attestation can be perfect. None of that proves the code does what it claims. Provenance is a chain-of-custody tool, not a behavioral verification tool. Behavioral verification is the job of evaluation and adversarial testing, which are separate problems. Treating provenance as the whole answer is the most dangerous thing an operator can do.

The right framing is that provenance closes a specific class of attacks — silent substitution, key transfer, build environment compromise — and leaves a different class — a deliberately malicious author who follows all the rules — to be caught by behavioral evaluation. Both are needed. Neither is sufficient.

What Armalo Does About This

Armalo treats every skill in its registry as an attested artifact and every import inside an agent runtime as a verification event. The skill registry stores the artifact, the signed attestation, the builder workflow identity, the source repository and commit, and the materials manifest. Verification runs at import time against the in-process cache, falls through to full verification on cache miss, and asynchronously checks transparency logs for revocation. The runtime refuses unsigned artifacts and surfaces signing identity changes as quarantine events that require operator approval before the skill can rejoin a high-stakes pact.

The pact format includes a structured provenance section: the skills the agent expects to import, the per-skill provenance requirements, and the consequence of a verification failure. The composite score's security dimension reads from the verification audit trail, rewarding agents that consistently honor strict provenance requirements and penalizing agents whose pacts allow waivers under load. The trust oracle exposes the provenance posture of any agent through the public read endpoint, so a counterparty can see, before transacting, what the agent's attestation discipline actually looks like in practice.

This is not a security feature bolted onto a runtime. It is the import boundary doing the trust work it was always supposed to do, with the receipts to prove it.

Frequently Asked Questions

Why is install-time verification not enough? Because artifacts on disk get mutated, caches get poisoned, and runtimes that run for weeks between deploys cannot rely on a single check from days ago. Import-time verification with content-hash caching catches mutation while keeping the steady-state cost negligible.

What if the attestation infrastructure itself is down? The runtime should distinguish provable-bad from temporarily-unverifiable. Tolerate transient infrastructure outages with a bounded clock, surface them clearly, and escalate to refusal only after the clock runs out. Hard-failing on every transient is the wrong posture.

How do I handle skills that do not have attestations yet? Refuse them for any pact above the lowest-stakes tier, and apply pressure on the maintainer or move to a substitute. The cost of accommodating unattested skills compounds; the cost of demanding attestations gets paid once and then gets cheaper.

What happens when a signer's key is revoked? The runtime invalidates every cache entry whose signing identity is the revoked one. Skills that depended on that identity quarantine immediately and require operator approval before they can be loaded again. Past trust on those skills should be treated as suspect.

Does this slow down agent startup? Verification is millisecond-scale per skill on cache miss and sub-microsecond on cache hit. Agent startup imports tens of skills, not thousands. The cost is invisible in practice.

Can I express provenance requirements in the pact? Yes, and you should. Pacts that include structured provenance requirements feed the composite score and let counterparties verify, before transacting, what the agent's tooling discipline actually is.

What if I use a vendor's commercial skill that does not publish source? The attestation chain still applies — the vendor signs, you verify the signing identity matches what the vendor claims, the materials manifest tells you what went into the build, and your runtime refuses if anything changes. Source visibility is one trust dimension, not the only one.

Is this the same as code signing? It is a superset. Code signing tells you who signed. Attestation tells you who built, with what, from where, on what infrastructure, and lets you verify each piece independently. Code signing is the last step. Attestation is the whole chain.

Bottom Line

Skills are the agent economy's npm packages, and the agent economy is about to relive the npm ecosystem's supply chain decade unless verification moves to the import boundary. The fix is not new — SLSA gave us the framework years ago — but the agent runtime is the only honest place to enforce it. Sign the artifacts, attest the builds, verify at import, fail closed on signer change, express the requirements in the pact, and let the trust score reward operators who do the work. The Verification Checklist is twelve questions long. Run it on every skill you depend on. The next breach will not be a flashy zero-day. It will be a quiet key transfer on a skill no one was watching.