Beyond Bot Detection: Intent-Based Security for AI Traffic

Why is the human-or-bot test breaking down?

Logs, WAFs, and traditional bot-management tools were designed for a web dominated by humans and relatively simple automation. They can tell you that a request arrived. They often cannot tell you whether the actor behind it is a legitimate customer, a trusted AI agent acting on that customer's behalf, an undeclared or compromised agent, or malicious automation operating with stolen or hijacked intent.

That gap is widening. Much of today's AI-driven traffic is undeclared and arrives without reliable identification. At the same time, Model Context Protocol (MCP) servers are emerging as a new interaction surface that browser- and network-layer tools may not see in full journey context.

Authentication helps establish identity. Intent helps explain behavior. Closing the gap means continuously evaluating behavioral signals, device intelligence, network context, and journey activity — making it possible to distinguish trusted activity from compromised or malicious behavior, not simply identify that an agent or automated system is present.

What can security teams see from the edge?

A single deployment at the CDN edge — with no changes to application code and no additional infrastructure to operate — closes the visibility gap in six ways:

• Every step in one view. Continuous journey visibility across web, mobile, API, and agentic traffic, starting from the first pre-authentication interaction rather than only at login or checkout.
• Activity assessed by intent. Declared and undeclared agents evaluated by what they're doing, how they're behaving, and the journey context — not a simple bot-or-human verdict.
• Visibility into MCP traffic. MCP activity brought into the wider customer journey, rather than assessed in isolation by point-in-time API or browser tools.
• Threats stopped before the application. Account takeover, credential stuffing, automated abuse, and suspicious API activity surfaced at the perimeter, reducing malicious traffic reaching origin infrastructure.
• Signals logs don't capture. Device, behavioral, identity, and network context that server-side logging alone may not provide.
• A replayable decision trail. The evidence behind each risk decision preserved and streamed to your SIEM to support investigations, audit, and incident response.

One deployment, three teams

The same edge deployment serves three constituencies that historically bought separate tools. Security and CISO teams see more: edge and API visibility beyond application logs, continuous assessment of human and agentic traffic, business-logic abuse detection, and explainable decision evidence in the SIEM. Fraud and risk teams catch more: continuous signals across UI, API, mobile, and agentic journeys, reduced losses from account takeover, scams, bonus abuse, and mule activity — with rules and models updated without waiting on application release cycles. Platform and DevOps teams operate more efficiently: no new always-on stack to run, scale, and patch; deployment through infrastructure-as-code; and unwanted traffic deflected before it reaches origin.

Because all three draw from the same intelligence layer, security and fraud finally share one view — one deployment and one decision layer for understanding human and agentic risk across the customer journey.

Does edge deployment mean losing control?

The common concerns are addressable by design. You decide which journeys and endpoints are monitored, what information is collected, when profiling and decisioning occur, and how deployment changes are reviewed and released. Sensitive PII is encrypted at the edge before it leaves your environment, with access controlled through customer-managed permissions and keys, and encrypted event data can live in your own AWS S3 environment for data-residency requirements. Profiling JavaScript can be served through your own CDN and domain, reducing third-party supply-chain exposure. Fail-open behavior is deliberate, configurable, and visible, so a supporting-service interruption doesn't become an availability incident. And deployments are versioned and reversible — suspend, roll back, or undeploy through a controlled release process that preserves your existing CDN behavior.

Get the full solution brief

The complete Security & CISO solution brief includes the full capability breakdown for each of the three teams, the security-posture detail — key custody, supply-chain controls, fail-open configuration, logging continuity — the myth-by-myth treatment of CDN deployment concerns, and the compliance program covering SOC 2 Type II, ISO 27001:2022, and PCI DSS obligations.

Download the Darwinium Security & CISO solution brief to see the full picture.

Frequently asked questions

What is intent-based detection?

Intent-based detection evaluates who or what is acting, on whose behalf, and whether the activity introduces risk — using behavioral signals, device intelligence, network context, and journey activity — rather than issuing a binary human-or-bot verdict. It distinguishes a trusted AI agent acting for a real customer from malicious automation that looks identical at the request level.

Why is traditional bot management no longer enough?

Bot management was built to separate humans from automation. Now legitimate AI agents act on behalf of real customers while malicious automation blends into trusted traffic — so blocking all automation blocks customers, and much of today's AI-driven traffic arrives undeclared, without reliable identification.

Does this replace a WAF or bot-management tool?

It closes the gap those tools leave. WAFs and bot managers answer whether a request matches known bad patterns; an intent layer adds continuous behavioral, device, and journey context on top — including MCP and agentic traffic they may not see in journey context.

Will edge deployment slow down web traffic?

Profiling and risk evaluation can be applied only to the pages, endpoints, and interactions you choose to protect — such as account creation, login, password recovery, or payment — with risk processing running alongside the customer journey rather than in front of every request.

Can it be removed if needed?

Yes. Edge deployments are version-controlled and can be suspended, rolled back, or undeployed through a managed release process. Undeployment removes the relevant workers or functions while preserving your existing CDN behavior.