Signed tool manifests : additive extension for tool-poisoning / "rug pull" defense #2913

That's the right wiring compiling from the canonical bytes behind
manifestHash rather than an independent re-parse is what keeps the
three-way binding intact. Appreciate you closing that loop on the
enforcement side.

I'll add a short "Known Consumers" note to proposal.md referencing
capgate as an example of the enforcement leg consuming manifestHash
useful for anyone reading the proposal cold to see the anchor actually
being used end-to-end.

Appreciate the §7 note — glad to have capgate stand as the worked example of the enforcement leg.

One small accuracy flag so the doc stays precise for anyone reading it cold: capgate compiles from its declared capability set today, and consuming the canonical bytes behind manifestHash as the compile anchor is the change I described — in progress, not yet shipped. Until it lands, wording like "capgate is being wired to compile from the canonical bytes identified by manifestHash" keeps §7 accurate to current state. I'll ping you the moment it ships so you can flip it to present tense with confidence.

Sure!!!

Update on the §7 note — capgate just shipped the anchor. v0.0.4 is on npm (capgate), and every compiled artifact now carries a provenance block (manifestHash, grammarVersion, canonicalization: "RFC8785"); compiling one manifest to bwrap, docker, and egress yields the same hash across all three.

One precision so §7 stays exact: capgate computes the hash over its own capability manifest — the declaration it compiles — using an RFC 8785 / JCS canonical form, so the bytes are reproducible by anyone who canonicalizes the same projection. That's a sibling to your manifestHash over the signed MCP tool manifest, not the identical artifact. So wording like "capgate compiles from a canonical, content-addressed manifest projection (RFC 8785), the same canonicalization scheme as manifestHash" is accurate to what shipped — present tense, no caveat needed. If you'd rather §7 assert capgate consumes your manifestHash directly, that's a deeper integration I haven't built (it'd mean ingesting the tool-manifest format) — happy to talk through whether that's worth it as the proposal firms up.

Alright! Thankyou for update.

On the execution and authorization half that keeps getting described here as the next thing to build: it is built, it is shipped, and it is independent of any manifest scheme or runtime. Vaara runs against MCP as is.

Shipped and runnable now, keyless, AGPL:

• A hash-chained record per tool call (SEP-2828), binding the call, the decision that authorized it, and the outcome.
• The gate, not just the log: vaara proxy --enforce allows, denies, or escalates a call before it runs and rewrites denied calls out of the model response. vaara init routes a machine's agent tooling through it end to end.
• A cryptographic decision proof: the recorded verdict is the correct threshold output over committed inputs, in zero knowledge, keyless, no trusted setup.
• Qualified existence-in-time: each record carries an RFC 3161 timestamp graded qualified only when the signer chains to the EU trusted list, validated against the European Commission's own DSS validator at level QTSA. Absent a pin it reports self-asserted, not qualified, so it never overstates.
• All of it verifiable offline by someone who does not trust us.

Signed tool manifests are a sound protocol-level addition for descriptor integrity, and they are orthogonal to this. Vaara does not sit downstream of a manifest format or of anyone's runtime. It is a standalone evidence layer that binds and proves what a call did, and it already works end to end.

github.com/vaaraio/vaara. vaara verify-record surfaces the verdict, --trusted-issuer-cert pins the list.

@vaaraio — fair correction on the tense. I wrote "circling" apologies for not being more personal; it's shipped. And I under-described it: a gate that denies and escalates before a call runs, with an offline-verifiable decision proof, is more than the receipt layer I credited. Noted. The independence/separation is the right line. Descriptor integrity at admission, call integrity at runtime — the call, the decision that authorized it, the outcome, bound and provable — those don't nest under each other, and neither does mine.

The seam: your gate acts on the call. As you've described it, it allows/denies/escalates before execution and rewrites denied calls out of the response. Result-borne content lives past that boundary — a call can clear the gate clean, verdict ALLOW, fully receipted, and still return a mail body or an exec dump with instructions a stranger wrote in it. The bytes ride an authorized call's return path, so nothing upstream — manifest, decision, receipt — has cause to stop them. That's why it's a third thing and not a subset: downstream of even a perfect gate, and about what the agent may do after reading what came back, not whether the call was allowed to run.

So: manifests prove what the tool is, your layer proves what the call did, result-taint governs what the agent may do with what returned. Good to see the runtime half shipped and end-to-end.

Folded this into §7 as informative entries, not normative changes: SEP-2828/vaara noted as shipped with real enforcement (vaara proxy --enforce) and a keyless decision proof, explicitly orthogonal to this proposal and not currently binding to manifestHash. Also added a line on the result-content-trust gap you raised (#3093) as a separate, out-of-scope boundary descriptor and call integrity don't cover what a tool's results carry back. Referenced, not adopting terminology from either.

I think the three-layer decomposition emerging here is useful:

descriptor integrity → call authorization/execution integrity → result-content trust

There may be a fourth property worth keeping separate from all three: semantic authority of the selected action.

A tool can have an unchanged, correctly signed manifest. The proposed call can be structurally valid, pass an independent authorization gate, execute exactly as authorized, and produce a perfectly valid execution receipt. The returned content can also be clean.

Yet the agent can still have selected the wrong tool or effect for what the user actually authorized.

For example, suppose a support agent is authorized to administer a customer account and the user asks:

remove Alice from the mailing list

The agent proposes:

delete_customer(customer_id="alice")

Nothing necessarily failed at the descriptor-integrity layer. Nothing necessarily failed cryptographically. The call may even fall inside the agent's standing capability and parameter constraints.

The failure is that the proposed world-state transition does not correspond to the intended effect.

I have been testing this failure class in REMORA:

https://github.com/darklordVirtual/REMORA-research

On a sealed 500-case external tool-selection evaluation, we observed:

structural-only controls: 24/500 native wrong-tool ACCEPTs
contracts plus intent binding: 6/500
adding a conservative UNKNOWN semantic floor: 0/500 native wrong-tool ACCEPTs

There is an important caveat. The stricter semantic layer reduced legitimate autonomy substantially, so I do not interpret the final number as a general safety claim or a solved problem. The negative results and utility failures are published as well:

https://github.com/darklordVirtual/REMORA-research/blob/master/NEGATIVE_RESULTS.md

What the experiment suggests to me is narrower: call integrity and action correctness are independently testable properties.

That would give a lifecycle something like:

manifest integrity → semantic authority → exact-call authorization → execution integrity → result-content trust → effect verification

I would also distinguish execution integrity from effect verification.

A receipt can establish that the authorized call was dispatched and report its outcome, but for consequential state mutations it does not necessarily establish that the authorized world-state transition actually occurred.

Where an authoritative read-back exists, I think it is useful to bind:

intended effect → authorized call → execution → observed postcondition

and distinguish EFFECT_VERIFIED, EFFECT_MISMATCH, and EFFECT_UNVERIFIABLE.

The REMORA execution path currently treats these as separate stages:

https://github.com/darklordVirtual/REMORA-research/blob/master/docs/deployment/execution-quickstart.md

This also raises an interesting question for the signed-manifest proposal itself.

If manifestHash identifies the exact ToolSpec the agent reasoned against, should an execution authorization bind not only the normalized call, but also the exact manifestHash that defined the tool when the decision was made?

Conceptually:

manifestHash + normalizedCallHash + policyDecisionId + executionAuthorizationId

Then a manifest change between assessment/approval and dispatch becomes a deterministic execution failure rather than only something detected on the next reconnect.

That would not make the manifest proposal responsible for authorization. It would simply give the authorization layer a stable cryptographic identity for which definition of the tool was actually authorized.

So I see these approaches as complementary:

signed manifest: is this the tool definition that was admitted?

semantic authority: is this the right action for the authorized purpose/effect?

execution authorization/receipt: was this exact call permitted and what execution was recorded?

result-content trust: what authority should information returned by the tool carry into subsequent reasoning/actions?

effect verification: did the external system actually reach the authorized state?

The part I would be particularly interested in standardizing across these layers is not one universal security object, but a small set of cryptographically stable join points so independent implementations can compose without collapsing these different claims into one.

REMORA's machine-readable claim register is here for the experimental evidence:

https://github.com/darklordVirtual/REMORA-research/blob/master/docs/assurance/claim_register_v1.yaml

I would be interested in whether binding manifestHash into the action-time authorization artifact fits the intended scope of this proposal, or whether you deliberately want that composition point to remain entirely external.

Good question, and yes, that's exactly the intended composition point, not something I want to pull into this proposal's scope.

manifestHash is meant to be just a reference anchor (§6). Binding it into an execution-authorization artifact along with normalizedCallHash and policyDecisionId is precisely the kind of external use this was designed for, the same pattern as the SEP-2828 composition discussed above. If a manifest rotates between assessment and dispatch, that mismatch becomes the consuming layer's problem to catch via the hash. This proposal doesn't need to define that layer itself.

The semantic-authority and effect-verification layers are an interesting decomposition, but they're a separate proposal. This one stays scoped to descriptor integrity. Appreciate the empirical work, and publishing the negative results too.

These are two separate questions. This proposal only answers the first one, whether the tool is what it claims to be. Runtime authorization, whether this specific call should happen, sits in the layer above it, which is where something like SEP-2828 lives.

The two connect through manifestHash (section 6). An authorization decision can bind to a specific manifest version, so a rotation between approval and call becomes visible to that layer directly.

For a real zero trust setup you want both. This proposal deliberately stays scoped to the first one.