Security & data handling

Enterprise allocation software runs on visible trust. Pemabu separates cloud workbook services (auth, allocation monitoring, Flywheel) from optional sovereign vault (encrypted credentials on your infrastructure). Autonomous trade execution is paused at launch; paper sandbox is opt-in only. This page summarizes encryption, token storage, and our Zero-Custody framework. It supplements our Privacy Policy.

Bank connectivity, payments, and core infrastructure are delivered through authorized third-party APIs. We display partner attribution where those integrations are active.

In transit: All production traffic is served over HTTPS/TLS. Content-Security-Policy headers restrict script and connect sources; mutation API requests require CSRF validation when a session is present.

Plaid access tokens (brokerage sync): After Link exchange, Plaid access tokens are encrypted with AES-256-GCM before persistence. Keys are derived from MASTER_VAULT_KEY via key derivation. Ciphertext includes a random IV and authentication tag.

Sovereign vault credentials: Exchange API keys stored in local vault mode use AES-256-GCM under MASTER_VAULT_KEY (minimum 16 characters). Decryption occurs only inside the vault plane when deployed locally — not on serverless cloud hosts.

Database: Supabase Postgres relies on provider encryption at rest. Application-layer encryption is applied to high-sensitivity tokens and fields as described above.

Public API keys (Pemabu API): When you create a programmatic API key, we store only a SHA-256 hash and a short display prefix. The raw key is shown once at creation; we cannot recover it later.

Plaid tokens: Encrypted at rest as described above. Tokens are decrypted only server-side during sync jobs and webhook handling; they are never returned to the browser.

Exchange & broker credentials: Optional read-only sync keys may be stored per portfolio for position import. Live autonomous order placement is paused at launch. When paper sandbox is enabled, only sandbox/paper credentials are accepted. Pemabu does not persist exchange credentials in cloud Supabase or Vercel serverless infrastructure unless you deploy sovereign vault mode.

Market data keys: Tiingo and similar quote-provider tokens may be stored per portfolio for price refresh in cloud workbook mode. These are read-only market data credentials, not trading keys.

Session & CSRF: Authentication sessions are managed by Supabase Auth (HTTP-only cookies). CSRF tokens are bound to the session via Web Crypto HMAC and validated on mutation routes.

Definition: Pemabu does not take custody of your funds, securities, digital assets. We provide a rules-based ranking display with read-only account sync, and — when you explicitly opt in — paper sandbox practice on brokers you authorize. We are not a broker, custodian, or registered investment adviser.

Cloud workbook (default — launch focus): Hosted on Vercel with Supabase. Allocation engine, drift alerts, rebalance preview, and read-only broker sync. EXECUTION_LIVE_MODE remains off; autonomous trade is paused.

Sovereign vault (optional): Docker Compose deployment with local Postgres vault for encrypted credential storage. Paper trading sandbox may be enabled as an opt-in tool (PAPER_TRADING_ENABLED=true) — not live autonomous execution at launch.

Consolidated view without moving custody: Sovereign and portfolio views aggregate positions you report or connect — Pemabu does not take title to underlying assets.

Pemabu runs on enterprise-grade cloud infrastructure with the controls below. We do not expose internal provider names in customer contracts — this summary reflects what the product enforces in code.

• Production traffic served over HTTPS/TLS with Content-Security-Policy on workspace routes
• Owner-scoped access via Supabase RLS and deny-by-default API roles
• Plaid tokens and sensitive fields encrypted at rest (AES-256-GCM)
• Sentry monitoring with PII stripped; secrets in Vercel environment variables — never in git

See also product glossary for how "sovereign vault" differs from Sovereign View and category positioning.

Pemabu is designed for display, read-only sync, and evidence export — not autonomous custody or live trade without explicit human review. There is no in-product HITL ticket queue for customers; the postures below describe how exceptions and high-risk actions are handled.

• Autonomous live trade execution is paused at launch — monitoring, rebalance preview, and opt-in paper sandbox only
• Flywheel swing parameters always remain pending_review; MCP tools structure output for human review, never auto-submit orders
• Settlement exceptions and spend-cap denials surface to the operator out-of-band — there is no customer-facing exception queue in the product
• Strategy Council and Copilot produce drafts and memos — not investment advice or binding trade instructions

Settlement exceptions and operator overrides are handled out-of-band by the platform operator — not through a Pemabu UI surface.

• Row-level security policies on Supabase tenant data
• Rate limiting on sensitive API routes (Supabase-backed limiter)
• Sentry error monitoring with PII stripped before export
• Secrets live in Vercel environment variables per environment; local development uses a gitignored .env.local — never committed to git
• Portfolio sharing and family-view tokens are HMAC-signed with expiry; read-only by design

Security questions or responsible disclosure: contact@pemabu.com. Include "Security" in the subject line.