Trust & security
Security at ROAS Shield
We protect your paid-ad data and Meta access tokens with strong encryption, strict per-workspace isolation, and least-privilege Meta permissions. This page describes only what is true in the product today — not a roadmap.
Token protection
Your Meta access tokens are encrypted at rest with an AES-GCM envelope carrying a versioned key header, the master key lives only in a DigitalOcean SECRET environment variable, and token values are never logged.
Tokens never reach the browser. Branded token types make user, Page, and Instagram tokens distinct so a token of one kind cannot be assigned where another is expected — a misuse is caught at compile time, not in production.
Tenant isolation
No — every workspace is isolated by a workspaceId carried on every job, enforced by PostgreSQL row-level security and a tenant-scoped database client, so cross-workspace reads and writes are blocked.
Every job and every query is scoped to a single workspace. PostgreSQL row-level security plus a tenant-scoped Prisma client mean a request can only ever see the data of the workspace it belongs to — there is no shared, unscoped read path for tenant data.
Safe-by-default moderation
Auto-delete is schema-blocked. A delete action is rejected unless a rule carries an explicit per-rule opt-in at a high confidence threshold, and only an Owner or Admin can enable it — otherwise a delete is demoted to a hide.
Buyer-intent comments are never auto-deleted, and AI replies are draft-only by default. Auto-send only happens when a workspace explicitly enables it for a rule that clears our confidence and risk checks.
Webhook integrity
Every Meta webhook signature is verified on the raw request body with a constant-time comparison using your Meta App Secret, before any parsing happens.
Each event passes through three independent dedup layers — a Redis SET NX EX lock, a Postgres UNIQUE(event_hash) constraint, and a BullMQ job id — and the endpoint acknowledges in under 500ms so Meta never has to retry.
Least-privilege Meta access
We request only the Meta permissions needed for ad-comment moderation, and we read ad metadata only — we never use ads_management and never create, edit, or budget your campaigns.
All Meta requests are pinned to Meta Graph API v24.0.
Your data & GDPR
You can request deletion of your data at any time, and we honor it through a dedicated data-deletion path.
- Request data deletion — how to delete your data and what we remove.
- Privacy Policy — what we collect and why.
- Data Processing Agreement — our processor commitments.
Frequently asked
- Are my Meta tokens encrypted?
- Your Meta access tokens are encrypted at rest with an AES-GCM envelope carrying a versioned key header, the master key lives only in a DigitalOcean SECRET environment variable, and token values are never logged.
- Can my data leak to another workspace?
- No — every workspace is isolated by a workspaceId carried on every job, enforced by PostgreSQL row-level security and a tenant-scoped database client, so cross-workspace reads and writes are blocked.
- Do my access tokens ever reach the browser?
- No — tokens never reach the browser; every read and write is authorized against your workspace on the server, and branded token types prevent cross-type misuse at compile time.