Signing modes: where each works

A signer that needs a local browser can't run on a hosted server, and a server-side key can't ask a human to approve each trade. Match the signer to the surface before you deploy.

The matrix

Surface	BrowserSigner (local wallet)	RemoteBrowserSigner (hosted wallet)	KmsSigner (AWS KMS)	LocalAccountSigner (raw key)
Claude Desktop plugin (your machine)	✅ default	—	✅	✅ dev only
Local Python script	✅	—	✅	✅
Self-hosted MCP, headless / Docker	❌	—	✅ recommended	✅ dev only
Hosted / remote MCP (Claude web, a shared server)	❌	✅	✅	⚠️ avoid
CI / automation	❌	❌	✅	✅ dev only

✅ works · ⚠️ works but discouraged · ❌ can't work · — not applicable

Why the ❌s

BrowserSigner is desktop-only. It opens a page on 127.0.0.1 and hands the transaction to a wallet extension in your local browser. There is no browser on a headless server, in Docker, or in CI, so it simply can't run there. This is the single most common surprise when moving from a laptop to a server.

A raw private key on a remote or shared host is a liability. It can sign anything, unattended, and it's sitting on a machine you may not fully control. Use KMS there instead — the key never leaves the HSM, and you can scope its IAM policy to kms:Sign on that one key.

Choosing

• Human at a desktop, wants to approve each trade → BrowserSigner (the plugin's browser mode). Most contained.
• Unattended, on any server → KmsSigner. No key on disk, no per-trade prompt; the spend caps are your backstop.
• Hosted app where users bring their own wallet → RemoteBrowserSigner.
• Local dev / sandbox only → LocalAccountSigner, with a dedicated limited-funds wallet.

The more automatic the signer, the more the guardrails matter: with KMS or a raw key there's no human in the loop, so caps and gates are what keep a mistake small. See Risk & responsible use.

Remote surfaces need real auth, too

A hosted MCP also has to authenticate its callers (not just sign transactions). It refuses to start on HTTP without a bearer token or OAuth. See Connect Claude web.