Tool definitions as untrusted input makes total sense! Metadata/schema injections are real risk as MCP ecosystems grow. Are you implementing signature verification or cryptographically signed manifests to enforce provenance?

Comments

[Tom Jones]

Short answer: no signatures yet, and today handed us a measured reason they cannot carry provenance alone in this ecosystem.

Nothing binds a model NAME to what is actually served. We pinned the provider under one model id and measured parallel tool-calling one upstream at a time: 0/8 correct on two providers, 5/8 on a third, same model string, same prompts, same params. A signed manifest authenticates the manifest's author. The behavior underneath it still changed with the serving layer, and no signature is invalidated when it does.

So the split we run is: deterministic verification of every tool CALL against the caller's schema (structural + type + enum, fail-closed - an unverifiable call escalates, it never serves as trusted), and for provenance the direction we are moving is a capability fingerprint rather than a certificate: a small fixed probe set with discrete outcomes (e.g. how many calls a multi-call turn returns), replayed on a schedule. If the fingerprint moves, the thing behind the name changed, whatever any manifest says. Discrete outcomes matter because text similarity is too smeared by serving nondeterminism to detect identity - we measured that too, self-similarity of one endpoint asked twice was 0.305 byte-similarity at temperature zero.

Where signatures DO earn their place: authenticating that a tool definition came from its publisher unmutated. That closes the injection vector you are naming, and it is worth having. It is just orthogonal to the drift vector, and in our measurements the drift vector is the one that fires without anyone attacking you.