Security Overview

1.Why this page says what is missing

Most security pages list only strengths. That is not useful for deciding whether to trust a product with your work, so this one also says what CreatorBase does not have yet. If a control you need is in the second list, it is a reason to wait.

2.What is in place

• No passwords. Sign-in is a one-time link to your email. There is no password database to breach and no credential to reuse. The consequence is that your email account is the key to your CreatorBase account — protect it, and turn on two-factor authentication there.
• Encryption in transit. TLS on every connection, enforced.
• Encryption at rest. The database and file storage are encrypted by the platform.
• Per-account isolation in the database. Access is enforced by row-level security in Postgres, so isolation is a property of the database rather than something every query has to remember. A missing filter in application code cannot expose another account's rows.
• Connector keys are encrypted separately, with a key held outside the database, and are never sent back to the browser after you save them. A database dump alone does not yield your publishing credentials.
• Publishing requires an explicit action. A post goes out because you clicked publish or set a schedule. Automated runs are refused for brands set to require approval, and that is enforced in the publishing code rather than by asking a language model to behave.
• Duplicate publishes are prevented at the database level, by a unique constraint written before the provider is called. A retry after a timeout cannot double-post to your real account.
• Realtime voice bypasses our servers. Audio streams from your browser to the voice provider directly, with a short-lived token. We cannot record it.
• Least-privilege AI access. The assistant can only act through a fixed set of typed tools. It cannot run arbitrary code, reach arbitrary hosts, or read another account's data.
• Prompt-injection boundary. When analysing a third-party post, its text is treated as data, not as instructions. This matters because the same assistant holds publishing tools.
• Automated checks before release. Every change runs typechecks, tests, a lint gate, and checks for database schema drift and unreachable routes.

3.What is not in place yet

• No SOC 2, ISO 27001, or third-party penetration test. If your organisation requires a report before adoption, we do not have one.
• No two-factor authentication on CreatorBase itself. Sign-in security inherits from your email provider.
• No customer-managed encryption keys.
• No formal uptime commitment. See the Terms of Service.
• Access logging for support access is not yet exposed to customers.
• Single production region. Recovery from a total regional failure would rely on platform backups and would not be fast.

4.Operational practices

• Production access is limited to the operator, over authenticated sessions.
• Credentials are held in the hosting platform's secret storage, never in the repository. There are automated checks against committing them.
• Database changes go through reviewed migration files, and an automated check compares what the repository declares against what production has actually applied.
• Dependencies are pinned, and updates are reviewed rather than applied automatically.
• Backups are encrypted, taken by the database platform, and retained on a rolling 30-day window.

5.Reporting a vulnerability

Email [SECURITY_EMAIL](mailto:SECURITY_EMAIL). Include enough detail to reproduce it. If you want to encrypt the report, ask and we will send you a key.

Our commitments: we acknowledge within 3 business days, keep you informed, credit you if you want credit, and fix genuine issues as a priority over feature work.

We will not take legal action against you for good-faith research that follows the terms below. There is no bug bounty — we are pre-revenue and would rather say so than imply a payment we cannot make.

Please do:

• Test only against your own account.
• Stop as soon as you have confirmed a vulnerability, and do not access, modify, or retain anyone else's data.
• Give us reasonable time to fix it before publishing.

Please do not:

• Run denial-of-service or volumetric tests.
• Use social engineering or physical intrusion against us or our providers.
• Test our providers' own infrastructure — report those to them.

6.If there is a breach

We will notify affected users without undue delay and within 72 hours of becoming aware, at the email on the account. The notice will say what happened, what data was involved, what we have done, and what you should do — and will state plainly what is not yet known rather than waiting for a complete picture. Business customers also have the contractual notification terms in the DPA.