You've left 4 comments since Jul 17, and each one named a real gap. Batched response below.
1. "Layers 1-8 all inspect the artifact at import time, but MCP skills are live code" (Jul 17)
"The trojan-in-a-zip is the easy threat because it's static — you can scan it once and be done. The hard one is a skill that ships clean and then pulls its payload at runtime, or a server that returns benign tool descriptions to your scanner and malicious ones to a real client."
This was the most important critique anyone made on the 8-layers article. The fix is the post-execution filter: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/uta-monorepo/packages/gateway/src/post-exec-filter.ts — runs after each tool call, inspects result + side effects, blocks if tool catalog changed since approval.
The --network none sandbox specifically couldn't demonstrate the runtime-fetch class of attack you described — that was the gap. Static scanning + dynamic analysis in a no-network sandbox catches the supply-chain side; the post-exec filter catches the runtime side.
2. "Genuinely curious how you'd catch a tool-description-poisoning attack" (Jul 17)
"Genuinely curious how you'd catch a tool-description-poisoning attack where the MCP server serves different descriptions per client — that's the one I'd want answered before installing from any marketplace, and none of the 8 seem aimed at it."
The honest answer is: I don't have a complete solution to this yet. The partial fix is:
- At approval time, pin the tool catalog (list of tools + their input schemas) to a content hash
- At runtime, every tool description served by the MCP server must match the pinned hash
- If the server tries to serve a different description to a real client than what was pinned → block + alert
This catches the "server returns benign to scanner, malicious to client" attack if the scanner and the client both go through the same gateway. It does NOT catch the case where the server fingerprints the client and serves different descriptions to different clients based on TLS fingerprint, UA, or timing. That's an open problem — probably needs a non-trivial design (multi-client probing, diverse fingerprints) to detect.
Threat model document at https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/uta-repo/THREAT_MODEL.md has the explicit coverage map per attack class, including this one marked as "partial."
3. "Well done, thanks!!" (Jul 19) and "Great job, keep me updated" (Aug 8)
Acknowledged. Thanks for following along — your comments have been the most consistently sharp of any reviewer.
What's next
The canonical repo is now at https://github.com/alicelabs-llc/universal-trust-adapter (moved from eddyflores100-lang because my personal account got flagged by GitHub abuse-detection — ticket #4658791 open). Test vectors with canonical JCS bytes per fixture are at https://github.com/alicelabs-llc/universal-trust-adapter/tree/main/marketnow/docs/atc-spec/test-vectors.
If you want to run an independent verifier against the test vectors, the test CA private key is published at _test-ca-keys.json so any Python/Go/Rust verifier can re-derive the signatures from scratch.
— Edison
Top comments (0)