Checkpoint Docs
Enforce

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

FeatureGatewayMiddlewareDetect-only
DetectionYesYesYes
Policy enforcementYesYesNo
Code changesNone (DNS only)npm packagenpm package / script tag
Latency~1–5ms (edge)~5–10ms (server)Varies
Custom domainsYesN/AN/A
Response customizationVia policiesFull controlN/A
ChatGPT signature verificationYesYesNo
WASM detectionYes (edge)Yes¹No

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

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:

  • Allow — Let the request through to your origin (the default posture; detection is still recorded).
  • Block — Return a 403 and refuse to serve the request.
  • Redirect — Return a 302 to a full URL (https://example.com) or a same-origin path (/ai-welcome) — typically a consent page or an AI-specific landing page.
  • Challenge — Require consent or step-up approval before proceeding.
  • Require identity (instruct) — Return a 401 with a structured KYA-OS challenge. The agent must present a cryptographic identity (RFC 9421 or a KYA-OS delegation proof) on retry. Bypass-proof for agents that cannot forge a valid signature. Learn more →

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.

Configure 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%.

Learn about detection →

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:

  1. Create a project (or open an existing one).
  2. Choose a mechanism — a Gateway (DNS, no code) or Middleware (code, in your app). You can run both.
  3. Author a policy in Compose — describe the rule in plain language; Checkpoint compiles it to Cedar.
  4. Dry-run the policy against real traffic to preview verdicts.
  5. Authorize & deploy — deploy in observe mode first, then flip to enforce.
  6. Monitor decisions and health from the dashboard.

What Enforce is not. Two nearby surfaces belong to Govern, not Enforce. Protections (the auth/consent tab surfaced under Policy) configures 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. (This unified auth/policy surface is still evolving, so its dashboard placement may change.) 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 Quick Start

  1. In the dashboard, add a Gateway for the domain you want to protect
  2. Add the DNS record shown (CNAME to cname.checkpoint-gateway.ai)
  3. Wait for verification to complete
  4. Author and deploy your policies in Compose

See the Gateway guide for the full step-by-step, including DNS and SSL details.

Middleware Quick Start

npm install @kya-os/checkpoint-nextjs
// middleware.ts (Next.js)
import { withCheckpointApi } from '@kya-os/checkpoint-nextjs/api-middleware';

export default withCheckpointApi({
  apiKey: process.env.CHECKPOINT_API_KEY,
});

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

Health & Monitoring

The Gateway exposes health endpoints for monitoring:

GET /__gateway/health   → Health status
GET /__gateway/ready    → Readiness probe
GET /__gateway/version  → Version and region info

View monitoring details →

Next Steps