Skip to main content

​
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. 
npm audit signatures @walletsuite/mcp-server
The command verifies the attestation against the public Sigstore transparency log and returns the source repository, commit SHA, and workflow file used to build the package. Verification is independent of WalletSuite infrastructure: the trust anchor is the public transparency log, not any endpoint we control.

​
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.
SecretWhen requiredRuntime exposure
WALLETSUITE_API_KEYAlwaysRead once at startup; never logged
OWS_AGENT_TOKENHeadless / production (agent mode)Read once at startup; never logged
OWS_PASSPHRASEInteractive bootstrap and admin only (owner mode)Read once at startup; never logged
Agent token filesOwner-mode bootstrap outputLocal file, mode 0600; never returned in chat
Production and headless deployments run in agent mode with a scoped, policy-bound token. The vault passphrase is not required at runtime — it is used once by a human operator to bootstrap the vault and issue agent tokens, then does not need to be present in the environment where agents actually sign. This is the recommended production posture. By default, newly issued agent tokens are written to a local file with owner-only permissions (0600). The CLI can print a token to stdout instead, but only when invoked with an explicit, intentionally-named opt-in flag — so a CI job or wrapping script can’t capture a token through automation that didn’t ask for it. See Key Management for the owner/agent mode distinction 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.
See Audit Trail for the receipt schema and hash chain.

​
Dependency Surface

Published releases fail on any high or critical advisory against a runtime dependency; the full list is verifiable via npm view. For the broader posture on formal audits and third-party certifications that sit above the build pipeline, see Security Diligence → Certifications Roadmap.