Context
Continue's .continuerc.json lets users wire up arbitrary MCP servers, tools, and models. The threat surface is real — anyone can publish an MCP server, and there's no canonical way for a Continue user to inspect who issued the credential for a tool before executing it.
I'm not alleging a vulnerability in Continue. I'm proposing an opt-in verification layer that any user can install alongside Continue's MCP loader.
What we built
Universal Trust Adapter (UTA) — https://github.com/alicelabs-llc/universal-trust-adapter
UTA verifies credential cards issued in 8 formats:
- ATC v3 (Agent Trust Card)
- JWT (with
x5c chain)
- W3C Verifiable Credentials
- A2A (Agent-to-Agent) cards
- EAT-AI (Entity Attestation Tokens)
- ZTA (Zero Trust Agent) cards
- MCP Server Cards
- X.509 certificates
It exposes a 12-stage pipeline: PARSER → DETECT → SCHEMA → CRYPTO → ISSUER → KEY_BINDING → POP → PROVENANCE → LIFECYCLE → EVIDENCE → POLICY → DECISION.
Live API: https://www.marketnow.site/api/trust?action=formats
Why open this issue
I'd like to know whether the Continue maintainers would accept a non-invasive integration: a config flag like experimentalTrustVerification: true that, when set, routes each MCP server's card through UTA before Continue's tool runner executes it.
If the answer is "we'd prefer to keep this out-of-tree," that's a valid answer and we'll respect it — we already ship a standalone CLI.
Happy to write a design doc if there's interest.
References
Context
Continue's
.continuerc.jsonlets users wire up arbitrary MCP servers, tools, and models. The threat surface is real — anyone can publish an MCP server, and there's no canonical way for a Continue user to inspect who issued the credential for a tool before executing it.I'm not alleging a vulnerability in Continue. I'm proposing an opt-in verification layer that any user can install alongside Continue's MCP loader.
What we built
Universal Trust Adapter (UTA) — https://github.com/alicelabs-llc/universal-trust-adapter
UTA verifies credential cards issued in 8 formats:
x5cchain)It exposes a 12-stage pipeline:
PARSER → DETECT → SCHEMA → CRYPTO → ISSUER → KEY_BINDING → POP → PROVENANCE → LIFECYCLE → EVIDENCE → POLICY → DECISION.Live API: https://www.marketnow.site/api/trust?action=formats
Why open this issue
I'd like to know whether the Continue maintainers would accept a non-invasive integration: a config flag like
experimentalTrustVerification: truethat, when set, routes each MCP server's card through UTA before Continue's tool runner executes it.If the answer is "we'd prefer to keep this out-of-tree," that's a valid answer and we'll respect it — we already ship a standalone CLI.
Happy to write a design doc if there's interest.
References
@marketnow/trust-core,@marketnow/trust-adapters,@marketnow/trust-gateway