How Treeova protects broker credentials and strategy IP: row-level security, AES-256 token encryption, HMAC webhooks, advisory locks, and an MFA-gated admin surface.

    Back to Blog

    Treeova's Security Architecture, Explained — A Plain-Language Companion

    Treeova TechnologiesApril 18, 20264 min read
    Share:

    Companion post. Plain-language summary of the Security & Data Architecture whitepaper. For the full methodology and limitations, read the whitepaper at /whitepapers/security-and-data-architecture.

    Why security gets its own whitepaper

    Treeova holds two kinds of high-value data: trading account credentials (broker tokens, OAuth grants) and strategy intellectual property (the agent chains and prompt templates a user has authored). Both deserve more than a vague "we take security seriously" line.

    Row-Level Security on every user-facing table

    Every table that holds user data uses Postgres Row-Level Security policies. Even if a query is somehow malformed, the database itself rejects access to rows the user doesn't own. RLS is the last line of defense.

    Encrypted broker tokens

    Broker OAuth tokens (Robinhood, TradeStation, Webull, TastyTrade) are encrypted with AES-256 before they're written to the database. Decryption happens only inside server-side functions that need to make a broker API call. The tokens are never exposed to the browser.

    HMAC-verified webhooks

    Inbound webhooks from brokers and integrations are verified with HMAC-SHA256 signatures. Unsigned or improperly-signed payloads are rejected before any business logic runs.

    Advisory locks for financial mutations

    Any mutation that touches a paper or live trading balance acquires a Postgres advisory lock first. This prevents race conditions when multiple actions hit the same account at once — a real concern for agentic systems that may fire several tool calls in parallel.

    MFA gate for the admin surface

    The internal admin surface is gated by enforced multi-factor authentication. Sensitive admin actions are also written to an append-only audit log with the actor, action, and target.

    What's intentionally withheld

    Specific lock IDs, exact procedure signatures, and individual super-admin user IDs are not published. They live in the codebase under access control.

    Limitations

    • No security architecture is invulnerable. Defense-in-depth reduces attack surface; it does not eliminate it.
    • Users remain responsible for protecting their own broker credentials on their own devices.
    • Third-party broker security is outside Treeova's control.

    Read the methodology

    Security & Data Architecture →