Skip to main content
This page covers MCP-surface security: how the hosted MCP endpoint bounds what an AI agent can do. For the cross-surface, non-custodial trust model, see Security Overview → Trust Model.

​
The tool profile is the prompt-injection boundary

An agent never holds every tool. Its callable surface is the server-owned tool profile bound to the agent, narrowed by the scopes in its short-lived token. Tools outside that intersection are never registered in the MCP schema WalletSuite hands this agent. The consequence is structural: the tool simply does not exist for this agent. It is absent from tools/list, has no callable handler, and cannot be reached through any in-session negotiation.
A poisoned search result, hostile tool output, or injected user instruction can only invoke a tool the schema exposes. It cannot call one that was never registered for this agent — there is nothing to name.
The profile is set on WalletSuite’s side, not by the caller, and the model never sees the credential that would let it request more. What each level grants lives in Execution Levels. What an admitted tool is allowed to sign is decided separately by the policy engine.

​
Detached signing vs broadcast

sign_transaction and send_transaction are intentionally separate tools, both at the Execute level.
  • sign_transaction — detached signing of raw unsigned transaction hex. Sensitive, but submits nothing on-chain by itself.
  • send_transaction — signs and broadcasts in one step. The destructive path. Beyond the Execute tool profile, it additionally requires an explicit confirmBroadcast=true in the call.
Either way the policy engine authorizes every signing intent before a signature is produced — the tool being reachable is not authority to move value.

​
Tool arguments never carry key material

The MCP tool surface only ever receives:
  • wallet identifiers (names, addresses, chain ids)
  • raw unsigned transaction payloads
It never receives or returns mnemonics, private keys, or a signing share. This is enforced at the schema layer — no MCP tool has an argument or return type that carries key material.

​
Secrets stay out of tool arguments

The agent’s key never reaches the model, a prompt, or a tool argument. Your server uses it to authorize the agent and injects the resulting short-lived token as an Authorization header on the MCP connection — never as a tool argument, so it stays out of prompt history and tool-argument logs. See Connect Your Agent.

​
Residual risks

Non-custodial does not mean zero risk. On the hosted MCP surface, the operator owns two controls:
  • Safeguard the agent’s key. It is the agent’s identity; anyone holding it can mint tokens for that agent until it is revoked. Keep it server-side and rotate on suspicion.
  • Grant the minimum tool profile. Bind an agent to the narrowest profile its workflow needs and widen deliberately, not all at once.
Review destructive actions carefully. A reachable send_transaction still needs confirmBroadcast=true and still clears policy — but confirming a transfer the agent did not present clearly defeats both.

Security Overview

The cross-surface, non-custodial trust model.

Execution Levels

What each tool profile grants.

Policy Gates

The deterministic decision point that authorizes every signing intent.

Connect Your Agent

How the agent’s key is handled.