How does Draftbit protect my code, data, and secrets?

Draftbit’s published security statement makes a few commitments. Your code is never used to train AI models, and you keep ownership and intellectual property rights over everything you build. API keys and credentials are encrypted at rest with AES-256, data in transit uses TLS, access controls limit who can see sensitive values, and the platform has regular security audits.

In the code itself, encryption at rest is applied field by field to the values that matter most. GitHub access and refresh tokens, organization and app secrets, environment variable values, database connection strings, MCP server tokens, and Supabase keys and passwords are stored encrypted rather than as plain text.

Where a value lives in your app matters as much as how we store it. Sensitive values in Build Config are meant for build-time configuration and server-side tooling, and they are not exposed to the compiled app. Plain text variables use the EXPO_PUBLIC_ prefix and are bundled into the app, so anyone who installs it can read them. Put only public identifiers there, and keep private keys on a backend that checks who is asking before it acts.

Access to a project is controlled through organization roles. Viewers get a read-only preview, editors change the app, owners and admins invite and remove members, and only the owner changes roles. Single sign-on with SAML is an Enterprise feature, and Enterprise agreements can also cover custom SLAs, dedicated infrastructure, and private hosting options.

Two things stay with you. Customer data usually lives in the backend you choose, so that backend’s permissions, backups, and retention rules are yours to set. And when you connect your own AI subscription or API key, that provider’s terms apply to the requests it handles.

If your security review needs a certification, a data location commitment, or incident terms in writing, ask about Enterprise terms rather than inferring them from this page.