Policies

Overview

Policies define how Checkpoint handles detected AI agents and bots. When a request is classified by the Gateway or Middleware, the policy engine evaluates the detection result and determines the response action.

Policy Evaluation Order

Policies are evaluated in priority order. The first matching rule wins:

1. Allow list     (highest priority)
2. Deny list
3. Path-based rules
4. Confidence threshold
5. Default action  (lowest priority)

Available Actions

The instruct action is the cryptographic-enforcement path. Instead of best-effort detection and a soft redirect, it challenges the agent with a standards-based HTTP 401 and a machine-readable MCP-I flow. This is bypass-proof for agents that cannot forge a valid signature — use it for auth-critical endpoints like payment APIs, data exports, and admin actions. See MCP-I Enforcement for the full flow, deployment requirements, and configuration.

Choosing an Action

Pick the action that matches the threat model of the endpoint. You can mix actions across a project by setting different defaults per path rule.

When to use allow

Let the request through and log the detection to the dashboard. Use this when:

• You want to observe agent traffic before committing to enforcement. Turn on detection, review the dashboard for a few days, and tune your rules before switching to block or redirect.
• The endpoint is public content (marketing pages, blog posts, documentation) and you have no reason to differentiate agent traffic from human traffic.
• You're running Checkpoint in parallel with an existing anti-bot system and want to compare signals without interfering.

Not a good fit for: endpoints that do real work on the customer's behalf (data exports, payments, admin actions). Allowing agents through without any check defeats the purpose of enforcement on those routes.

When to use block

Return a 403 and refuse to serve the page. Use this when:

• The endpoint is strictly not for agents under any circumstances and you want the most aggressive response. Examples: competitor scraping of proprietary content, admin surfaces, endpoints that cost money per request.
• You have a known-bad User-Agent or agent class in your deny list and want to harden against it.
• You're running a short-term block during an incident (e.g. an AI crawler is hammering your origin).

Not a good fit for: the general-purpose default on a content site — you'll accidentally block legitimate AI agents your users are delegating to. Use redirect or instruct for soft-to-cryptographic enforcement instead.

When to use redirect

Return a 302 to a custom URL. Use this when:

• You want a soft enforcement that still tells agents "you can get what you need, just through this other flow." The redirect URL typically points to a consent page, a sign-in flow, a pricing page, or your hosted Bouncer consent.
• You want brand control — instead of sending agents to Checkpoint's default /bouncer/{projectId}/consent, you configure a URL or same-origin path on your own domain (for example, /ai-welcome or https://acme.com/for-ai).
• You want something friendlier than a hard block but don't need cryptographic enforcement.

The redirect field accepts both absolute URLs (https://acme.com/path) and same-origin paths (/ai-welcome). Same-origin paths are resolved against the agent's current origin, which is useful when the same policy covers staging and production domains.

Not a good fit for: sensitive endpoints where an agent absolutely must not get through unless authenticated. A 302 is trivial for a sophisticated agent to ignore — use instruct for cryptographic enforcement instead.

When to use instruct

Return a 401 MCP-I challenge. Use this when:

• The endpoint handles sensitive work — payment processing, data exports, user-authenticated APIs, admin actions. You want cryptographic assurance that only authorized agents get through.
• You specifically want to block agent tool-delegation evasion. Detection-based actions (redirect, block) can be bypassed by agents that proxy through third-party tools (URL inspectors, web search APIs, screenshot services). instruct requires a cryptographic proof on the actual request hitting the gateway, which a proxied request cannot carry.
• Your customers expect your APIs to support modern MCP-I-aware agents (ChatGPT, Claude, KYA-OS agents) out of the box.

This is the bypass-proof path. It requires the Checkpoint Gateway in front of your origin — in-app middlewares fall back to redirect behavior because they cannot process the 401 challenge round-trip. See MCP-I Enforcement for the full flow, configuration, and limitations.

Not a good fit for: general-purpose content protection where most agents are not yet MCP-I-aware. Non-cooperating agents see a 401 with no way to proceed, which may cost you legitimate traffic on public surfaces. Pair instruct with redirect on a path-rule basis — use instruct on /api/payments/* and redirect on / — rather than using instruct as a site-wide default.

Policy Configuration

Via the Dashboard

1. Navigate to Project Settings → Enforce
2. Click Configure Policy on your Gateway or Middleware
3. Set rules using the policy editor
4. Save and apply

JSON Configuration

{
  "default_action": "allow",
  "block_threshold": 80,
  "allow_list": ["Googlebot", "Bingbot", "Yandex"],
  "deny_list": ["malicious-bot", "scraper-ua"],
  "path_rules": [
    {
      "pattern": "/api/*",
      "action": "block"
    },
    {
      "pattern": "/public/*",
      "action": "log"
    },
    {
      "pattern": "/checkout/*",
      "action": "block"
    }
  ]
}

Allow List

The allow list has the highest priority. User agents matching the allow list are always allowed through, regardless of detection results.

Common entries:

Deny List

The deny list blocks specific user agents or identifiers. Deny list entries are checked after the allow list but before other rules.

You can also manage deny list entries from the Deny List tab in the project dashboard, which supports blocking by:

• User agent string
• IP address or CIDR range
• Browser/device fingerprint

Path-Based Rules

Apply different policies to different URL paths. Path rules are evaluated after the allow and deny lists but before the default action.

{
  "pathRules": [
    {
      "pattern": "/api/admin/*",
      "action": "block"
    },
    {
      "pattern": "/api/public/*",
      "action": "log"
    },
    {
      "pattern": "/blog/*",
      "action": "allow"
    }
  ]
}

Rule Fields

Confidence Threshold

The global blockThreshold sets the minimum confidence score required to enforce the default blocking action:

{
  "blockThreshold": 80,
  "defaultAction": "block"
}

With this configuration, only detections with confidence ≥ 80 are blocked. Lower-confidence detections are logged but allowed through.

Choosing a Threshold

Default Action

The defaultAction applies when no other rule matches:

• "allow" — Allow all unmatched traffic (recommended starting point)
• "block" — Block all detected agents above the threshold
• "log" — Log detections without taking action

MCP-I Integration

Policies can integrate with Govern features. Agents that present valid MCP-I proofs can be treated differently:

• Agents with valid delegations can be allow-listed automatically
• Agents without proofs follow standard policy evaluation
• This enables a "known agents welcome, unknown agents blocked" approach

Testing Policies

1. Set your policy to "log" mode initially
2. Monitor detections in the dashboard
3. Review classifications and confidence scores
4. Adjust thresholds and rules based on real traffic
5. Switch to "block" or "redirect" when confident

Next Steps

• Detection in Enforce Mode — Understand detection signals
• Gateway Enforcement — DNS-based policy enforcement
• Middleware Enforcement — Code-based policy enforcement
• Monitoring — Track policy effectiveness