Runtime Privacy Signal Enforcement

Enforce GPC at the edge. Fail-closed. Provably compliant.

One-line integration. Real-time decision records. Zero trust gaps.

Get Started Free See How It Works Sign in

origin-check

gpc-signal

dpa-check

enforce

451 · deny

Signal

Sec-GPC: 1 — detected

Proof →

Decision

451 deny in < 5 ms

Proof →

Proof

Audit record per request

Proof →

How It Works

GPCGuard sits in your runtime path and applies a sequential enforcement chain before downstream systems process data. Each stage produces observable output.

INGRESSSignal Detection

Sec-GPC: 1
Origin: shop.example.com
Method: POST /api/checkout

Read GPC signal and full request context at the edge. No downstream system is touched until the chain completes.

INTERCEPTGate Checks

origin-check: pass
dpa-check:    pass
rate-limit:   pass

Guards execute in strict order. A single failure terminates the chain and returns a structured deny — fail-closed by design.

POLICYDecision Lookup

policy_version: v1.0
decision:       deny
reason: gpc_opt_out_honored

Active policy version resolves the enforcement outcome: allow, deny, or gate. Policy version is pinned to every record.

ENFORCERecord & Return

HTTP/1.1 451
X-GPC-Decision: deny
X-Guard: gpc-signal

Response issued. Decision record persisted with full context. Downstream processing never executes.

Chain invariant: every request that reaches your stack has a Decision Record — or was denied before it could.

View a sample record →

Proof-First

Every Decision Has a Record

GPCGuard does not trust internal state — it records it. Below is the anatomy of a real enforcement decision: input, guard chain, policy version, outcome, reason code.

Sample Decision Record

REDACTED

Input

origin: shop.example.com
sec_gpc: 1 (opt-out)
path: /api/checkout

Guard Chain

01 origin-checkPass
Origin Allowlist — Request origin matches registered site allowlist.
02 gpc-signalPass
GPC Signal Detection — Sec-GPC: 1 detected; signal classified as active opt-out.
03 dpa-checkPass
DPA Acceptance Gate — Data Processing Agreement on file and active for this site.
04 rate-limitPass
Abuse Circuit Breaker — Request volume within threshold; circuit closed.

Policy & Outcome

policy_version: policy_v1.0
decision: deny
reason: gpc_opt_out_honored
http_status: 451

View sample payload

{
  "request_id": "req_[REDACTED]",
  "tenant_id":  "tenant_[REDACTED]",
  "ts":         "2026-02-18T14:32:01.042Z",

  "input": {
    "origin":   "shop.example.com",
    "sec_gpc":  "1",
    "method":   "POST",
    "path":     "/api/checkout"
  },

  "guard_chain": [
    { "guard": "origin-check",  "result": "pass", "latency_ms": 1  },
    { "guard": "gpc-signal",    "result": "pass", "latency_ms": 2  },
    { "guard": "dpa-check",     "result": "pass", "latency_ms": 3  },
    { "guard": "rate-limit",    "result": "pass", "latency_ms": 1  }
  ],

  "policy_version": "policy_v1.0",

  "outcome": {
    "decision":   "deny",
    "reason":     "gpc_opt_out_honored",
    "http_status": 451
  }
}

How enforcement works →Inspect sample payload →

Guard Chain Trace

Sequential

Guards execute in order. A failure at any step terminates the chain and returns a structured deny response — fail-closed by design.

origin-checkPass
Origin Allowlist — Request origin matches registered site allowlist.
gpc-signalPass
GPC Signal Detection — Sec-GPC: 1 detected; signal classified as active opt-out.
dpa-checkPass
DPA Acceptance Gate — Data Processing Agreement on file and active for this site.
rate-limitPass
Abuse Circuit Breaker — Request volume within threshold; circuit closed.
outcomedeny
gpc_opt_out_honored — downstream processing blocked before execution

Fail-closed = safe default deny

If any guard check is inconclusive or the system is degraded, the default response is deny. Nothing processes until enforcement confirms it can.

Same record, two lenses:

Engineering

guard name · latency · reason code

Compliance

policy version · opt-out honored · audit trail

Decision-Level Proof

Every enforcement event lands in the Audit Ledger — signal, tenant scope, policy applied, and action taken. Not an event count. A row you can open and read.

Full record schema →

Audit Ledger— enforcement decision stream (sample, redacted)

DENYALLOWGATE

Timestamp	Tenant Scope	Signal	Policy	Action	Reason
2026-02-18T14:32:01Z	tenant_[REDACTED]/shop.example.com	Sec-GPC: 1	policy_v1.0	DENY	gpc_opt_out_honored
2026-02-18T14:31:58Z	tenant_[REDACTED]/shop.example.com	Sec-GPC: 0	policy_v1.0	ALLOW	no_opt_out_signal
2026-02-18T14:31:47Z	tenant_[REDACTED]/api.example.com	Sec-GPC: 1	policy_v1.0	DENY	gpc_opt_out_honored
2026-02-18T14:31:39Z	tenant_[REDACTED]/app.example.com	Sec-GPC: 1	policy_v1.0	GATE	dpa_pending_signature
2026-02-18T14:31:22Z	tenant_[REDACTED]/shop.example.com	Sec-GPC: 1	policy_v1.0	DENY	rate_limit_circuit_open

Tenant Scope is explicit on every row. No cross-tenant data surfaces in any view.

Proof →

Not a Cookie Banner Tool

Consent UI and runtime enforcement solve different problems. GPCGuard focuses on deterministic server-side handling and verifiable policy outcomes.

Regulatory exposure: preference ≠ enforcement

Capturing an opt-out preference without verifiable runtime enforcement leaves covered processing unguarded — and audit trails empty when regulators ask for proof.

See what enforcement proof looks like →

Dimension	Typical CMP Focus	GPCGuard Runtime Focus
Primary surface	Banner and consent preference UX	Ingress request policy enforcement
Decision timing	After user interaction with UI	Before covered processing executes
Coverage	Mostly client-side script behavior	API/runtime decision path and dashboard evidence
Outcome	Preference captured	Preference enforced and observable

Drop-In Enforcement

Route your ingress through GPCGuard's edge function. No SDK to bundle, no client-side script — enforcement happens before your stack touches the request.

Edge middleware

See what gets recorded →TypeScript / Deno

// Forward each request through the GPCGuard enforcement gate
const response = await fetch(
  'https://<project>.supabase.co/functions/v1/gpc-signal',
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${SITE_API_KEY}`,
      'Sec-GPC': request.headers.get('Sec-GPC') ?? '0',
      'Origin':  request.headers.get('Origin')  ?? '',
    },
  }
)

// Gate outcome: 'allow' | 'deny' | 'policy'
const { decision } = await response.json()
if (decision !== 'allow') {
  return new Response(null, { status: 451 })
}

No client SDK

Enforcement lives at the edge — zero bundle impact on your frontend.

Stateless gate

Each request evaluated independently; no session state required.

Structured response

decision, guard, and reason fields for programmatic downstream handling.

Assurance Preview

Infrastructure-grade enforcement is reviewable, not assumed. Below is how GPCGuard substantiates its operational claims — before you sign up.

Scope

Enforcement point, not a CMP

GPCGuard operates at the ingress layer — between the signal and the processing. It is not a consent banner, not a preference store. It is a runtime policy gate with a recorded outcome per request.

Proof

Audit-ready evidence

Every enforcement event produces a structured Decision Record: input context, guard chain result, policy version applied, outcome, and reason code. Records are retained and exportable — not summaries, not counts.

See sample evidence →

Operations

Fail-closed by design

When a guard check is inconclusive, degraded, or the system is under stress, the default response is deny. Nothing processes until enforcement confirms it can. This is what "fail-closed" means operationally — it is a safety property, not an error state.

Assurance

Trust Center preview

Security overview, subprocessor list, and incident contact are in active preparation. This section will link to a public Trust Center when available.

Coming soonRead security overview →

Coverage Signals

GPCGuard supports enforcement workflows under state privacy laws that require GPC signal honoring for covered businesses. Coverage signals indicate which jurisdictions the enforcement pipeline is designed for — they are operational indicators, not legal guarantees.

CaliforniaCCPA / CPRAGPC signal enforcement supported

ColoradoCPAGPC signal enforcement supported

ConnecticutCTDPAGPC signal enforcement supported

New JerseyNJDPAGPC signal enforcement supported

See sample evidence →Read security overview →

Policy. Enforcement. Proof.

Move from “we collect preferences” to “we can show how every request was handled.” GPC enforcement starts in minutes.

Get Started Free Read the Docs Inspect evidence schema →