Docs

Security Overview

This page describes how GPCGuard is built to handle data safely and protect customer accounts. It reflects current engineering controls — not certifications or SLA guarantees.

Current Controls

  • Authenticated dashboard operations use the user JWT path with database-level tenant isolation.
  • The public GPC endpoint applies rate-limit, site, origin, active-site, DPA, and circuit-breaker guards before policy decisions are recorded.
  • Decision records use hashed request identifiers and structured outcome fields instead of plaintext user identifiers.
  • Billing, authentication, database, and hosting subprocessors are documented for buyer review.

Current Limitations

  • GPCGuard does not currently claim SOC 2, ISO 27001, PCI certification, or a formal uptime SLA.
  • The product is an API-layer decision endpoint and dashboard, not whole-site network interception.
  • Customers must wire HONORED decisions into their CMP, tag manager, CDP, server-side events, and ad partners.
  • Security and privacy posture can be reviewed during enterprise contracting; independent certifications are not yet published.

Data Handling

GPCGuard processes GPC signals to produce decision outcomes and decision records. It does not collect or store personal data for profiling purposes.

  • Signal processing paths use privacy-preserving hashing for request correlation — raw identifiers are not retained.
  • Signal-processing logs are structured and redacted. Plaintext PII and secrets are not intentionally written to logs.
  • Compliance telemetry is scoped to signal-processing observability: signal source, decision outcome, policy version.

Account and Tenant Isolation

Each customer account is isolated at the database level. One customer cannot access another customer's sites, decision records, or configuration.

  • Dashboard reads and writes run on the authenticated user path; direct table access is scoped by Row Level Security policies.
  • Internal-only evidence and analytics surfaces are exposed only through narrow database functions that derive ownership from auth.uid().
  • In customer-api, service role is used only for Supabase Auth token validation; public runtime, billing webhook, health, and ops functions use server-only service-role clients for narrowly scoped backend operations.
  • Cross-tenant access protections are enforced at the database boundary, not just application logic.

Infrastructure and Subprocessors

GPCGuard uses the following third-party infrastructure providers:

  • Supabase — database, authentication, and edge function hosting.
  • Vercel — dashboard hosting and CDN.

See the public subprocessor table for current categories and customer-data roles.

Vulnerability disclosure

How to report a suspected security issue and what to include.

Incident response

Current triage posture, customer communication approach, and limitations.

Subprocessors

Current infrastructure and billing providers used by GPCGuard.

Retention and export

Data categories, dashboard windows, audit records, and deletion process.

What This Page Does Not Claim

  • GPCGuard is not currently SOC 2, ISO 27001, or otherwise third-party certified.
  • This page does not constitute a formal security agreement or SLA.
  • Incident response procedures are in place but not yet published as a formal runbook.
  • This overview reflects current posture and will be updated as the product matures.

Security Contact

To report a vulnerability or security concern: security@gpcguard.app

For general support or enterprise security questions: support@gpcguard.app