Keys Isolation
No WalletSuite employee can access keys, signed transactions, or the audit trail in a self-hosted deployment.- Keys are generated inside the OWS vault on the customer infrastructure. They never leave.
- Signing happens inside OWS, on the customer infrastructure, against a key that exists in decrypted form only for the duration of the signing call.
- Audit receipts are appended to a JSONL file on the customer disk.
Data Residency
The audit trail, OWS vault, and signed payloads exist only on customer infrastructure — any cloud, on-prem, bare metal, or edge environment the customer chooses. There is no “WalletSuite copy.” Whatever network boundary a deployment sits behind, that is where this material stays. The WalletSuite backend API serves public chain data: balances, fees, metadata, unsigned transaction payloads. Residency requirements that apply to operational secrets or signing material are satisfied by the fact that those never leave customer infrastructure. Requirements that apply to public chain data are satisfied by the fact that it is public.Deployment Modes
Today, the only deployment mode is the self-hosted MCP server, which ships with the OWS vault built in. Everything on this page assumes that mode. The “no customer data on our systems” claim holds categorically because there is no other mode. A hosted offering is on the roadmap. When it ships, customers choose one of two modes: fully self-hosted (today’s deployment — the server and vault run on customer infrastructure) or fully hosted (the server and vault both run on WalletSuite infrastructure, with signing inside a hardware-attested enclave).Band Filtering as Prompt-Injection Defense
Band filtering is also a prompt-injection defense — enforced at the tool-visibility layer. Tools outside the active band are never registered with the MCP client. They do not appear intools/list, do not have a callable handler, and cannot be discovered through any in-session negotiation. An agent compromised by a malicious prompt — a poisoned search result, a hostile tool output from another server, a user instruction that was actually an injected command — cannot call a tool that the client does not know exists. It cannot invent send_transaction if broadcast is outside its band.
The enforcement point is the tool schema itself, not a runtime permission check. Bands are resolved once, at server startup, and reflected in the tools/list response the LLM receives. A model cannot reason around a tool that was never surfaced.
See Band Filtering for the band hierarchy and configuration.
Verification Path
- Architecture — Security Overview. Trust boundary, defense in depth, attack model.
- Key lifecycle — Key Management. Vault encryption, BIP-39/44 derivation, memory hygiene.
- Audit trail — Audit Trail. Receipt schema, hash chain, redaction model.
- Build provenance — Build & Supply Chain. Signed releases, runtime response validation, secret boundary.
- SDK source — public at github.com/walletsuite.
Incident Response
If you find a vulnerability, security@walletsuite.io is the canonical contact. The Responsible Disclosure page documents acknowledgment SLAs, severity definitions, and scope. For operational incidents on a customer deployment, the audit trail is the starting point. The hash chain lets an operator prove, after the fact, that no entries were inserted, modified, or removed. Exporting the trail to a SIEM preserves this property across longer retention windows than a single host.Certifications Roadmap
Formal certifications are on the plan for procurement readiness. They do not change the architectural guarantees above.| Certification | Status |
|---|---|
| SOC 2 Type II | Planned — 2026 |
| CCSS Level 2 | Planned |
| Independent penetration test | In progress |
Related
- Security Overview — trust model and defense in depth
- Key Management — OWS vault and key lifecycle
- Audit Trail — tamper-evident receipts
- Build & Supply Chain — signed releases and runtime validation
- Responsible Disclosure — reporting vulnerabilities