Security Architecture
How WalletSuite enforces non-custodial boundaries, scopes agent access with band filtering, and creates tamper-evident audit trails.
Last updated: April 2026
Non-custodial architecture
Non-custodial by architecture, with two paths. Default at all paid tiers: 2-of-2 MPC. WalletSuite holds one share, your team holds the other. Both signatures are required for every transaction — neither party can move funds alone.
For banks, custodians, and regulated institutions that require full custody: on-premise HSM signing. Keys are generated, stored, and used inside a FIPS-validated hardware module in your own data center. The keys never leave the hardware and cannot be exported. WalletSuite holds nothing — key material stays entirely within your environment.
The core principle is prepare ≠ sign ≠ broadcast. Each boundary is explicit and enforced by a different component. No single component — including WalletSuite — holds the full chain of custody.
MCP Server
no signing power
API
no signing power
MPC shares
split: WalletSuite + customer
On-prem HSM
customer hardware
Defense in depth at every layer
MCP Server: no key access
Attacker cannot sign — server holds no key material. Band filtering limits which tools are even visible.
Mitigated by designWalletSuite API: read-only chain data
Attacker gets read-only chain data (balances, fees). No signing capability, no key material.
Mitigated by designWalletSuite MPC share: half of a 2-of-2 quorum
Attacker has only one of two shares — cannot produce a valid signature without the customer share. Internal access is M-of-N gated and audit-logged.
2-of-2 quorumCustomer MPC share: half of a 2-of-2 quorum
Attacker has only one of two shares — cannot produce a valid signature without WalletSuite's share. Policy gates still evaluated server-side.
2-of-2 quorumOn-premise HSM: keys locked in FIPS hardware
Attacker needs physical access to the FIPS-validated hardware module and its authentication credentials. Keys never leave the hardware and cannot be exported.
FIPS hardware barrierRPC endpoint: read-only / relay only
Attacker can see or delay broadcast transactions. Cannot forge signatures or access keys.
Read-only exposureSecurity diligence
Most SOC 2 Type II controls ask one question: can an employee access customer funds? Our answer is architectural, not policy. In default 2-of-2 MPC, WalletSuite holds only one share, and the customer share is mathematically required for every signature. In on-premise HSM mode, we hold nothing at all — keys live inside customer-controlled FIPS-validated hardware on customer infrastructure, and signed transactions and the audit trail are emitted to customer-controlled destinations.
Employee access
No WalletSuite employee can move funds unilaterally. Internal access to our MPC share is M-of-N gated and audit-logged, and in on-premise HSM mode we hold no key material at all.
Prompt injection as a threat model
Band filtering is a prompt-injection defense, not just access control. Tools outside the configured band are never registered with the MCP client. An agent compromised by a malicious prompt cannot call what it cannot see — it can’t invent a tool to broadcast a transaction if broadcast is outside its band.
What else to verify
Trust boundary diagram: §01. Threat scenarios: §01. Audit trail mechanics: §05. Build hygiene: §07. Full enforcement mechanics and build pipeline in the security documentation (opens in new tab).
Band filtering MCP Server
Band filtering is a 4-tier access control system. Each band — read, prepare, sign, broadcast — is cumulative. An agent configured at the prepare band can access read and prepare tools, but nothing above.
Enforcement happens at server startup: tools above the band cap are not registered in the MCP tool registry. The agent cannot see or call them. This is not a runtime permission check — the tools do not exist for that session. Configure per agent role: an analytics agent gets read, a trading bot gets sign.
Query chain state
get_balance, get_transactions, get_fees
Construct unsigned tx
prepare_transfer, prepare_onramp
Policy-gated signing
sign_transaction (MPC default · on-prem HSM)
Submit to chain
send_transaction (user RPC)
The only wallet MCP server with infrastructure-enforced tool isolation.
Band filtering in the glossarySpend governance MCP Server
Band filtering decides what an agent can call. Spend governance decides whether a specific operation should proceed — and under what rules.
Policy + Agent Key
Evaluated together by the policy gate, before any key access. The agent key carries the policy set — both are validated in the same call. A mismatch rejects the request.
Policy rules
- Per-transaction spend limit
- Daily aggregate cap
- Chain allowlist
- Counterparty screeningBeta
Credential
- Scoped to one wallet
- Bound to one policy set
- Expires on a configurable window
If any rule rejects, signing never happens. Every pass, reject, and revocation is recorded
Audit trail MCP Server
Every signing and broadcast attempt is logged as a structured JSONL event. Each event includes a SHA-256 hash of the previous event, forming a tamper-evident chain.
Fields captured: operation type, agent identity, wallet address, chain, timestamp, band, policy evaluation result, and the hash link to the previous event.
The hash chain means you can independently verify that no event was inserted, modified, or deleted after the fact — without trusting WalletSuite infrastructure. Logs are exportable in JSON format for ingestion into your SIEM, compliance tooling, or archival storage.
Data & encryption
Applies to both the REST API and MCP Server.
In transit
HTTPS enforced on all endpoints (localhost exempt for dev). Database connections require SSL.
At rest
MPC shares encrypted at rest with envelope encryption (KMS-backed CMK per tenant). On-premise HSM stores keys inside the FIPS-validated hardware module; keys never exist outside the module. Database storage encrypted.
Key material
Never plaintext on disk, never transmitted over the network. In MPC mode, no party ever assembles the full key. In on-premise HSM mode, keys are generated, stored, and used inside the hardware module — they never enter host memory.
API authentication
API key required for all mutating endpoints. Rate limiting enforced per key.
Logging
Operation labels only — no URLs or wallet addresses in logs. Error messages never expose internal state.
Deployment
MCP Server — On-premise HSM
Runs on your infrastructure. The FIPS-validated HSM keeps keys inside the hardware module — they never leave your data center. Chain data is served by the WalletSuite API.
MCP Server — Hosted MPC
2-of-2 DKLS23 MPC managed by WalletSuite’s co-signing service. WalletSuite holds one share, customer holds the other — both required to sign. Same band filtering, policy gates, and audit trail without infrastructure overhead.
The REST API ships as a standalone product — same wallet operations over HTTP, across every supported chain. Pair with hosted MPC (default), on-premise HSM, or your existing signer.
Deployment documentation (opens in new tab)Compliance
Formal certifications are in progress. Today, WalletSuite’s security posture is built on non-custodial architecture, infrastructure-enforced governance, and a tamper-evident audit trail.
Responsible disclosure
If you discover a security vulnerability, please report it directly. Do not open a public GitHub issue.
We will:
We do not currently operate a bug bounty program.
Ship with security built in
Policy-gated signing, band filtering, and audit trails — ready in under 15 minutes.