> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Diligence

> How WalletSuite answers security diligence questions today.

No full key ever exists on WalletSuite infrastructure. The property is structural, not a policy promise — and it is the starting point for every other question on this page.

## Keys Isolation

No WalletSuite employee can move customer funds unilaterally.

Signing runs through non-custodial MPC threshold signing. WalletSuite operates a fully-managed cosigner holding one key share; the customer holds the other. Both shares are required to produce a valid signature, and no full private key is ever assembled in one place. Neither party alone can sign — the property is mathematical, not contractual. WalletSuite's share is envelope-encrypted at rest behind the scenes; internal access to it is M-of-N gated and audit-logged.

The backend API sees chain queries and transaction preparation requests — public blockchain data and the address involved. It cannot access signatures, key shares, or signed payloads.

The [Trust Model](/security/overview#trust-model) enumerates what each component can access.

## Data Residency

The customer key share is held in the customer's own storage — a database, HSM, device, or passkey-wrapped envelope, on any infrastructure the customer chooses. There is no "WalletSuite copy" of it. Whatever boundary that storage sits behind, that is where the customer share stays; it never reaches WalletSuite.

The WalletSuite backend API serves public chain data: balances, fees, metadata, unsigned transaction payloads. Residency requirements that apply to signing material are satisfied by the fact that the customer share stays in customer-side storage and no full key is ever assembled. Requirements that apply to public chain data are satisfied by the fact that it is public.

## Deployment

WalletSuite is a hosted platform. WalletSuite operates the MCP runtime and the fully-managed MPC cosigner — there is nothing for the customer to run or patch. Where the *agent* runs is the only axis:

1. **Managed or embedded assistant.** WalletSuite operates the agent runtime. The model never sees a credential or a token.

2. **Customer-owned agent.** Your model and framework run on your own infrastructure and [connect to](/ai-agents/token-exchange) the hosted MCP endpoint: your server holds the agent's key, authorizes the agent, and points the MCP client at the hosted endpoint. The raw key never reaches the model.

The signing guarantee is identical in both shapes — non-custodial, no full key ever assembled. Where the agent runs does not weaken it.

## The Tool Profile Is the Prompt-Injection Boundary

Each agent's callable surface is only the tools its server-owned profile and token scopes allow; anything outside is never registered in the MCP schema, so a compromised model — a poisoned search result, a hostile tool output, an injected instruction — has nothing to invoke. The profile is set on WalletSuite's side, never by the caller. See [Security & Trust](/ai-agents/security-model) for the full boundary.

See [Security & Trust](/ai-agents/security-model) for the tool-profile boundary, and [Execution Levels](/ai-agents/execution-levels) for what each level grants.

## Verification Path

1. **Architecture** — [Security Overview](/security/overview). Trust boundary, defense in depth, attack model.
2. **Key lifecycle** — [Key Management](/security/key-management). Threshold share custody, share storage, and signing flow.
3. **Audit trail** — [Audit Trail](/security/audit-trail). Receipt schema, hash chain, redaction model.
4. **Build provenance** — [Build & Supply Chain](/security/build). Signed releases, runtime response validation, secret boundary.
5. **SDK source** — public at [github.com/walletsuite](https://github.com/walletsuite).

## Incident Response

If you find a vulnerability, [security@walletsuite.io](mailto:security@walletsuite.io) is the canonical contact. The [Responsible Disclosure](/security/responsible-disclosure) page documents acknowledgment SLAs, severity definitions, and scope.

For operational incidents, 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     |
| ISO 27001                    | Planned     |
| CCSS Level 2                 | Planned     |
| FIPS 140-3 (MPC module)      | Planned     |
| Independent penetration test | In progress |

Auditors and target quarters will be published once engagements are signed. Until then, the architecture is the proof.

## Related

* [Security Overview](/security/overview) — trust model and defense in depth
* [Key Management](/security/key-management) — MPC share custody and key lifecycle
* [Security & Trust (AI Agents)](/ai-agents/security-model) — the tool profile as prompt-injection boundary
* [Audit Trail](/security/audit-trail) — tamper-evident receipts
* [Build & Supply Chain](/security/build) — signed releases and runtime validation
* [Responsible Disclosure](/security/responsible-disclosure) — reporting vulnerabilities