Last updated: October 5, 2026
This policy describes how Manifest AI Labs LLC ("we", "us", "our") protects the systems and data behind Bracket Trade ("the Service"), including the web application at brackettrade.com, its API (including the API endpoints still served on the legacy domain vibetraders.app), and its integrations with brokerages and other providers. It applies to all production systems, all personnel with access to them, and all vendors that process Service data.
Bracket Trade runs entirely on managed cloud infrastructure. We operate no physical servers or data centers of our own; the physical security section below explains what we inherit from our providers.
We classify the data we hold into four tiers:
Handling rules follow the classification. Secrets are never written to application logs; API routes log only the endpoint, method, status, duration, and token identifier. Our error reporting strips credential-bearing headers and cookies, redacts secret-named fields, and redacts provider key formats from free text before a report leaves our servers, and these scrubbing rules are covered by automated tests. Stored secrets are not shown in the interface, apart from an explicit export of your own keys that you initiate, and are transmitted only to the service they belong to. User data is stored against the owning account in the database and is removed by cascade deletion when the account is deleted.
Infrastructure access. Access to production infrastructure (hosting, database, source control, payment, brokerage, and error-reporting accounts) is limited to authorized personnel on a least-privilege basis. Every such account is individually owned, protected by a strong unique password in a password manager, and protected by multi-factor authentication where the provider supports it. There are no shared accounts. Access is reviewed when roles change and revoked immediately when no longer required.
Application access. Users authenticate with email and password through NextAuth sessions. Queries that read or write user data are scoped by the owning account's identifier, so one user's data is not reachable from another user's session, apart from content a user explicitly shares (such as community posts). Administrative functionality is restricted to accounts with an explicit admin role. Agent and API connections use bearer tokens that are stored as hashes, can carry per-connection spending limits, and can be revoked by the user at any time.
Secrets management. Production secrets (database credentials, encryption keys, provider keys) live in the hosting platform's encrypted environment variable store, not in source control. Secrets are rotated when personnel with access leave, when a vendor reports a compromise, or when we have any reason to suspect exposure.
In transit: All traffic between users and the Service, and between the Service and its providers (Alpaca, Stripe, AI providers, the database), is encrypted with TLS 1.2 or higher. The Service is served exclusively over HTTPS.
At rest: The production database (Neon PostgreSQL) encrypts all data at rest with AES-256. On top of that platform-level encryption, we apply application-level encryption to the most sensitive fields: brokerage and AI provider keys are encrypted with AES-256-GCM using a key held in the hosting platform's encrypted environment variable store and never committed to source control, passwords are stored as bcrypt hashes, and connection tokens are stored as SHA-256 hashes. Compromise of a database backup alone therefore does not expose usable credentials.
Application layer. The codebase is written in strict TypeScript, and an automated pipeline runs the full test suite and typechecks on every pull request and on every push to the main branch. Dependencies are monitored through GitHub security advisories and npm audit, and vulnerable packages are patched according to severity: critical vulnerabilities within 72 hours, high within 7 days, and moderate within 30 days.
Platform layer. Because the Service runs on managed serverless infrastructure, operating system, runtime, and database engine patching is performed continuously by our hosting providers (Vercel and Neon) as part of their own audited security programs. We track their security bulletins and status pages.
Detection. Production errors are reported to our monitoring system in real time, and hosting and database dashboards alert on anomalous behavior.
Response. When a security incident is suspected we follow a defined sequence: identify and assess the scope, contain it (which can include revoking connection tokens, rotating secrets and encryption keys, disabling affected endpoints, or taking the Service offline), eradicate the cause, and recover. Because the Service holds revocable brokerage keys rather than funds, containment for a credential exposure centers on immediate revocation and instructing affected users to regenerate their brokerage keys.
Notification. If an incident affects user data we notify affected users by email without undue delay and within 72 hours of confirming the incident, and we notify affected partners, including Alpaca, where their users or systems are involved. Every incident ends with a written post-incident review.
Disaster recovery. The database provides continuous point-in-time recovery, giving a recovery point objective measured in minutes. The application is deployed immutably; any previous deployment can be restored in minutes, and all infrastructure configuration lives in version control. Our recovery time objective for full service restoration is under 24 hours, and recovery procedures are exercised as part of routine deployment and restore operations.
We own and operate no physical servers, data centers, or network hardware. All production workloads run in cloud facilities operated by our providers (Vercel and Neon, on infrastructure from major cloud platforms), which maintain independently audited physical controls including badge access, surveillance, and environmental protections, documented in their published SOC 2 and ISO compliance attestations. Devices used to access production systems are protected with full-disk encryption, automatic screen locking, and current operating system updates.
We use a small, deliberately chosen set of vendors and share with each only the data it needs to perform its function:
Before adopting a vendor we review its security posture, including published SOC 2 or ISO 27001 attestations, encryption practices, and breach notification commitments. We review this vendor list and each vendor's access at least annually and whenever our use of a vendor changes, and we remove access that is no longer needed.
This policy is owned by Manifest AI Labs LLC and is reviewed at least annually, and additionally after any security incident or material change to our architecture or vendors.
To report a vulnerability or ask a security question, contact us at support@brackettrade.com. We acknowledge vulnerability reports within 2 business days.