Enforce
Active AI agent enforcement via Gateway (DNS) or Middleware (code)
What is Enforce?
Checkpoint Enforce provides active AI agent enforcement for your web applications. Unlike Detect which passively identifies agents, Enforce detects agents and applies policies — allowing, blocking, redirecting, or challenging traffic based on Cedar policies you author in plain language.
Enforce includes detection by default. When you enable Enforce, you get everything Detect offers plus policy-based actions.
Two Deployment Options
Checkpoint offers two enforcement approaches. Choose one or use both depending on your infrastructure.
Gateway (DNS-Based)
Route traffic through Checkpoint's edge network by updating a DNS record. Zero code changes required.
User Request → DNS (CNAME) → Checkpoint Gateway → Detect + Enforce → Your Origin
↓
Dashboard Analytics- Runs at the Cloudflare edge with WASM-based detection
- ~1–5ms detection latency
- Supports custom domains and SSL
- No application code changes
- Set up Gateway →
Middleware (Code-Based)
Add detection and enforcement directly in your application code using npm packages.
User Request → Your Server → Middleware → Detect + Enforce → Route Handler
↓
Dashboard Analytics- Server-side detection in Next.js or Express
- ~5–10ms detection latency
- Full control over enforcement behavior
- Customizable responses
- Set up Middleware →
Comparison
| Feature | Gateway | Middleware | Observe mode² |
|---|---|---|---|
| Detection | Yes | Yes | Yes |
| Policy enforcement | Yes | Yes | No (recorded only) |
| Code changes | None (DNS only) | npm package | Same as chosen deployment |
| Latency | ~1–5ms (edge) | ~5–10ms (server) | Same as chosen deployment |
| Custom domains | Yes | N/A | Same as chosen deployment |
| Response customization | Via policies | Full control | N/A (nothing is applied) |
| ChatGPT signature verification | Yes | Yes | Yes |
| WASM detection | Yes (edge) | Yes¹ | Yes |
¹ Middleware runs the same WASM engine in-process when you use the local-engine entry point (withCheckpoint). The SaaS entry point (withCheckpointApi) instead POSTs each request to the edge Gateway, so WASM runs at the edge, not in your process. See Middleware.
² Observe mode isn't a third deployment — it's a way of running either one. Detection still runs in full (WASM, signature verification), but no verdict is applied: every request passes through, and the dashboard shows what would have happened. Middleware takes it as the enforcementMode: 'enforce' | 'observe' config option; the Gateway reaches the same behaviour with the log action on a rule. See Enforce vs. observe.
Key Features
Policy Enforcement
Author policies in Compose — describe a rule in plain language, Checkpoint compiles it to Cedar, and you dry-run and deploy it. Each rule assigns a verdict to matching agent traffic; see Verdicts for the full list, what each one does, and the HTTP response it produces on each enforcement surface.
Deploy a policy in observe mode to record what it would do without affecting traffic, then flip to enforce once the verdicts look right. See Policies.
ChatGPT Signature Verification
Checkpoint verifies Ed25519 HTTP Message Signatures (RFC 9421) from ChatGPT and other agents that cryptographically identify themselves. When a valid signature is present, detection confidence is 100%.
Detection Classes & Confidence
Every request is classified as human, ai_agent, bot, or incomplete_data, with a confidence score from 0–100. Enforce reuses the Detect engine, so Detect is the canonical reference for what those classes mean and how confidence is scored. In Enforce, the classification and confidence flow into your Cedar policy, which decides the verdict.
The enforcement journey
Whichever mechanism you choose, the dashboard flow is the same shape:
- Create a project (or open an existing one).
- Choose a mechanism — a Gateway (DNS, no code) or Middleware (code, in your app). You can run both.
- Author a policy in Compose — describe the rule in plain language; Checkpoint compiles it to Cedar.
- Dry-run the policy against real traffic to preview verdicts.
- Authorize & deploy — deploy in observe mode first, then flip to enforce.
- Monitor decisions and health from the dashboard.
What Enforce is not. Two nearby surfaces belong to Govern, not Enforce.
Sign-in methods (configured under Policy → Auth) sets up the identity layer — auth
methods, providers, and per-tool consent — writing Bouncer configuration that produces the facts
your Cedar policy evaluates (e.g. principal.delegation == "verified"), rather than being an
Enforce policy itself; see Govern: Consent. Separately, the org-level
MCP Gateway (the "agentic hub" / Connections) — which upstream MCP servers and tools your org
exposes — is a Govern concept, distinct from the DNS Gateway on this page.
Quick Start
For the fastest setup with no code changes, use the Gateway. For full control within your application, use Middleware.
Gateway
Add a Gateway for your domain in the dashboard, point a DNS record at it, and author your first policy in Compose. No application code changes required.
Middleware
Install the SDK for your framework (Next.js or Express) and wrap your app with it. You'll need your project's API key — find it under Credentials.
Health & Monitoring
Both deployments expose health signals and feed the dashboard's detection views. See Monitoring for Gateway health endpoints, status states, and what's available for Middleware.
Next Steps
- Gateway Enforcement — DNS-based setup with zero code changes
- Middleware Enforcement — Next.js and Express integration
- Policies — Configure enforcement rules
- Detection in Enforce Mode — How detection works at the edge
- Monitoring — Health checks and performance metrics