Signed Releases
Every npm release of@walletsuite/mcp-server is published with provenance attestation. Provenance is a Sigstore-backed, OIDC-signed claim linking the tarball to the exact source commit and workflow run that produced it.
Runtime Response Validation
Every backend response consumed by a tool is validated against a typed contract before it reaches the LLM. A tampered or unexpected response fails schema validation and surfaces as a structured, sanitized error — it never becomes input to agent reasoning. The same validation boundary applied to tool arguments is applied symmetrically to the other side of the API call. Token amounts are preserved losslessly as strings. Large integer values are never coerced to floats, eliminating a class of precision-loss issues on balances and transfer amounts.Prompt Injection and Tool Hygiene
Beyond band filtering, the server assumes the LLM is an untrusted caller:- Every tool input is validated against a Zod schema before any backend call. Address format, amount format, and mutually exclusive fields are enforced at the boundary.
- Every backend response is validated against a handwritten contract. A tampered or unexpected response fails schema validation and becomes a structured error, not agent input.
- Internal diagnostics are logged server-side and sanitized before reaching the LLM. The model sees a structured, user-safe error; the server retains the detail.
- Logs use operation labels rather than URLs. Wallet addresses, transaction parameters, and response payloads are not written.
Secret Boundary
Secrets are supplied through environment variables at process launch. They are never passed as tool arguments, never returned in tool responses, and never written to prompt history or audit receipts. Environment variables are the injection interface, not the storage mechanism. Production deployments are expected to source secrets from a secrets manager — HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Kubernetes Secrets, Docker Secrets, or systemd credentials — and materialize them into the process environment only at launch. The server does not integrate with any specific KMS; the standard 12-factor injection path covers every major platform.| Secret | When required | Runtime exposure |
|---|---|---|
WALLETSUITE_API_KEY | Always | Read once at startup; never logged |
WALLETSUITE_PASSPHRASE | When the server holds the customer key share | Decrypts the local share at rest; read at startup, never logged |
WALLETSUITE_PASSPHRASE.
See Key Management for the signing model and full credential lifecycle.
Logging and Redaction
Logs are designed to be useful for forensics without leaking request-identifying material.- Operation labels replace URLs. Wallet addresses, transaction payloads, and request parameters are not logged.
- Internal diagnostics are retained server-side. The LLM receives a structured, sanitized error; the operator’s logs retain the detail.
- Audit receipts use schema-driven redaction: only dynamic text fields are scanned for inline secret patterns. Operational fields — wallet name, chain, identifiers, hashes, policy IDs — are preserved for audit, compliance, and forensic review.
- Transaction hex is truncated before write, so even a serialized payload containing key material would not land in storage intact.
Dependency Surface
Published releases fail on any high or critical advisory against a runtime dependency; the full list is verifiable vianpm view.
For the broader posture on formal audits and third-party certifications that sit above the build pipeline, see Security Diligence → Certifications Roadmap.
Related
- Security Overview — trust model and defense in depth
- Key Management - MPC signing, key shares, key lifecycle
- Audit Trail — receipt schema and hash chain
- Security Diligence — how to evaluate WalletSuite without SOC 2
- Responsible Disclosure — reporting a vulnerability