> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Security & Trust
> MCP-surface security — the tool profile as prompt-injection boundary, detached signing vs broadcast, and secret isolation.
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](/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](/ai-agents/execution-levels). What an admitted tool is allowed to sign is decided separately by the [policy engine](/core-concepts/policy-gates).
## 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](/core-concepts/policy-gates) 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](/ai-agents/token-exchange).
## 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.
## Related
The cross-surface, non-custodial trust model.
What each tool profile grants.
The deterministic decision point that authorizes every signing intent.
How the agent's key is handled.