Skip to content
Security overview

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.

Isolation

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.

01

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.

02

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.

03

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.

04

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.

05

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.

Identity & access

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 amr claim 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.
Audit immutability

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.
GDPR & data rights

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.
Operations

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.
Sub-processors

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-processorPurposeLocation
Google Cloud PlatformHosting, database, storage, secretsUSA (us-central1) / nam5
Google Identity (OAuth)Sign-inUSA
StripeSubscription billingUSA / EU
ResendTransactional emailUSA / EU
SentryError monitoringUSA / EU
OpenAIAI-platform scanningUSA
AnthropicAI-platform scanningUSA
PerplexityAI-platform scanningUSA
Google AI / GeminiAI-platform scanningUSA
xAIAI-platform scanningUSA
SerpAPISearch-engine scanningUSA
ApifyMarketplace scraping (TikTok Shop, Temu, Shein)EU / USA
Compliance

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.
Vulnerability disclosure

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.