BeforeRed only reads the public, official, documented APIs your providers already publish. We never see your source code, your database rows, your customer data, or your environment. This page explains exactly what we do, what we don't, and where we are right now.
These are not slogans. They are the rules that decide what BeforeRed ships and what BeforeRed refuses to ship. They are derived from the product's security and privacy commitments. Every feature has to fit inside them.
The narrowest provider credential available.
New connections are offered only where the provider supports a credential restricted against infrastructure changes. The connection flow identifies the exact scope and requires confirmation before accepting it. Broader personal, deploy, admin, and account-wide credentials are not offered as onboarding paths.
AES-256-GCM with a server-only key.
Every provider credential is encrypted before storage using AES-256-GCM, a server-only 32-byte encryption key, and a unique random IV. The encrypted record stores ciphertext, IV, and authentication tag. Credentials are never sent back to the browser after connection.
We read usage, not your data.
BeforeRed never reads your application source code, database rows, customer emails, environment variables, or user passwords. The product is built around a single line: we monitor your usage, not your users.
Only official, documented provider APIs.
We do not reverse-engineer provider dashboards, depend on undocumented internal endpoints, or scrape web pages. Every value BeforeRed shows you comes from a documented public API that the provider publishes and supports. If a value is not exposed by that API, we show unknown.
No silent write access or infrastructure changes.
Connections are owned and authorized per user. Self-serve disconnect deletes the stored encrypted credential and stops future syncs while preserving prior usage history. Self-serve history and account deletion controls are still in progress.
IDOR tests on every route that touches a project.
Every app, project, and connection query requires ownership verification on the server. We never trust a user ID, workspace ID, or connection ID that comes from the client. Row-level security is a second layer, not a substitute. Authorization tests cover every route that touches a project.
Every provider token is encrypted before it touches our database. The live implementation uses AES-256-GCM with a server-only 32-byte key, a fresh random IV for each write, and an authentication tag. Credentials are never returned to the browser after connection.
Every credential is stored as AES-256-GCM ciphertext with its unique IV and authentication tag. Encryption happens in a server-only module before the database write.
The 32-byte encryption key comes from production secret configuration and is loaded only inside the server-side credential vault. No browser route returns decrypted credential values.
AES-GCM verifies the stored authentication tag during decryption. Modified ciphertext, IV, or tag fails instead of returning a corrupted credential.
Connection routes do not return stored credentials to the browser. Provider adapters redact credential-like values from errors before they reach application logs.
We would rather be honest about the size of our security program than borrow credibility from a certificate we do not hold. The list below is the actual state of the product and the company, not the marketing version.
If a security claim is not on this page, we are not making it. When we ship something here, this page is the place to verify it. When we move an item from in flight to in place, we update the page first and announce the change after.
The current implementation and its limits, without borrowing credibility from controls or certifications that are not live.
No. BeforeRed does not request access to source control, git history, or code repositories. Provider adapters make documented API reads for the bounded signals each integration supports.
BeforeRed adapters are designed around provider usage, project, account, and status APIs—not your application database or customer records. If an API does not expose a usable metric without reading customer data, BeforeRed shows unknown instead of computing it from that data.
Provider credentials are stored as AES-256-GCM ciphertext with a unique IV and authentication tag. The 32-byte encryption key is server-only and is not stored in credential rows. A database-only compromise would not expose plaintext credentials, but a full application and secret compromise remains serious and would require key rotation and provider-token revocation.
A self-serve export is not shipped in the current alpha. Do not connect production credentials if you require a self-serve export or deletion workflow before using the product.
Encrypted at rest in the application database using AES-256-GCM. Each record contains ciphertext, a unique random IV, and an authentication tag. The 32-byte encryption key is server-only. Stored credentials are not returned to the browser after connection.
No. BeforeRed does not hold or claim a SOC 2 report today. The status section on this page lists the controls and certifications that are and are not in place.
Self-serve account deletion is still in progress. Do not connect production credentials if you require that control before using the alpha. Paid subscriptions are not active.