Security model

This is the one Core surface where software can move funds without a human approving each transaction. That design demands clarity about what protects you and what does not.

The boundary

Three mechanisms, layered:

1. Custody: CubeSigner. Private keys live in CubeSigner's hardware-backed signing service, not on the MCP server and never in the agent's context. A compromised agent cannot exfiltrate keys, because no component it talks to holds them.
2. Authorisation: the signed policy. Every call is evaluated against the policy — accounts, networks, spend limit, recipients. The policy is signed by your wallet, so the server rejects any stored policy that fails signature verification.
3. Identity: OAuth. Tokens are per-user and per-client, bound to your core.app identity, and revocable at both ends (authentication).

What the boundary does not cover

Be honest with yourself about these before granting a policy:

• The agent's judgment. Within the policy, the agent decides what to do. A prompt-injected or simply wrong agent can spend up to your limit on legitimate-looking nonsense — to an allowlisted recipient, on an allowed network, inside the cap. The spend limit is the blast radius, not a guarantee of good decisions.
• Recipient quality. The allowlist checks addresses, not outcomes. Allowlisting a contract means trusting what that contract does.
• Your assistant account. Anyone who controls your Claude or ChatGPT account controls an authenticated agent. Protect it like a financial login.

Practical posture

• Dedicated agent account, minimal funding, low spend limit (starting policy).
• Review the activity log — especially refusals.
• Disable the policy when not actively using agents; re-enabling is one signature.

Reporting

Found a vulnerability in the MCP server or policy engine? See reporting a vulnerability — wallet infrastructure is in scope for the bug bounty.