Skip to main content
This page covers MCP-specific security: how the MCP surface bounds what an AI agent can do. For the cross-surface trust model (signing-layer guarantees, audit trail mechanics), see Security Overview.
WalletSuite MCP is non-custodial. Signing runs through MPC 2-of-2 (DKLS23): WalletSuite holds one key share, the customer holds the other, and both are required for every signature. No full private key is ever assembled. See Trust Model for the full table.

​
Bands as prompt-injection defense

WalletSuite MCP exposes tools through four bands. Tools outside the active band are never registered in the MCP schema — the LLM cannot discover or call them.
BandWhat it allows
readbalances, prices, fee quotes, asset resolution, transaction status and history
preparetransaction-preparation tools
signwallet lookup and detached signing
broadcastsign-and-send
Inactive tools do not appear in tools/list, have no callable handler, and cannot be discovered through any in-session negotiation. An agent compromised by a poisoned search result, hostile tool output, or injected user instruction cannot call a tool the client doesn’t know exists. Bands resolve once at server startup; there is no per-request override. The default is read. Expand only as your workflow requires.

​
Why the default stays narrow

A safe rollout:
  1. start with read
  2. move to read,prepare when you need transaction preparation
  3. add sign when you are ready to issue scoped agent tokens
  4. add broadcast only when you are ready to execute on-chain actions
See Band Filtering for multi-agent patterns.

​
Detached signing vs broadcast

sign_transaction and send_transaction are intentionally separate. sign_transaction — detached signing of raw unsigned transaction hex. Sensitive, but does not submit anything on-chain by itself. send_transaction — signs and broadcasts in one step. The destructive path. Requires:
  • the broadcast band
  • confirmBroadcast=true in the call

​
MCP tool-surface boundaries

The MCP tool surface only ever receives:
  • wallet identifiers (names, addresses, chain ids)
  • raw unsigned transaction payloads
  • policy parameters at agent-token issuance
It does not receive or return:
  • mnemonics
  • private keys
  • the customer-side MPC share
This is enforced at the schema layer — there is no MCP tool whose arguments or return type carries key material.

​
Secrets stay out of tool arguments

Sensitive values are supplied through environment variables, never through tool arguments:
  • WALLETSUITE_API_KEY
Secrets stay out of prompt history and tool-argument logs.

​
Why WalletSuite MCP is closed-source

WalletSuite MCP is distributed as a product surface through the published npm package and Docker image, while the core implementation remains private. Trust comes from:
  • non-custodial MPC 2-of-2 architecture (see Security Overview)
  • signing boundaries enforced inside the signing layer, outside the LLM’s reach
  • explicit capability controls through bands, agent-token scopes, and policy gates
  • clear operational documentation
Closed source does not change the custody model: WalletSuite still cannot sign alone.

​
Remaining risks

Non-custodial does not mean zero risk. MCP-specific risks the operator owns:
  • enabling broader bands than needed
  • approving or automating a transaction the agent did not present clearly
  • running the MCP server on a compromised host
  • leaking environment secrets (API keys, agent tokens)
Mitigation: keep bands narrow, scope agent tokens at issuance, and review destructive actions carefully.

​
Practical guidance

Defaults for a new install:
  • MCP_BANDS=read
  • signing through MPC 2-of-2; self-host the MCP server when you need it to run on your own infrastructure (the customer share never leaves it)
  • no broadcast until the signing flow is proven
Add capability deliberately, not all at once.