WP-09 — Security & Data Architecture

Treeova operates an AI-driven options trading platform where users delegate execution authority — for paper or live accounts — to autonomous agents. That delegation creates a strict requirement: the platform must enforce data isolation, credential protection, and administrative accountability at every layer of the stack.

This whitepaper documents the security and data architecture that backs those requirements. It covers the controls that govern user data, broker credentials, administrative access, and the paper-versus-live boundary. Implementation-level identifiers (function names, lock identifiers, exact column lists) are intentionally withheld.

See the product surface for the broker-credential controls described here: Feature page for Connect Trade. For a non-technical summary of the same controls, see the Security overview.

Every database table that holds user-owned data has row-level security (RLS) enabled. RLS policies are written so that the authenticated user identifier must match the row's owner column before a read or write succeeds. The policy is enforced by the database, not the application — so an application-layer bug cannot bypass it.

Privileged read paths used by the platform itself (for example, intelligence aggregation across symbols) execute under a service-role context that is administrative-only and never reachable from a user session. This separation is the single most important control in the platform's security model.

Broker connections never store passwords. They use OAuth tokens or API keys issued by the broker. Tokens are encrypted with AES-256 before being persisted, and the encryption boundary lives outside the application code path that handles user requests.

Token refresh is handled server-side; the client never sees the access or refresh token. Compromise of a single user session cannot exfiltrate broker tokens because the tokens are not loaded into client memory.

The fully funded paper trading environment is fully isolated from live broker accounts. Paper executions are simulated inside the platform and never reach a real broker. Paper accounts, balances, and positions live in separate tables from their live counterparts.

The agent execution layer enforces this boundary at runtime: an agent assigned to a paper account cannot execute against a live account, and vice versa. This boundary is verified before every execution, not just at agent assignment time.

Administrative roles are role-gated and require multi-factor authentication for sensitive actions (role assignment, credential rotation, billing adjustments, agent overrides). Every privileged read or write — even read-only inspection of user data for support — appends an immutable record to an audit log.

The audit log captures the acting administrator, the action, the target table or user, the access timestamp, and request metadata such as IP address and user agent. The log is append-only and retained for compliance review.

AI agents execute inside a sandbox that limits them to an explicit set of tools and data scopes assigned by the user. The runtime enforces a modality security gate that validates each tool call against the agent's permitted modality before execution. Tools that can move money or change broker state require additional symbol pinning and safety checks before they fire.

Every agent run produces full telemetry — input and output tokens, tool calls, execution duration, and cost — which is retained for observability and post-hoc review.

Inbound webhooks (broker callbacks, payment events, alert triggers) are verified using HMAC-SHA256 signatures with rotating secrets. Requests that fail signature verification are rejected before touching application logic. Outbound integrations (alert delivery to Discord, Telegram, X, email) resolve recipients server-side against the user's verified integrations only — agents cannot inject arbitrary recipients.

This whitepaper documents the controls in place; it is not a guarantee against every possible attack. Specifically:

• Treeova's controls protect data inside the platform. Compromise of a user's email account, password manager, or device can still allow an attacker to authenticate as the user. We strongly recommend MFA on the user's email and the use of a password manager.
• Broker-side incidents (broker outages, broker API breaches) are outside Treeova's control. Treeova exposes broker-reported errors transparently in the trading workspace.
• No security architecture is static. Treeova reviews and updates controls regularly; this whitepaper is versioned and will be re-issued as the architecture evolves.