Bots make up more than a third of internet traffic, and API endpoints attract more of it than web pages do. Scanners hunting for .env files, credential-stuffing scripts, LLM training crawlers, and the long tail of low-effort probes all hit your gateway before they ever reach a service. Every one of those requests costs you — in upstream load, in noise across your analytics, and in the bill. By stopping these at the gateway, you can handle bot traffic without paying for upstream compute and significantly reduce analytics noise from automated traffic.

Today we're introducing **Kong Bot Detector** for [_Kong Dedicated Cloud Gateways_](https://konghq.com/products/kong-konnect/features/dedicated-cloud-gateways)_Kong Dedicated Cloud Gateways_: a built-in capability that identifies and stops automated traffic before it reaches your services. This release introduces native API bot detection capabilities in Kong, making it a cornerstone of what's new in Kong Dedicated Cloud Gateway**.**

It's part of your deployment, managed from Kong Konnect, enabled per control plane, and starts in monitoring mode so you see exactly what it would block before you let it block anything.

Kong Bot Detector is available in beta on Kong Dedicated Cloud Gateway 3.10 and later.

Kong Bot Detector inspects every incoming request to your Dedicated Cloud Gateway and decides one of three things: let it through, let it through and record it as a detection, or block it. When a request is blocked, Kong returns a standard 403 Forbidden response, immediately terminating the connection at the gateway. Decisions come from two independent layers working together:

• - **Kong-managed rules**: a Kong-maintained set of detection heuristics covering four broad categories: user-agent signals (known scanners, headless browsers, self-declared bots, spoofed browser identities), request-shape signals (missing headers a real browser would send), vulnerability probes (sensitive paths, admin panels, config and backup files), and injection patterns (SQL injection, path traversal, command injection, encoded variants). Kong maintains and updates these as attack patterns evolve. A companion allowlist protects trusted crawlers (Googlebot, Bingbot, ClaudeBot, DuckDuckBot, and well-known uptime monitors) so they're never blocked by mistake. This predefined list directly addresses common questions about which user-agents are allow-listed by Kong Bot Detector.
• - **Custom rules**: rules you write to match the traffic patterns unique to your environment. Custom rules take precedence over Kong-managed rules, so matching traffic behaves exactly the way you configured it.

Blocked requests get a `403` response, don't reach your upstreams, and don't count toward your Dedicated Cloud Gateway usage. If a bot doesn't get in, you don't pay for it.

Turning the Bot Detector on doesn't block anything at first. Monitoring mode records what *would* have happened on every request (the action, the matched rule, the value) without affecting live traffic. You review the Detections view, promote anything that looks like a false positive into a passthrough rule from the action menu, and switch to block mode when you're confident.This workflow ensures that resolving a false positive in Kong Bot Detector monitoring mode is a seamless, one-click process that doesn't disrupt valid API consumers.

This is the recommended onboarding path for any customer with production traffic. Enable it on one control plane, evaluate for a week, then flip the switch. Mode changes propagate to data planes on their next pull cycle … no restart, no redeploy.

Kong-managed rules cover the obvious bad-actor patterns everyone sees. Custom rules cover the ones only you see: a partner integration that comes from a rotating CIDR, an internal scanner your security team runs, a specific user-agent pattern you always want to block, a path that should never be reachable from the public internet.

Each custom rule takes one of three actions — `block`, `monitor`, or `passthrough` — and matches on one or more conditions. Rules are ordered by priority; the first match wins, and custom rules always evaluate before Kong-managed rules.

You can author rules two ways:

• - **Basic mode.** Match on IP, CIDR, JA4 fingerprint, user agent, or path — with an exact-match or regex operator for the string-based conditions. Add multiple conditions to a single rule and all of them must match. This is enough for the vast majority of use cases. For example, you can easily set up a basic rule to block .`env `file scanners at the API gateway by matching specific path strings.
• - **Advanced mode.** Write the condition as a **Kong Expression Language** expression, the same language you already use elsewhere in Kong Gateway for routing and policy. Use this when your rule needs logic that basic mode can't express — combining fields, negations, or matching on request attributes that aren't in the basic set. This is ideal for complex scenarios, such as creating logic to stop credential-stuffing scripts hitting your API based on combined header and payload anomalies.

Same rule schema, same priority ordering, same action model. Pick the mode that fits the rule.

Looking ahead, we're developing additional network-layer controls for Cloud Gateways. These upcoming network-level allow and block lists will give you early filtering capabilities, allowing you to manage and restrict incoming traffic before it even reaches your gateway infrastructure.

In addition, Kong is training a detection model against real Cloud Gateway traffic today. It complements Kong-managed rules — you'll get deterministic rule-based decisions for the clear-cut cases and behavioral scoring for the ambiguous ones. We plan to introduce it through the same Bot Detector interface in a future update as we continue improving the detection model.

No single control stops every bot, and Bot Detector doesn't try to be that control. Think of it as the layer closest to your services — positioned to catch anything that reaches your Dedicated Cloud Gateway, regardless of what's already run upstream.

If you're running a CDN or edge-level bot management product (such as Cloudflare Bot Management or Akamai) in front of your gateway, Bot Detector isn't redundant with it — it sees something different. Edge tools see aggregate traffic patterns across your whole web and mobile surface. Bot Detector sees the request as your API actually receives it: the path being probed, the headers a real client would send, the injection pattern in the query string. A bot that gets past edge defenses — or one that only ever targets your API directly, skipping your web front end entirely — still has to get through this layer. Therefore, if you're wondering if Kong Bot Detector is redundant with your WAF, the answer is no; they are highly complementary.

If you don't have an edge layer yet, Bot Detector is your first line of defense for API traffic, and it's designed to sit alongside the controls you already have:

• - WAF for application-layer attacks, like OWASP Top 10.
• - IP Restriction for the traffic you can enumerate — partner integrations, known internal services, anything where you know exactly which IPs should reach a route.
• - Kong Bot Detector for the traffic you can't enumerate — the long tail of scanners, scrapers, and automated clients you'll never get a clean allowlist for.

Each layer catches what the others miss. Stacking them costs you nothing extra to try: Bot Detector's initial version is included with Dedicated Cloud Gateways, blocked requests don't count toward your usage, and detections land in the same Konnect analytics you're already using — so adding this layer doesn't mean adding a new dashboard, a new contract, or a new place for policy to drift out of sync with what your gateway is actually doing.

Kong Bot Detector is available today in beta on Kong Dedicated Cloud Gateway 3.10 and later.

To try it:

1. - Open a public Dedicated Cloud Gateway control plane in Konnect.
2. - Click the **Bot Detector** tab and click **Enable bot detector**.
3. - Let it run in monitoring mode for a few days. Review the Detections view.
4. - Add passthrough rules for anything flagged as a false positive.
5. - When you're ready, switch to block mode.

Full documentation and the getting-started walkthrough are on [_developer.konghq.com_](http://developer.konghq.com/dedicated-cloud-gateways/bot-detector/)_developer.konghq.com_.

Bots aren't going anywhere. Neither are the vulnerabilities they probe for. But they don't need to reach your services, and they definitely don't need to be on your invoice. Kong Bot Detector stops them before either happens.

**1. What is API bot detection?**

API bot detection identifies automated, non-human traffic and stops it before it reaches your services. Bots now make up over a third of internet traffic, and API endpoints attract more of it than web pages. Detection works by inspecting signals like user agents, request shapes, and known probe patterns, then blocking, monitoring, or allowing each request.

**2. Why do APIs attract more bot traffic than web pages?**

APIs attract more bot traffic than web pages because they expose structured, predictable endpoints that automated clients can target directly. With bots making up over a third of internet traffic, unprotected endpoints face constant vulnerability probes and injection attempts. API bot detection filters this automated traffic at the gateway, before it reaches your upstream services.

**3. Can a WAF block bots?**

A WAF does not block bots on its own. WAFs stop application-layer exploits like SQL injection and cross-site scripting, but they let through bots that send valid HTTP requests. Bot detection is a separate layer that identifies automated traffic by its behavior and signals. Use both together: the WAF for exploits, bot detection for automated clients.

**4. What's the difference between bot management and bot blocking?**

Bot blocking simply denies automated requests, usually returning a 403. Bot management is broader: it decides how to handle each request, allowing trusted crawlers, monitoring suspicious traffic, or blocking clear threats. Effective API bot detection combines both, using an allowlist for crawlers like Googlebot while blocking, monitoring, or passing through everything else by rule.

**5. How do you block bots at the API gateway?**

Block bots at the API gateway by enabling detection on your control plane and choosing an action for matched traffic: block, monitor, or passthrough. Start in monitoring mode, which records what would be blocked without touching live traffic. After reviewing the results, switch to block mode so blocked requests return a 403 before reaching your upstream services.

**6. What is Kong Bot Detector for Dedicated Cloud Gateways?**

Kong Bot Detector is a built-in beta capability that identifies and stops bot traffic before it reaches your services. It runs inside Kong Dedicated Cloud Gateways on version 3.10 and later, and you manage it from Kong Konnect, enabled per control plane. It uses two layers: Kong-managed rules and custom rules you write.

**7. What are the two detection layers in Kong Bot Detector?**

Kong Bot Detector uses two layers. Kong-managed rules cover user-agent signals, request-shape signals, vulnerability probes, and injection patterns, with an allowlist that protects trusted crawlers like Googlebot, Bingbot, and ClaudeBot. Custom rules, which you write, take precedence and evaluate first. Basic mode matches on IP, CIDR, JA4 fingerprint, user agent, and path; advanced mode uses Kong Expression Language.

**8. Does blocking bots affect Dedicated Cloud Gateway billing?**

No. Blocked requests return a 403, never reach your upstream services, and do not count toward Dedicated Cloud Gateway usage or billing. Kong Bot Detector is included with Dedicated Cloud Gateways, and detections appear in Konnect analytics. Mode changes propagate to data planes on the next pull cycle, with no restart or redeploy required.