Explore proof of inference and model-serving attestation

[i386]

Context

Steven Mih raised an important discussion about proof of inference: how can a client tell whether a node generated a response with the model it advertises, rather than substituting a cheaper quantization or different weights?

Sources:

• Steven Mih on LinkedIn
• Discord discussion

Why this matters

A human-readable model name is not a strong identity claim. A node could advertise a full-precision or higher-quality model while serving a cheaper quantization, modified weights, a different tokenizer, or a different runtime configuration.

“Proof of inference” is best understood as three separate claims:

Claim	Example question	Candidate evidence
Model identity	What exact model/package does the node claim to serve?	Content-addressed package and artifact digests
Execution identity	Did this request actually run with those bytes and this runtime?	Signed request/response receipt, ideally TEE-backed
Behavioral identity	Does the output behave like the claimed model?	Statistical fingerprints or reproducible verification

No single mechanism solves all three.

Proposed model identity

A model name such as Qwen3-8B is too broad. The advertised identity should include an immutable package or manifest digest covering:

• canonical package manifest;
• source model identity and revision;
• quantization/distribution;
• tokenizer identity;
• all selected artifact digests;
• generation/runtime defaults;
• Skippy/llama ABI version;
• accepted equivalence classes, if quantized variants are intentionally allowed.

A useful conceptual identity is:

model_package_digest =
  sha256(canonical_manifest + artifact_digests + runtime_abi)

Mesh-llm already has useful building blocks here. Layer-package manifests record source identity, per-artifact SHA-256 values, layer coverage, and ABI compatibility. Production references should use immutable package commits/tags rather than moving branches. See the model package specification.

A quantized model is not inherently fraudulent. The fraud is advertising an identity outside the declared package or accepted equivalence class. The policy should make that distinction explicit.

Per-request evidence

A node could produce a receipt covering the request and response:

receipt = sign_node_key(
  client_nonce,
  request_digest,
  model_package_digest,
  runtime_digest,
  generation_parameters,
  output_digest,
  timestamp
)

Important details:

• The client contributes the nonce and request digest so the node cannot fabricate or replay a request.
• The request digest should be canonicalized and may protect prompt privacy without disclosing the raw prompt.
• The output digest commits the node to a particular response; the client can retain the response and verify the digest.
• A node signature authenticates the statement but does not make a dishonest statement true. The signing key must be bound to a trusted node identity, owner policy, or hardware attestation.
• Split inference needs evidence from participating stages, or a coordinator receipt that commits to each stage package/runtime digest and execution order.

Statistical fingerprints

Fingerprinting is a practical, lower-cost verification layer:

• TOPLOC proposes compact locality-sensitive hashes over intermediate activations and reports perfect detection in its evaluated experiments.
• DiFR reports detecting 4-bit quantization with AUC above 0.999 within 300 output tokens.

These should be treated as probabilistic spot checks, not universal cryptographic proofs. They may depend on the model family, prompt/challenge design, sampling configuration, hardware, and detector training distribution. A known public challenge could also be gamed by a sufficiently adaptive provider.

Potential mitigations include verifier-selected nonces, unpredictable challenge prompts, periodic audits, and a mesh policy that records confidence and false-positive/false-negative behavior rather than exposing a binary “proven” label.

TEE-backed attestation

A trusted execution environment could provide stronger evidence that a measured inference binary loaded a specific model/package digest and generated the response. However:

• remote attestation proves a measured program/environment, not automatically that the program is correct;
• the measurement must cover model loading, runtime libraries, configuration, and relevant GPU execution;
• hardware/vendor support, availability, performance, side channels, and key management need consideration;
• TEE evidence should be represented separately from statistical fingerprints.

The existing mesh-llm release attestation is a useful precedent, but it is build provenance only. It does not prove that a remote process is running unmodified code or that the claimed model was used at request time. See mesh requirements and release attestation.

Capsule history

The “capsule history” idea could make evidence portable and useful for later review. A capsule could be a signed, append-only record containing:

1. node identity and advertised capabilities;
2. model/package manifest and artifact evidence;
3. runtime/build/TEE evidence, where available;
4. client request commitment and nonce;
5. per-request receipt and output commitment;
6. fingerprint/challenge result;
7. later verification, dispute, or reputation outcomes.

This would let a client or mesh operator distinguish:

• what a node advertised;
• what evidence it presented;
• what was actually checked;
• how strong that evidence was;
• whether later evidence contradicted the claim.

Proposed progression

1. Define the threat model and assurance levels.
2. Make model/package identity precise and advertise immutable digests.
3. Add nonce-bound signed inference receipts.
4. Add optional statistical challenge/fingerprint verification.
5. Add TEE evidence for high-assurance nodes.
6. Store the resulting evidence in a signed capsule history.
7. Define trust, privacy, replay-prevention, split-inference, and dispute-resolution rules.

Proposed next steps

• Schedule a call/discussion with Steven Mih to understand the proposed TOPLOC/DiFR and attestation approaches in more detail.
• Agree on the threat model and assurance levels.
• Inventory the existing package, identity, release-attestation, and receipt primitives.
• Draft a minimal design for digest advertisement plus nonce-bound inference receipts.
• Decide whether to prototype statistical verification, TEE verification, or both.

This issue is for design exploration and coordination; it does not yet commit mesh-llm to a particular cryptographic or hardware-attestation approach.

Client nonce delivery strategy

Nonce-bound evidence needs a stable request identity before receipts can make useful replay or provenance claims. The OpenAI frontend should implement the following contract:

1. Resolve exactly one canonical RFC 4122 UUIDv4 nonce at the outer logical-request ingress. Preserve a valid client value; otherwise mint a fresh value.
2. Derive origin and provenance at a trusted boundary. Never trust a public caller-provided origin marker.
3. Carry the same typed nonce context through target selection, retries, request reconstruction, pipeline or MoA dispatch, and authenticated remote mesh hops.
4. Echo the resolved contract on every response path, including JSON, streaming, remapped upstream errors, locally synthesized errors, and model discovery.
5. Keep the evidence claim narrow. A client-supplied nonce proves client contribution to freshness; a frontend-minted nonce provides request correlation but must be labeled as such.

Delivery is split into two child issues:

• Implement client nonce normalization and propagation #1608 implements ingress normalization, retry stability, forwarding, and the currently covered response adapters. PR feat(openai-frontend): inject a fresh per-request client nonce at the local ingress #1397 resolves this issue when merged.
• Complete the OpenAI client nonce lifecycle #1609 moves nonce and provenance into shared typed context and completes coverage for internal hops and locally synthesized responses.

This split allows the bounded security and propagation fixes in #1397 to land while retaining complete response coverage and trustworthy provenance as explicit follow-up work.

[StevenMih]

Thanks @i386 — this is a sharper decomposition than what we had on the discord thread. The three-claim split is looks good, and worth keeping hard: model identity, execution identity, and behavioral identity fail differently, so they need separate evidence with separate confidence labels — your point that the mesh should record confidence and error behavior rather than a binary "proven" label is the much needed nuance, I like to all them confidence rungs :)

Mapped to your progression, where the agent action capsule can help:

Step 2: agree the layer-package manifests already carry most of model_package_digest — the adds are immutability discipline (tags/commits, not branches) and the equivalence-class declaration, so a quantized variant is policy rather than fraud, exactly as you framed it.

Step 3 is the layer we build, and the one I'd like to prototype with you. Your receipt tuple is an agent-action record where the tool is the model: we'd emit it as a signed capsule at the /v1 serve boundary — same capability-plugin pattern as your metrics plugin — with the client nonce, request digest, model_package_digest, runtime digest, params, and output digest as committed fields, hash-chained per node. Apache-2.0, two IETF drafts behind the format. The design property that matters for your steps 4–6: it's mechanism-agnostic — a fingerprint result or TEE quote rides as a typed reference (digest + declared context) inside the same record, so steps 4 and 5 upgrade the evidence a record carries without changing the wire format. And step 6's capsule history then comes nearly free: the records are already signed and append-only, and anchoring them to a transparency log is what stops a node forking its claim history per audience.

One note for step 7's dispute rules, learned the hard way elsewhere: keep "evidence absent/expired" distinct from "checked and failed" — a record of absence and an absence of record are different facts with different owners, and collapsing them is the most common defect in evidence vocabularies.

On the call: yes. I'll bring a receipt-as-capsule strawman and I'll also prototype the step-3 plugin in parallel.

[StevenMih]

Following up on the strawman I said I'd bring — it's here, Apache-2.0: https://github.com/action-state-group/capsule-emit-mesh

It implements your step-3 receipt tuple verbatim as a signed, hash-chained record: client nonce, request digest, model_package_digest, runtime digest, generation params, output digest, timestamp. Verified live against a real mesh-llm serve --local-model-only node and a real goose session, not a mock.

One correction to my own earlier comment, up front. I said I'd prototype it as "the same capability-plugin pattern as your metrics plugin." Having actually read the code, that framing doesn't survive contact:

the native serving plugin ABI (crates/mesh-native-serving-plugin-api) delivers GenerationStart/Commit/Finish — token ids, counts, timing — but never the OpenAI JSON request or response body, so a plugin on it can't reconstruct request_digest/output_digest as #1233 defines them;
the metrics plugin isn't on that ABI — it's an out-of-process capability provider the host calls into, not an observer of core's own inbound /v1 traffic;
openai-endpoint is a provider too, but for routing out to an external OpenAI-compatible backend — the opposite direction from what a receipt needs.

So the honest PoC is a sidecar reverse-proxy at /v1: zero changes to mesh-llm, works against a release binary or cargo run, and labeled as an external observer rather than a first-party integration. Every record carries provenance: "collector" for exactly that reason — it observes at the wire, it is not the gate.

The one I'd like your read on: OpenAiHookPolicy + HookedOpenAiBackend in crates/openai-frontend/src/hooks.rs do see both sides — before_chat_completion has the full request, and chat_completion_with_context holds the full response. That's the native long-term shape, but using it today means a custom binary, i.e. a fork rather than an installable plugin. Whether that's a direction you'd entertain is a better use of call time than anything in the strawman.

Two things surfaced building it, filed separately so they're trackable independently of any of the above — #1303: tool_calls entries come back with no id, so an OpenAI-compatible client has nothing to pair a role: "tool" result against. Happy to PR it. Same issue carries two --local-model-only docs snags that cost me time.

To run it yourself — no model download needed for the mock path:

git clone https://github.com/action-state-group/capsule-emit-mesh
python3 run_demo.py # mock node, proves the sidecar mechanism
./run_live_demo.sh # real mesh-llm + real goose, the way I verified it

Two live record streams from that run, verifiable in a browser with nothing uploaded — the record travels in the URL fragment, which the browser never transmits, so the payload never reaches our server. The permalinks are attached, copy and paste them to any browser.

demo-run-1.txt
demo-run-1b.txt

One more for the call: With a 7B local model driven by goose's agent prompt, I saw responses carrying a well-formed tool_calls array and a non-empty content string, which goose's parser rejects. You already have a GuardrailResponseCategory::MixedTerminalAndTool in crates/openai-frontend/src/guardrails/validation.rs that looks like it's meant for precisely this — it didn't fire on my --local-model-only path. I don't know whether guardrails are off by default in local-serve, whether I misconfigured, or whether that's a gap. Worth five minutes.

On your step 7: I kept "evidence absent" and "checked and failed" as distinct states in the record — a failed inference is sealed with verdict_class: "errored", not "denied," since the sidecar can only honestly say a request was dispatched and the outcome was a refusal. It can't claim pre-dispatch denial from outside the process.

[StevenMih]

Again great to meet and I think y'all got when it was mentioned that agent action capsule “...kind of feels like this is a trust primitive for AI inference on the Internet.” as an initial reaction. I had a chance to dig into this and work out the way forward to achieve what we discussed on the call.

Step 1, drafted: a threat model for both strangers

The progression in this issue opens with "define the threat model and assurance levels." Work has since started around several of the later steps — #1331 and #1332 cover step 3, #1346 reaches toward step 5 — and since we've got some alignment I have applied my agent actions work toward getting a thread model in place for mesh-llm. That step 1 give us a way to order the rest of the steps. There is no principled way to say whether a fingerprint matters more than a TEE quote until the threats are written down.

So I have drafted it, and widened it in one direction:
https://github.com/action-state-group/capsule-emit-mesh/blob/dcb3b3f/docs/TRUST-MODEL.md

The framing that changed the document while I was writing it. This issue asks the requester's question — how does a client tell whether a node ran the model it advertises? — and asks it well. But a mesh has two strangers in it. The second is the person lending a Mac mini or a rack of idle CI machines, and nothing written so far says what they get to trust. That is not a footnote; a capacity mesh has no supply without them, and today they are making an unpriced risk decision with no evidence to reason about.

Working that side produced the finding I did not expect. I enumerated eight things a node operator should reasonably fear, and six are answered by the same records the requester uses — but only if the requester is bound into them. Today the record is unilateral: the node signs an account of an exchange it describes alone, and there is no requester identity anywhere in the receipt tuple. Which is why the provider side reads as unaddressed.

This issue already half-states the fix: "the client contributes the nonce and request digest so the node cannot fabricate or replay a request." No client sends one today. Complete that sentence — have the requester sign their commitment, have the node counter-sign — and the provider's largest exposure improves directly: an abusive request becomes attributable to the identity that asked, rather than to the machine that served it.

One honest qualification I would rather state than have found. A self-held key is an identifier, not a vouched identity: it buys continuity and pseudonymous accountability, not attribution to a person. The bilateral profile I am drawing on requires a credential chaining to a root the relying party accepts, and says first-use acceptance is not conformant. So what a signature buys depends on where the key is rooted — which is a property of the deployment, not the mechanism. An open mesh gets continuity; a membership-gated deployment where an operator admitted the member gets someone they can name and eject. Strangers can become verified participants without a protocol change.

Two structural choices worth flagging, since both are arguable:

Five evidence classes, not one ladder. Record integrity, identity, execution, mutuality, confidentiality — each advancing independently, because a node can be strongly identified and behaviourally unchecked, or TEE-attested with no mutual commitment. The one place they interact: advancing confidentiality reduces achievable execution assurance, since fingerprints work over activations and under FHE those are ciphertext. Which means on a confidential path the record carries the whole trust claim rather than less of it.

Three states everywhere, never two. absent, present-unverified, checked — where checked may carry a verdict of failed. "Checked and failed" and "never checked" are different facts with different owners.

I also went through the split path, since the coordinator is a party the model originally left out and turns out to be the least-evidenced one in the system. The encouraging part: everything a commitment would need already exists as data — the topology is a structured object with stable ids and per-stage layer ranges, a correlation spine threads run/request/session/topology/stage identity through the wire protocol, per-stage manifest_sha256 and source_model_sha256 are already carried, and execution ordering is already modelled with epochs. What is missing is that nothing signs any of it. Corrections welcome — I read a checkout dated 2026-08-11 and this tree moves fast.

One structural question the model kept running into, which belongs in this thread rather than the plugin ones: how much of this can be done without the inner loop?

Step 3 can be done at the API boundary — request in, response out, both digested, signed and chained. That is what the prototype demonstrates and it is genuinely useful: it establishes non-repudiation, input-output binding, and order.

Steps 4 and 5 cannot. A statistical fingerprint is computed over intermediate activations, and TEE evidence has to cover model loading and the forward pass. Only the runtime has either. So an API-boundary observer, however well built, can never produce behavioural or execution evidence — not as a limitation of the implementation but of the vantage point. #1331 says as much when it calls the native serving ABI "complementary, not interchangeable," and #1332's own Q8 asks the question directly.

The practical consequence for build order: if the receipt is minted at the boundary and the fingerprint is later minted in the runtime, you get two evidence paths that have to be joined after the fact — which is the same correspondence problem the tool-call and inference streams already have, where the only thing relating them is a timestamp. Minting them at one point, or at minimum defining the typed reference between them before either exists, avoids paying for that twice.

Which raises the question I do not have standing to answer: does the inner loop need to emit a generation record of its own, or is a typed reference from the boundary record to runtime-supplied evidence enough? My instinct is that a small native generation receipt — deterministic output commitment plus, later, a fingerprint slot — is the more durable shape, because it is the only place those bytes exist before normalization. But that is a question about your runtime's seams, and you are better placed to answer it than I am. It also determines whether the ABI needs one additional event or several.

The three-claim decomposition at the top of this issue is yours, and the document extends it rather than replacing it. Where it says "not built," that is a description of today, not a commitment from anyone.

Three things I took elsewhere rather than piling them in here: the assurance vocabulary now diverging across #1332 and #1346 (proposal on #1331), what belongs in a mesh profile versus a general record format (#1332), and the digest-domain question from #1303 — that normalized responses carry a wall clock in the tool-call id, so digesting them gives a different value every run for identical model output, which blocks anything that verifies by re-running a node's work.

On #1346 — the record layer needs no change to carry an encrypted exchange. Because it commits to bytes rather than meaning, a digest over ciphertext behaves exactly like a digest over plaintext. The one thing that issue does demand is a generalisation I think is right anyway: what a record commits to is not "a model" but an execution bundle — compiler revision, numeric approximations, packing, decoding, stage order. That covers container digests, tool binaries and TEE images just as well.

Following up the call — the builders read, and the order I'm actually working in.

Step 4 has a prerequisite I hadn't seen, and a cheaper form than I'd assumed. I had been taking behavioural identity to mean statistical fingerprinting. Having built step 3 for real, I think this network's threat model admits something simpler and stronger: spot-check replay. A receipt already commits the request digest, generation parameters, model_package_digest and runtime. An auditor — or a user, or a dispute process — holding the weights has everything needed to re-run the request and compare. At temperature 0 with a fixed seed that comparison is exact rather than statistical, and it needs no new cryptography and no access to activations.

Two honest limits on it. Exact reproduction is only safe within a hardware class: GPU reduction order is not deterministic across different silicon, so a legitimate node can fail an exact comparison for reasons that have nothing to do with honesty. A mismatch should therefore open an investigation, not close one — and where hardware differs, a declared tolerance or a fingerprint is still the right instrument. That is the honest division of labour between step 4's two possible forms, and it is why I would not drop fingerprinting so much as demote it.

The prerequisite, and it is the thing I'd most like a decision on: the digested bytes have to be deterministic. Today's tool-call ids are minted in the host-runtime normalizer and carry a wall clock, so digesting the client-visible response yields a fresh value every run for identical model output. That leaves a fork nobody has had to pick yet — digest the pre-normalization form and it is reproducible but is not what the client saw; digest the post-normalization form and it is what the client saw but cannot be replayed.

I hit the identical seam in the sidecar with goose compatibility, and solved it by having the record carry both: a digest of the raw response, a digest of what was delivered, and the declared list of transforms applied on the way out. The transform list is the part that matters — it makes the relationship between the two digests checkable rather than asserted, and it means a verifier can tell whether a difference is a transform or a substitution. Same shape would work here, and it is cheap to specify now and expensive to retrofit once implementations exist.

On step 3, one thing from your side. The nonce in the prototype is sidecar-generated and labelled that way in every record — goose sends no nonce header, so the receipts do not carry the anti-replay property this issue asks for. The sidecar already accepts X-Capsule-Client-Nonce. One header from the mesh client and step 3 gains the property that actually matters for shared capacity: a node cannot bill twice for work it did once.

Step 6 is closer than step 4. Chaining is built; what is missing is publishing the peaks somewhere the node does not control. That is what stops a node showing different histories to different audiences, and it is also what makes model splits provenance-able — each split is a signed file and the chain rolls up.

Step 5 I would defer. TEE evidence is the strong version of execution identity, but it needs hardware that a heterogeneous mesh of Mac minis and gaming rigs largely does not have, and it is not what a requester is actually asking when they wonder whether a stranger's node ran the model it claimed. Worth building toward; not worth blocking on.

So the order I am working: deterministic digest boundary → client nonce → peaks export → replay spot-check → admission control. That last one was Michael's suggestion on the call and I think it is what makes any of this load-bearing rather than observability: a node that cannot produce a valid receipt does not get work.

A Mac mini is being set up this week. I would rather come back with running code than more prose.

One question, and it is the first one in the document. Does the provider-side threat model match what your hearing and thinking about? I reasoned it out based on my actions auditing work. If your list differs, feel free to PR the doc in place. Again happy to PR over as well.

[StevenMih]

Following up with the code rather than more prose.

Three things landed since this morning, all Apache-2.0 and all in the open.

The digest-domain question is now measured rather than argued. I re-ran the demo against the supported mesh inference port this time — not --local-model-only, which @michaelneale rightly pointed out is a debugging endpoint — with real mesh-llm and real goose. Six records across the two boundaries — four inference receipts and two tool-call action records — all verifying offline. And the thing I flagged on #1303 reproduces exactly as expected: because the normalizer mints tool-call ids carrying a wall clock, digesting the delivered response yields a different value on every run for identical model output. That is fine for correlation, which is what it is for. It means a digest over delivered bytes cannot support anything that verifies by re-running a node's work — and there is still no defined place to take deterministic model-produced bytes from. My view is unchanged and now has a measurement behind it: the record should commit to both domains as separately declared fields, plus the list of transforms applied between them, so a verifier can tell a declared transformation from a substitution.

The client nonce works end to end. A client now sends X-Capsule-Client-Nonce and the resulting records carry client_supplied rather than a self-generated fallback, with both cases shown side by side so the difference is visible. The fallback path is still there and still labelled honestly, because that distinction is the point.

What that changes about the ask: you have already specified the receiving half. #1331's example manifest allowlists x-capsule-client-nonce as a sanitized header a permitted plugin may read, and #1332 carries the client_supplied / plugin_generated_fallback distinction so a record can say which it got. The sending side is the only piece nobody has claimed — and step 3's anti-replay property, which this issue asks for in its own words, turns on exactly that one header.

And the bilateral exchange has a working implementation. The threat model I posted this morning argued that the record should bind the requester as well as the node, and that the proposal's weakness was having no implementation anywhere. It has one now: the four moves — request attestation, constraint evaluation before dispatch, action attestation referencing the request by digest, acknowledgment — with the degraded path demonstrated beside the full one and shown to be distinguishable, since a specification requiring that they never be confusable deserves a test rather than a promise.

One honest limit, stated in the demo's own README and in the records it produces: the demo key is self-held, which is explicitly non-conformant with the identity requirement it is demonstrating — that requires a credential chaining to a root the relying party accepts. It shows the mechanism, not a conformant deployment, and it says so in three places so nobody has to take my word for it.

One thing in that repo is wrong and I'd rather say so than have you find it. The README still walks through --local-model-only as the live path — seven references, no mention of the front door — because I wrote it before your correction on #1303 and haven't fixed it yet. docs/ SUPPORTED-PORT-RERUN.md is the accurate account of the run described above; where the two disagree, the README is stale and I'm fixing it. Sorry for the trip hazard.

bilateral exchange — action-state-group/capsule-emit-mesh #2
client nonce end to end — #5
supported-port rerun and the digest measurement — #6, with the run written up in docs/SUPPORTED-PORT-RERUN.md
docs/TRUST-MODEL.md, updated since this morning — https://github.com/action-state-group/capsule-emit-mesh/blob/bbb6518/docs/TRUST-MODEL.md

The question from this morning still stands and is the one I would most like answered: does the provider-side threat model match what node operators actually tell you they worry about?

[StevenMih]

Closing the loop on the two defects I flagged in my own repo above, since I'd rather the record show them fixed than fixed quietly.

The CAPSULE_ANCHOR=true in the quickstart is now false, with the consequence written next to the flag rather than only in the limitations section. Reviewing it turned up a second instance I'd missed — the same true in a copy-pasteable example inside goose/server.py's docstring — also fixed. And I checked whether anyone had actually been caught by it: the log holds 273 entries and hasn't grown since 11 August, so there are no third-party writes. Two entries I can't attribute from the public log predate the README entirely, and I'd rather say that than round it to zero.

The --local-model-only references are gone from the live path; the three that remain are inside a block labelled as the debugging endpoint. And docs/SUPPORTED-PORT-RERUN.md now carries the sampling correction with the original claim retracted in place rather than deleted, so the thing I got wrong is still visible next to the thing that replaced it.

Separately: a fresh install of that repo was broken today — mcp resolves to 2.x, which removed mcp.server.fastmcp, and two dependencies were never declared at all. Fixed with a pinned dependency file and a clean-venv import check in CI. Worth mentioning because it means anyone who tried to run it before today couldn't have, which is the honest reason nothing appeared in that log.