SEP-3140: Signed Capability Declarations & Trustworthy Trust Labels - #3140

Note: AI Policy disclosure
I consulted LLM model to prepare the proposal write-up but the solution was fully developed manually by myself.

Hi @pcarleton and @localden , requesting you to review the SEP and sponsor the changes.

I built a private, vendor-neutral fixture against the independently verified proposal blob for PR 3140 at head 7ace05eabfecb932c7dff70c10689ea7f7489719 (seps/3140-MCP-Signed-Capability-Declarations-and-Trust-Labels.md, SHA-256 3bbbeafe6f3b54fe45cd07d995cf3a3c300ef10c5290141797785a5ab01d0126). This is not a claim of official MCP conformance.

The normative checks exercise declaration negotiation and unsigned policy; RFC 8785 plus SHA-256/base64url content hashing; string per-name versions; complete signed manifests; detached JWS/JWKS verification; canonical server binding; time/nonce checks; RFC 9728 publisher discovery with deterministic HTTPS/private/link-local/loopback/DNS-pinning SSRF checks; restrictive unknown trust values; and material-change re-verification and re-gating. The 35/35 focused checks pass on Homebrew Node 24.

Three consistency checks that recompute fromHash/toHash, changed, and material are explicitly local hardening extensions, not direct normative claims. Canonical URI normalization, qualified identity, and declaration-level replay rejection are also extensions.

Concrete ambiguities remain: monotonic ordering for string versions; delete/re-add semantics; exact detached-JWS protected headers and signing input; canonical URI equivalence; title/icon changes that alter the complete hash but remain non-material; redirect/proxy/multi-address DNS pinning and publisher-key rotation; clock skew and nonce replay; and missed, duplicated, reordered, or racing list_changed notifications.

Optional secure-by-default authentication at lines 228–238 was not implemented and is documented as an exclusion. The local dependency-free JCS implementation is a fixture limitation relative to the proposal’s reference-implementation recommendation; it is tested against a published RFC 8785 vector but is not a maintained third-party JCS library.

If this is useful, I’m happy to share minimized test vectors from the fixture, compare behavior with other implementations, and help turn the remaining ambiguities into independently reproducible candidate conformance cases.

AI assistance disclosure: OpenAI Codex assisted with the fixture, tests, analysis, and drafting this comment. I reviewed the fixture, test evidence, analysis, and draft; I understand the claims above and am responsible for all conclusions and any publication.

Hi @localden @pcarleton , I have implemented a PoC for the SEP proposal.

Steps to run the PoC:

1. node sep-3140-poc/demo.mjs
2. node --test sep-3140-poc/test/conformance.test.mjs

Strong direction. Binding signed manifests to trust labels gives clients something concrete to gate on before execution — that is the right layer to strengthen.

One gap I do not see addressed yet: signatures and content hashes attest to what was declared at signing time. They do not, by themselves, constrain what the implementation does afterward. In static audits of MCP servers, most findings are manifest/capability mismatches — undeclared network, write, subprocess, or env reach — where the declared surface stays plausible while code drifts. That failure mode leaves signatures intact; it is not a “bad signature” event.

If trust labels (effect, egress, sensitivity) are signed over the manifest only, what mechanism keeps those labels aligned with observed behavior between re-sign events? Cross-check against runtime capability surface? Periodic re-attestation? Something else?

For context: I recently started weekly static rescans of public MCP server implementations against their declared tool surfaces. I have two observation points so far — 2026-08-02 and 2026-08-03 — so I do not yet have time-series drift measurements to cite. The rescans are specifically to accumulate that series; I will report back if the data bears on whether signed declarations need a non-signature drift channel.

Question: does SEP-3140 intend to cover “declaration unchanged, behavior changed” paths, or is that explicitly out of scope for this SEP?

@Tetsurohhori yes, this SEP covers "declaration unchanged, behaviour changed".

I've added a working demo showing that a tool doesn't just claim what it can do, it actually gets held to it. The signed capability list is enforceable, so any surprise network, file, or secret access can be detected, blocked and logged.

@omkarparth — thank you for answering the scope question directly, and for shipping something runnable against it.

I have data that bears on the enforcement side, from the opposite direction. Over the past week I hand-verified 12 static findings of exactly the class this SEP targets — declared MCP tool surface versus observed code — by fetching each file at its pinned commit and reading the call site. One of the twelve survived. The other eleven were the tool doing the thing it exists to do:

• the official filesystem server writing files (with 'wx' and an atomic-rename symlink defense already in place)
• a create-* scaffolding CLI writing package.json and README
• a benchmark client writing its own results file
• a doctor health-check writing a probe file and unlinking it on the next line
• an arxiv MCP server fetching arxiv.org
• import "dotenv/config" on line 2 of a server entry point
• a sandbox calling socket.gethostbyname() to compute the host it then adds to its own deny list

That last one is the case I would most want your demo to have an answer for. The code needed name resolution in order to implement a network restriction. An enforcement layer that blocks "surprise network access" has to permit the call that builds the block list, and the only thing distinguishing it from an exfiltration path is intent.

The one that survived is different in kind, and it is public if you want a fixture: Klavis-AI/klavis#1676 — a Google Slides MCP server writing the OAuth refresh token to token.json at a relative path with no mode set, where the server's own .env.example documents where credentials are read from and does not mention that anything is written. Pinned at 45c9f7da83d1, mcp_servers/google_slides/server.py:123. That is a byproduct of authentication outliving the call, not the tool's product.

So my read is that the difficulty is not enforcement, it is declaration granularity. A capability list precise enough that the filesystem server's ordinary work is not a violation is close to fs:*, which constrains very little; a list tight enough to catch the token.json case has to distinguish "writes its output" from "persists a credential". My 1-in-12 is one measurement of how contested that boundary is between a static tool and a careful reader.

I also have one external label on it. On oraios/serena#1824 I filed two findings; the maintainer closed it with "Both false positives." One of those two I had already rejected in my own review before he replied — so on that finding the automated detector said drift, and two humans independently said no. I record externally-labelled precision separately from self-reported precision for that reason; it currently stands at 0/2, n=2.

None of this argues against signed capability declarations. It argues that the signature and the enforcement are the tractable halves, and that whoever writes the declaration is carrying the part that decides whether the mechanism is useful or just noisy.

AI-assistance disclosure: the static tooling, the analysis, and this comment were assisted by AI (Claude, Cursor). I read each of the twelve call sites at the pinned commit myself and remain responsible for what is claimed here.

I'm building agent security tooling that (when released) will ship the mechanism this proposal describes, so I wanted to share what the mapping looked like in practice, plus one gap I think is worth closing before this lands.

The shape maps cleanly onto what we already run. Immutable, versioned cards where a change is a new version, never an edit in place, matches your content hash plus version. The registry as the root of trust for publisher identity matches how we bind keys to identities. And the closed label vocabulary with unknown meaning most restrictive is the call that makes the whole thing enforceable: free form labels are exactly what made the old MUST unsatisfiable, and keeping the vocabulary orthogonal to the tool scopes work is the right boundary. I'd rather the labels stay risk and sensitivity, and let scopes carry authorisation, than merge the two.

The gap: "detect and re-gate" on a material change is necessary but not sufficient imho. Detection tells the host something changed, and re-gating suggests the gate runs again. What I'd make explicit is that a version bump invalidates prior approval. Without that, a quiet bump after approval lands new declarations in front of the model with the gate re-run against the old consent. The difference matters: re-running a policy check is not the same as asking for approval again.

One question, your PoC covers the signing path well. Is there appetite for a signed declarations conformance test living in the spec repo, so a client can check that a server actually signs before it trusts? The MUST stays unsatisfiable until that check is a thing a client can run.

@damoclais — two data points, one for each half of your comment. Both are our own failures, so
take them as evidence rather than advice.

On "a version bump invalidates prior approval". I agree it needs saying, and I would bind the
invalidation to the content hash rather than to the version label. We published
anchors-verify-v0.3 pointing at the same commit as v0.2 — two version labels, one artefact. It
is recorded as VCL-0004 in our conduct ledger, with both tag URLs, because we caught it ourselves
rather than because anyone complained.

The label was ours to write and it said something untrue. The hash could not have. If prior
approval is invalidated by a version bump, a producer controls when re-approval happens; if it is
invalidated by the content hash changing, the producer does not. That also handles the case you
are worried about — the quiet bump after approval — without needing to define "material change",
because any change is a hash change.

The cost is noise: hash-triggered re-approval fires on a whitespace fix. That seems like the
better failure direction to me, but it is a real cost and worth stating in the spec text rather
than discovering later.

On a signed-declarations conformance test in the spec repo. Yes, and I would put one
requirement on it that is not obvious until it bites you: the vectors have to assert the reason
a check stopped, not the verdict it returned.

We learned that the expensive way. Running an external conformance suite against our own verifier
last week, one negative vector passed — expected reject, observed reject — because our
implementation stopped at an unrecognised version string and never reached the property the vector
was written to test. It printed the right answer for the wrong reason, and every check that reads
only the verdict column would have stayed green. That is worse than the false negative sitting
next to it in the same run, because the false negative announces itself.

That shape is not a one-off. We have three instances of it in our own ledger and the suite
maintainer reported a fourth in their project within the same fortnight. What they share is
narrower than "multi-branch verdicts": in every case the verdict came from a guard that fired
before the property was evaluated — a missing attestation, a fabricated fixture, an unknown
version string. So the rule I would write into a conformance test's requirements is: any branch
that can emit a verdict without evaluating the property under test must say so in the verdict
itself, and the vectors must assert on that.

Concretely, for signed declarations, a vector like "signature valid but declaration unsigned"
should require the implementation to report which it checked. A client that trusts a server
because verification returned true, when verification returned true after skipping the signature
path, is exactly the unsatisfiable-MUST problem you describe, one layer down.

We publish Ed25519 attestations with a verification script a third party can run against a URL
without us being involved, and we run an external suite against our own verifier and publish the
mismatches. Both are public if a second implementation is useful for whatever lands here. No ask
attached.

Disclosure: the implementation, the conformance runs cited above, and this comment were assisted
by AI (Claude, Cursor). I checked the ledger entry and the tag digests myself and remain
responsible for what is claimed here.

On hash-keyed invalidation: agreed, the VCL-0004 example is the argument. A label is a claim the producer gets to write; a hash is not. It also matches how we key consent. Our offers are content-identified: the response binds to the offer's hand hash, which covers the full payload including the nonce and timestamp, so consent binds to the bytes and a re-issued offer is always a fresh consent. A re-mint of an underlying card never touches an existing offer, because the offer pins the deck manifest hash.

One thing your rule inherits from the current text: the SEP specifies a content hash but not what bytes it covers. Two implementations can hash different serialisations of the same declaration and get different hashes, which quietly breaks cross-implementation invalidation, and it is where the whitespace noise cost comes from. If the hash covers the canonical serialisation (RFC 8785, as the fixture already does), formatting noise disappears and the rule becomes portable. Worth making canonicalisation explicit in the spec text; right now the rule depends on it without saying so.

Materiality does not disappear but it moves. "Any change is a hash change" is right as the invalidation trigger, but the title/icon case already flagged in this thread shows the prompting layer still needs a materiality notion, or a description tweak re-asks the human.

Two tiers: re-validate on any hash change, re-prompt only on material change. Same trigger, better UX, and "material" stops being a security term.

On reason-asserting vectors: agreed, and the sharp way to state the failure is that a verifier which rejects everything passes every negative vector. One boundary for the conformance test's requirements: the reason must be assertable in the harness, not required on the wire, because a server disclosing why it stopped is an oracle. The verifier reports the reason to the auditor; the server stays quiet. Both are testable; they are different surfaces.

And closing the loop with your rescan thread: this covers the declared surface only. The "declaration unchanged, behaviour changed" class is the SEP's own non-goal (signing establishes provenance, not honesty), so it still needs the drift channel you are building.

@damoclais — agreed on the invalidation binding, and the consent parallel lands: an offer that
pins bytes cannot be quietly re-scoped by a label its producer rewrites. Two things back — the
oracle boundary as a correction to what I wrote, and one dated example for the coverage point.

The correction first. I said the verdict itself must say when a branch emitted it without
evaluating the property. That conflates two surfaces, and yours is the right cut: the reason has
to be assertable in the harness, not present on the wire. A server that explains why it stopped
is answering questions the caller did not earn. Same requirement, correct surface — the verifier
reports to the auditor, the server stays quiet.

On "the SEP specifies a content hash but not what bytes it covers": I have a fresh instance of
exactly that failure, which is why I think it deserves spec text rather than a footnote.
A census I published on 2026-08-16 carried a snapshot_sha256. Yesterday an external reader
checked that value against everything I had shipped with it, and it matched none of them — it was
the hash of an intermediate file I had never bundled and had since deleted. Nothing in my own verifier could catch it, because the field
was read out of stored results and passed back into the recomputation, so it could only ever agree
with itself. Recorded as VCL-0013 in aos-standard/catalog, CONDUCT.jsonl, with the reporter
attributed.

The point for the spec: my hash was not wrong about the bytes it covered. It was silent about
them, and silence let it drift from the artefact for eight days without anyone, including me,
being able to notice. RFC 8785 fixes the cross-implementation half; saying which artefact the
hash is taken over fixes the half that bit me. Both belong in the text.

Your two tiers resolve the cost I raised. Re-validate on any hash change, re-prompt only on
material change, and the whitespace noise stops being a reason to prefer version labels — which
was my only real hesitation about hash-keyed invalidation.

On the closing point: agreed, and I would rather it stay a non-goal here than be half-solved.
Provenance and honesty are different claims with different evidence, and a spec that promised both
would make the weaker one harder to see.

Disclosure: this comment was assisted by AI (Claude, Cursor). I checked the ledger row and its
digest myself and remain responsible for what is claimed here.

Following up on my August 2 offer, here is a minimized, protocol-neutral reproduction of the failure mode @Tetsurohhori described and the harness/wire boundary @damoclais clarified:

https://gist.github.com/Silentpartnercoding/2c5ddb251d4b60f337b86b0452409950

CONFORMANCE-CAUSALITY-001 uses an SEP-3140-shaped case: the manifest signature is valid, the version is supported, and the presented declaration is absent from the signed manifest.

It runs the same vector against two implementations:

The mutant rejects on UNSUPPORTED_VERSION before evaluating manifest_membership_binding; the correct verifier reaches that property and rejects on DECLARATION_NOT_IN_MANIFEST. Both return the expected final verdict.

The vector binds four machine-readable fields: verdict, property_under_test, property_reached, and stop_reason. These are verifier/auditor harness observations, not proposed MCP wire fields. Human-readable error text is deliberately outside the contract.

Local result on Node v24.18.1: 3/3 tests pass, including an explicit assertion that verdict-only conformance stays green while reason-bound conformance kills the mutant. This is a reproduction, not a claim of official MCP conformance.

AI assistance disclosure: OpenAI Codex assisted with the fixture, tests, analysis, and drafting this comment. I reviewed the fixture, test evidence, and draft and remain responsible for the claims and publication.

@Silentpartnercoding — I ran it. Three points back: one portability datum, one hole, and the
cheapest patch I could find for the hole.

Portability. 3/3 on Node v20.20.2, not just the v24.18.1 you cited. Same output from the
fixture runner. Nothing in it depends on a recent runtime, which matters if this is ever proposed
as a conformance vector — the harness should not silently require a Node version that a
compliance auditor does not have.

The hole. The fixture kills the mutant it ships, but the four fields it binds —
verdict, property_under_test, property_reached, stop_reason — are all self-reported by
the implementation under test. I wrote a verifier that never reads its input and returns the
expected four fields verbatim:

function lyingRejectAll(_input) {
  return { verdict: "reject", property_under_test: "manifest_membership_binding",
           property_reached: true, stop_reason: "DECLARATION_NOT_IN_MANIFEST" };
}

verdict_only  passes: true
reason_bound  passes: true

So @damoclais's exact hazard — a verifier that rejects everything passes every negative vector —
survives reason-binding, provided the reject-all implementation also fabricates the reason. What
reason-binding buys is real but narrower than the table suggests: it raises the cost of a false
green from one lie to four, and it kills accidental short-circuits, which is the realistic
failure. It does not kill a deliberate one, and it does not distinguish a verifier that reached
the property from one that says it did.

The patch. Pair the negative vector with a positive one — same manifest, declaration present,
expected allow:

correct           → verdict: allow   reason_bound passes: true
lying reject-all  → verdict: reject  reason_bound passes: false

reject-all now dies on verdict alone, before the reason fields are consulted. The general form:
a conformance suite made only of negative vectors cannot separate a correct verifier from a
refusing one, no matter how many fields each vector binds. To be precise about your suite, since
this is easy to overstate: it does assert that the correct verifier passes. But the only vector in
it expects reject, so "passes when it should" is never exercised on an input that should be
allowed — and that is the assertion reject-all cannot survive.

Getting to reason-binding that is observed rather than reported means instrumenting the
implementation — the harness records which property predicates were actually evaluated. That is a
much heavier contract, and I do not think this SEP should carry it. The positive vector is
cheap and closes the realistic gap.

One note on why I went looking. I published a hash eight days ago whose verifier read the value
out of stored results and passed it back into the recomputation, so it could only ever agree with
itself; an external reader broke it in five hours. Your fixture is the same shape through a
different door — the expected value and the observed value both originate from the thing being
tested. I did not spot that pattern because I am clever about conformance suites. I spotted it
because I shipped it.

Disclosure: this comment was assisted by AI (Claude, Cursor). I ran the fixture and both probes
myself on the gist version e761042 and remain responsible for what is claimed here.

@Tetsurohhori — thank you. You are right about both the hole and the narrower value of reason binding.

I updated the same gist at commit b839f79:

https://gist.github.com/Silentpartnercoding/2c5ddb251d4b60f337b86b0452409950

The fixture now includes:

• a paired positive vector with the declaration present and expected verdict allow;
• a rejectAllMutant that ignores its input and self-reports every field expected by the negative vector; and
• an explicit assertion that the negative reason-bound case still accepts that mutant, while the paired positive control kills it.

The corrected discrimination is:

Results: 5/5 tests pass on Node v20.20.2 and v26.5.0. The README now says explicitly that self-reported reason binding kills accidental short-circuits but is not an independent execution oracle. The positive control supplies the missing behavioral discrimination without requiring implementation instrumentation.

Thank you for running the fixture, reducing the failure, and giving the exact portability target.

AI-assistance disclosure: OpenAI Codex assisted with the patch, test execution, analysis, and drafting this response. I authorized publication and remain responsible for the claims made here.

@Silentpartnercoding @Tetsurohhori @damoclais Thank you for all your comments.
I'm currently focused on getting this SEP approved from the MCP maintainers and finding a sponsor.
Once that is done, following the SEP guidelines - I will circle back to the above comments.