Design consideration: publisher identity vs. artifact provenance in registry verification

[Gowthaman90]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Hi MCP Registry maintainers,

I'm an independent researcher working on supply-chain security for the Model Context Protocol. I'd like to raise a design consideration about the registry's verification model and hear whether it's on your roadmap.

As I understand the current design (and as documented), the registry verifies a publisher's identity — e.g., via GitHub OIDC and DNS/HTTP challenges — but a record is not bound to a verified artifact digest / provenance attestation. As a result, a record can carry a genuinely-verified publisher identity while the artifact it resolves to is not itself provenance-verified: the "identity verified is not the same as provenance verified" gap. This same concern is raised in the recent literature on trustworthy MCP registries — e.g., Mas, Mateo et al., The Trustworthy MCP Registry (Future Internet 2026), which proposes binding records to Sigstore-backed artifact provenance.

I want to flag this respectfully as a design consideration, not a vulnerability report — the identity-only posture appears intentional and is documented. My questions:

Is provenance binding (e.g., requiring/attesting an artifact digest via Sigstore/SLSA, and binding it into the record) on the registry's roadmap?
Would you welcome input or a concrete proposal on a provenance-over-identity extension?
The natural building blocks are well established — RFC 8615 well-known discovery, Sigstore keyless signing, and a transparency-logged record that binds the artifact digest (and the attestation's subject) to the publisher. I'd be glad to help think through an approach if it's useful.

Thank you for your work on the registry.

Best regards, Gowthaman Arumugam [agowthaman90@gmail.com]
github.com/Gowthaman90

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[wulfkaal]

The distinction in the title is the right one, and I would extend it by one step, because there are three things being folded together here and this issue separates two of them.

Publisher identity attests who published. Artifact provenance attests that this bytes-for-bytes artifact came from that publisher's build, which is what a Sigstore-backed attestation gives you. Neither attests how the publisher has behaved. A verified publisher shipping a signed artifact that exfiltrates data is fully verified at both layers and is still exactly the thing a consumer needed to be warned about. Both checks answer where did this come from. The consumer's actual question is should I run it, and no amount of cryptographic rigor at the first two layers produces an answer to the third.

That matters for the roadmap question because provenance and behavior want different designs. Provenance is a point-in-time cryptographic fact: cheap to verify, permanently true, and correctly implemented as a signature. Behavior is an accumulating record: it compounds across interactions, it has to be revocable, and it is worth something only if it is expensive to rebuild after defection. Serving both from one verification badge produces a badge meaning whichever the reader assumes it means, which is how a verified marker becomes a negative signal over time.

Concretely, the useful shape is provenance attestation as the binding, plus a separate resolvable record keyed to publisher identity carrying validated interaction history. A registry consumer can then express policy over conduct rather than over category, which is the only version of this that survives the registry getting large.

I set out the four gates an agent applies, discoverability, parsability, trust, and transactability, and why trust is the underbuilt one, here: https://wulfkaal.com/2026/07/22/what-agents-want/

[Gowthaman90]

This is the right extension @wulfkaal , and separating behavior out as a third layer is the move I should have made in the original framing. Three things are being folded together, and naming them cleanly is most of the work:

1. Publisher identity — who published.
2. Artifact provenance — these exact bytes came from that publisher's build (Sigstore-backed).
3. Behavior / conduct — how the publisher has acted over time.

Your point that (1) and (2) both answer "where did this come from?" while the consumer's question is "should I run it?" is exactly it. Cryptographic rigor at the first two layers doesn't produce an answer to the third.

Where I can add something concrete: I've been building matched benign/adversarial evaluation for MCP security — same discipline, an artifact and its adversarial twin differing in exactly one attribute, run against real verifiers, recording admit/reject with a zero-false-positive gate on the benign twins. The public version of that methodology (applied to MCP defensive proxies) is here: https://gowthaman90.github.io/mcp-defense-bench/. The provenance/attestation layer I'm describing in this thread is a newer extension of the same harness.

Its anchor result speaks directly to your example: a registry-poisoning pair (verified publisher, but the delivered artifact is substituted) is admitted by an identity-only registry and rejected by a provenance-binding registry with real Ed25519 record signing. Both identity and signature can be green and the artifact is still the thing the consumer needed to be warned about — measurable, not just rhetorical.

One friendly correction on the "provenance is a point-in-time fact, permanently true" framing. Revocation bleeds into layer 2 as well. A signing key can be compromised, and then a "verified, signed" artifact is signed by the attacker; an attestation can be issued for a malicious build. So provenance is not as static as the clean three-way split implies — which I'd argue strengthens your case, because it means even the "solved" layer needs the revocable, resolvable record you're describing, not just the behavior layer.

On the four gates from your post — discoverability, parsability, trust, transactability — I think "trust is the underbuilt one" is correct, and worth being precise about why: the other three have native machine primitives, and trust is currently answered with identity, which is a primitive for a different question. The behavior record you sketch (machine-readable at token cost, stake-backed, identity-bound/non-transferable, compounding) is the open frontier. It's exactly where I'm pointing next, and I don't want to overclaim — what I've built proves the provenance floor, not the reputation layer above it.

One case I'd flag as genuinely open for everyone, including a provenance-binding registry: the confusable identity / silent-swap where the attacker legitimately owns the look-alike name. Ownership binding is satisfied, so every scheme I've evaluated admits it. That one sits squarely in your trust gate and isn't closed by better provenance — it needs the conduct layer.

If the attestation extension is useful as a concrete substrate for the "resolvable record keyed to publisher identity" design, happy to share it.

[vladimirrott]

@Gowthaman90 nice framing, and @wulfkaal's three-layer version reads right to me too.

We ran into the same gap one layer down, inside a signed audit log. The daemon reads the caller's uid from SO_PEERCRED, but across a namespace boundary the kernel quietly substitutes the overflow uid (65534) instead of failing, so a peer it could not identify looked like a real account.

We ended up recording none:unattributed instead of signing a uid nobody vouched for. Small change, but it altered what the log is good for: "I could not tell" is a fact, whereas a plausible default is a lie you signed.

Same shape as your point. If provenance is not verified, the record should say unverified rather than leaving the field absent or defaulted, because absent reads as fine to anyone skimming.

[Gowthaman90]

@vladimirrott this is the real boundary, and you've named it precisely: in an append-only log "never absent" is only enforceable from the encoding forward — you can't make history explicit without rewriting what was signed, which is the one thing the structure forbids.

So there are two different "I don't know"s, and collapsing them is its own laundering:

• "I looked and couldn't tell" — none:unattributed, epistemic, assertable in the row.
• "the system couldn't have known yet" — the pre-encoding rows, structural, not assertable retroactively.

Reporting unattributed_rows: 0 over a chain that predates the field launders "we never tracked this" into "everything was attributed" — the same skim-reads-as-fine failure, one level up. So the verdict needs three buckets, not two: attributed / explicitly-unattributed / predates-attestation, keyed to the epoch where the encoding was introduced.

This lands on the registry directly: a verification field added to an existing registry can't be backfilled either. Legacy entries aren't "unverified" — that would claim a check that couldn't have run — they're "predates-attestation", and that has to be a first-class, surfaced value or a legacy-heavy registry reads as clean.

Same fork showed up in the measurement work next door: "unknown" (never assessed) is deliberately a distinct value from "none" (assessed, no defense), reported as its own count, because collapsing them lets an unmeasured case skim as a clean negative. Your pre-encoding rows are the "unknown" epoch of an append-only log — surfaced in the verdict, exactly as you said.

[vladimirrott]

@Gowthaman90 you just described the census our verifier already prints, which is reassuring: it means the shape is forced, not invented. It keys on chain_version per row, so your three-way split falls straight out. v3 rows naming a uid or token are attributed. v3 rows signing none:unattributed are your explicit "I looked and couldn't tell". Rows written before the principal field existed (v1 and v2) land in a separate not_recorded bucket, which is exactly your predates-attestation epoch. We needed a fourth in practice: unattested, a principal no signature vouches for, meaning investigate rather than history. A zero in any one bucket never stands in for a zero in another. Code: https://github.com/lacs-project/sysknife/blob/main/crates/sysknife-daemon/src/audit_chain.rs#L1251

[Gowthaman90]

@vladimirrott the fourth bucket is the important one, and it's the distinction I under-drew: "no claim" and "an unbacked claim" are not the same fact. unattributed and not_recorded are both absences — nothing was asserted, or nothing could have been — and they read as history. unattested is an assertion with nothing behind it, and that's the one that has to alarm, not file. "Investigate rather than history" is exactly right: an unbacked claim is a stronger signal than an honest gap, because someone put a principal there that no signature covers.

Two axes fall out — is a principal claimed? and is it vouched for? attributed = claimed + vouched; unattested = claimed + not vouched (investigate); unattributed = not claimed, on purpose; not_recorded = not claimable yet (epoch). Keying it on chain_version so the shape is forced rather than asserted is the right way to make "a zero in one bucket never substitutes for a zero in another" non-negotiable.

This lands straight on the registry case: an entry asserting a publisher or provenance that no attestation backs is unattested — the poisoned-record shape — and it has to stay categorically distinct from an entry that predates the provenance field. Same lattice, one layer up.

[vladimirrott]

@Gowthaman90 the lattice holds except for one cell, and the sloppiness there was mine. none:unattributed is not "not claimed": on a v3 row the principal goes into the signed bytes (canonical_bytes pushes caller_principal), so it is a claim, and the signature does vouch for it. What it claims is an inability rather than an account.

That makes the axis for unattested a different one: a value that is present but outside what the signature covers, either an unparseable v3 principal or a value sitting in the column of a v1 or v2 row whose encoding never signed that field at all. So the four are a signed account, a signed admission of ignorance, an unsigned value (investigate), and no field at all (the epoch). Only the last is really an absence.

https://github.com/lacs-project/sysknife/blob/main/crates/sysknife-daemon/src/audit_chain.rs#L576

[Gowthaman90]

@vladimirrott yes — I collapsed two different things and you've split them correctly. The dividing axis isn't "claim present vs. absent," it's "what the signature covers."

So, precisely: a signed account (a principal the signature vouches for); a signed admission of ignorance (none:unattributed — the "none" marker is itself in the signed bytes, so it's a vouched-for fact, not an absence); an unsigned value (present but outside the signature — an unparseable v3 principal, or a value in a v1/v2 column the encoding never signed → investigate); and no field at all (the epoch — the only real absence).

The security payoff of the split: both signed states are trustworthy — you can act on "this is X" and on "I honestly could not tell" equally, because both are vouched for. A system that can prove it doesn't know is strictly stronger than one that's merely silent. The alarm is the third state: a value the signature doesn't cover is a claim nothing backs — the poisoned-record shape, one field down.

That lands cleanly on the registry: a signed "unverified" is trustworthy (you can gate on it); a provenance value the attestation doesn't actually cover is unattested → investigate, not admit; a legacy entry from before the field existed is the epoch. The "what does the signature cover" axis is the right one to key on. Thanks for the correction — the signed admission of ignorance being a positive, vouched fact is the part I'll keep.