Built for the team your counsel asks about.
Brand-protection software handles trademark filings, counterfeit takedowns, and customer impersonation. The decisions that flow through it need a paper trail and a security posture you'd describe to your auditor. Here's what we ship.
Five layers of cross-tenant isolation.
Every customer's data lives in its own tenant scope. Cross-tenant access requires bypassing every one of the following layers — and at least the first two are enforced in code on every read and write.
URL path scoping
Every tenant-scoped Firestore path is constructed server-side from the slug parsed out of the request URL. Cross-tenant access requires bypassing path construction itself — there is no client-supplied tenant id.
Tenant membership check
Every server-side read or write that touches `tenants/{tid}/...` calls `requireMembership(tid, email)` before any DB call. Missing this check is treated as a P0 bug.
Default-deny Firestore rules
`firestore.rules` defaults every collection to deny. The Firebase Admin SDK that backs server-side Firestore calls bypasses Security Rules — but rules act as a defense-in-depth layer for any future Client SDK addition.
Least-privilege IAM scoping
Each Cloud Run service runs under a dedicated service account with only the IAM roles it needs. Scanners cannot delete audit-log entries; the app runtime cannot reach the Cloud Run job control plane.
GCS Object Lock for the audit archive
Every audit row is replicated nightly to a Google Cloud Storage bucket sealed by Bucket Lock for 7 years. Even a project owner cannot delete or modify entries within the retention window.
Sign-in is the gate, not the goal.
- Google OAuth only. No password authentication, no shared accounts. Customer email verification (`email_verified` from Google) is a hard requirement to sign in.
- Per-tenant membership checks on every read and write. The tenant id comes from the URL path; it is then passed to a server-side membership helper before any DB call.
- JWT sessions, max 8h, revocable per user. Member removal, tenant pause, self-service “sign out all sessions”, and admin force-revoke all bump a per-user timestamp that invalidates issued tokens on their next request.
- Step-up reauth for privileged admin actions. Suspending a tenant or impersonating a member requires a fresh Google sign-in plus an HMAC-signed elevation cookie with a 5-minute TTL.
- Platform-admin Google MFA enforcement. Brand Protector platform admins must have 2-Step Verification enabled on their Google account; admins without it are blocked from the admin console (verified against the OIDC
amrclaim at sign-in). - API tokens. Personal tokens (
bp_pk_*) are SHA-256 hashed at rest; plaintext is shown once at mint time. Failed-attempt counters trigger auto-lockout.
An audit log a project owner cannot delete.
Audit log immutability is enforced in layers, not asserted in marketing copy:
- A scoped Firestore Security Rules block denies every operation against the per-tenant audit subcollection from any client-side path.
- A least-privilege scanner service-account role denies audit deletion to the workload that produces audit entries.
- The authoritative archive is a nightly export of every audit row to a separate Google Cloud Storage bucket whose retention policy is sealed by Bucket Lock for 7 years. Even a Brand Protector project owner cannot delete or modify the archive within the retention window.
- The audit log is customer-visible inside the workspace with date-range filtering and CSV export at any time.
Self-serve, in-product.
- Article 15 (right of access). Owners and admins can request a complete workspace data export from settings. The export is generated asynchronously as a single ZIP archive (one JSONL file per subcollection: detections, takedowns, cases, audit log, members, configuration, plus tokens and webhooks as metadata only). A signed download link is emailed and valid for 7 days; the archive is purged from our storage after 30 days.
- Article 17 (right to erasure). Workspace deletion is a tenant-owner action and triggers a 30-day soft-delete followed by irreversible purge of all customer data, evidence files, and credentials. For individual data subjects, audit-row pseudonymization is self-serve on member removal — the audit trail's integrity is preserved, the individual's email is replaced with a stable per-tenant pseudonym.
- Articles 16, 18, 20, 21. Rectification and portability self-serve from the settings UI; restriction and objection requests are handled by privacy@brandprotector.io.
Visibility, alerts, and rate limits.
- Cloud Monitoring uptime checks and alert policies on every public endpoint.
- Rate limiting on every public endpoint, including authentication.
- Per-request correlation IDs surfaced in error responses and customer support.
- Internal admin scanner-health dashboard so issues in third-party scrapers or AI providers are caught before they reach customers.
- Daily encrypted backups with 35-day retention; tenant data restore on request during the 30-day soft-delete window after cancellation.
- A separate non-production staging environment with its own GCP project and dataset.
Who else touches your data.
We give customers at least 30 days' notice of any new sub-processor that processes Customer Data, with an opportunity to object. The full list, with locations, is in the DPA; below is the live snapshot.
| Sub-processor | Purpose | Location |
|---|---|---|
| Google Cloud Platform | Hosting, database, storage, secrets | USA (us-central1) / nam5 |
| Google Identity (OAuth) | Sign-in | USA |
| Stripe | Subscription billing | USA / EU |
| Resend | Transactional email | USA / EU |
| Sentry | Error monitoring | USA / EU |
| OpenAI | AI-platform scanning | USA |
| Anthropic | AI-platform scanning | USA |
| Perplexity | AI-platform scanning | USA |
| Google AI / Gemini | AI-platform scanning | USA |
| xAI | AI-platform scanning | USA |
| SerpAPI | Search-engine scanning | USA |
| Apify | Marketplace scraping (TikTok Shop, Temu, Shein) | EU / USA |
Where we are, and where we're going.
We are not yet SOC 2 certified — engagement underway.
Brand Protector is in the early stages of a SOC 2 Type I engagement; the policies, controls, and evidence collection are being put in place now. If you're evaluating us against a formal attestation requirement, talk to us about timing — we'd rather you have the truth than a marketing badge.
- GDPR Article 28 processor obligations are in our DPA, available on request signed.
- Standard Contractual Clauses (Module 2 controller-to-processor) cover EU-to-US transfers; UK IDTA covers UK transfers.
- CCPA/CPRA — we do not sell or share personal information.
Found a security issue?
If you believe you've found a security vulnerability in Brand Protector, please email security@brandprotector.io with reproduction steps and any supporting evidence. We acknowledge receipt within 2 business days and aim to triage within 5 business days. Please give us a reasonable opportunity to remediate before public disclosure.
We do not currently run a paid bug bounty programme, but we're happy to publicly credit researchers who report issues responsibly.
Need a deeper conversation?
Security questionnaires, custom DPA terms, or specific isolation requirements — we're happy to talk through any of it.