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.
Opt-out for HFT trading agents that need sub-millisecond local signing: OWS (Open Wallet Standard). Keys are derived locally via BIP-39/BIP-44 and stored in an AES-256-GCM encrypted vault on your infrastructure. Keys are decrypted in process memory only for the duration of a signing operation, then wiped. 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
OWS Vault (opt-out)
user-controlled
What happens if a component is compromised?
MCP Server compromised
Attacker cannot sign — server holds no key material. Band filtering limits which tools are even visible.
Mitigated by designWalletSuite API compromised
Attacker gets read-only chain data (balances, fees). No signing capability, no key material.
Mitigated by designWalletSuite MPC share compromised
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 compromised
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 quorumOWS Vault compromised (opt-out)
Attacker needs the vault passphrase. Keys are AES-256-GCM encrypted at rest, never plaintext on disk.
Encryption barrierRPC endpoint compromised
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 OWS opt-out mode, we hold nothing at all — keys, signed transactions, and the audit trail live entirely on customer infrastructure.
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 OWS opt-out 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 · OWS opt-out)
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 inside OWS, 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). OWS vault encrypted with AES-256-GCM, scrypt + HKDF-SHA256 envelopes. 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 OWS mode, decrypted in-memory only during signing, then wiped.
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 — Self-hosted (OWS)
Today’s live deployment. Runs on your infrastructure. OWS vault keeps keys local — they never leave your network. 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), self-hosted OWS, 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.