Security & data handling

Enterprise bookkeeping and allocation software runs on visible trust. Pemabu separates cloud workbook services (auth, books, allocation monitoring) 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 (Books): After Link exchange, Plaid access tokens are encrypted with AES-256-GCM before persistence. Keys are derived from PLAID_ENCRYPTION_KEY (or AUTH_SECRET as fallback) via SHA-256 key derivation. Ciphertext includes a random IV and authentication tag.

Sensitive books fields: Account and routing numbers may be protected with field-level AES-256-GCM when FIELD_ENCRYPTION_KEY is configured (64 hex characters / 32 bytes).

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 (allocation) and isolated Pemabu Books Postgres rely 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 software for monitoring, bookkeeping, reconciliation, 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. Books, 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.

Audit & attestation: Optional Flomisma pipeline anchors and books audit trails support enterprise evidence export; immutable logs in vault mode support SOC 2-style evidence collection.

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
• Multi-tenant isolation via Supabase RLS and books Postgres deny-by-default API roles
• Plaid tokens and sensitive fields encrypted at rest (AES-256-GCM)
• Sentry monitoring with PII stripped; secrets managed via Infisical / Vercel env — never in git

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

Pemabu is designed for monitoring, bookkeeping, 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. See Close + Attest for how period close couples to settlement anchors.

• 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 managed via Infisical in development; production env vars in Vercel/Infisical — 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.