Arcjet brings bot detection into code to protect AI workflows without CAPTCHAs 

Beyond fake user agents

Automated abuse no longer looks like simple scripts and fake user agents. 

Attackers now use real browsers, headless automation frameworks and AI-driven agents that can load pages, store cookies, submit forms, scrape content and trigger expensive application actions. 

Advanced Bot Signals brings browser telemetry into Arcjet’s runtime security model, so developers can evaluate browser behaviour together with application context before allowing sensitive actions such as signup, login, checkout, form submission, or high-cost AI requests.

Developers drill in, directly

Developers apply protections directly where sensitive actions happen. That puts enforcement where the application’s real context lives – user identity, account state, route sensitivity, business logic and downstream cost – rather than relying entirely on network-level signals that cannot see what the action actually means.

This puts enforcement where the application’s real context lives – user identity, account state, business logic, route sensitivity and downstream cost – rather than relying entirely on network-level signals that cannot see what the action actually means.

“Browsers provide signals, but applications provide intent,” said David Mytton, CEO at Arcjet. “A signup form, checkout endpoint, or expensive AI action carries different risk than a marketing page. Advanced Bot Signals gives developers a way to combine browser telemetry with application context, so security decisions happen where the action is actually being taken.”

Advanced Bot Signals is also part of Arcjet’s broader protection model for AI-enabled applications. As agents and browser automation become capable of operating web interfaces like users, teams need controls that evaluate traffic before expensive or sensitive action execute.

Arcjet evaluates those decisions in code, alongside rate limits, email validation, prompt-injection checks, sensitive-data controls and other runtime policies.

Developer abilities: Advanced Bot Signals

Advanced Bot Signals integrates directly into Arcjet’s application-layer security model. Developers define rules in the same codebase as the feature itself, so protection ships with the code and gets reviewed in the same pull request. 

There is no separate system to manage.

With Advanced Bot Signals, software engineering teams can:

• Detect browser automation that executes JavaScript and behaves like a real user.
• Passively collect browser telemetry without interrupting users with CAPTCHAs.
• Enforce protection only where risk exists: signup, login, checkout, invite, form and high-cost AI routes.
• Combine browser signals with application context, rate limits, email validation and other Arcjet rules. 
• Start in dry-run mode, analyse real traffic and promote protections safely.

Advanced Bot Signals works alongside existing capabilities such as prompt injection protection for AI chat endpoints and tool calls and Guards for runtime protection inside agentic application workflows. Together, these controls help developers protect both traditional web endpoints and AI-enabled workflows from automated abuse, data leakage, prompt manipulation and unexpected infrastructure or model costs.

CEO deep dive

The Computer Weekly Developer Network (CWDN) sat down for a deep dive with David Mytton, CEO, Arcjet.

CWDN: Why should every software engineer treat bot protection as a core development concern, not a security team afterthought?

Mytton: Bots don’t attack “security” in the abstract. They attack product features: signup forms, checkout flows, login pages, password resets and now expensive AI actions. A bot is not just bad traffic. It is a product workflow being automated against you. A security team can set policy and provide guardrails, but they rarely have the route-level context needed to make the best decision. Is the user particularly important? Does the action send a message, spend credits, reserve inventory, or trigger an LLM call? Those are engineering and product questions as much as security questions.

CWDN: How does enforcing security policy directly in code change the way developers think about application risk?

Mytton: Instead of thinking “we have bot protection somewhere,” developers can look at the code and see the actual policy: who is allowed, what signals matter, what limit applies and what happens when the request is denied. That changes the development workflow – security becomes part of the implementation, not a box checked later. The same pull request that adds a route can include the rules that protect it. Reviewers can ask normal engineering questions: is this strict enough, is it too strict, does it fail safely, does it explain the decision and does it match the business logic? When security lives in code, it becomes part of engineering judgment rather than an external approval step.

CWDN: AI agents grow more capable of mimicking real users, what should developers be building defensively right now?

Mytton: AI agents make automation more capable, but they do not remove the need for intent, identity and business logic. Developers should assume that automation will increasingly look like a real browser operated by a real user. It may load pages, run JavaScript, store cookies, click buttons, fill forms and follow multi-step flows. The old question was “is this a bot?” The question now is “Is this action acceptable in this context?” 

CWDN: Why is application context – identity, route, business logic – something that network-level security tools fundamentally cannot see?

Mytton: You cannot properly protect a signup, checkout, or AI action if all you know is the IP address and headers. The network can see the request. The application can see the intent. It knows whether the user is authenticated, whether the account is new, whether the action is expensive, whether the email address matters and whether the same behaviour is normal for one API, but suspicious for another.

CWDN: What does it mean in practice for bot protection to ship in the same pull request as the feature itself?

Mytton: It means the protection is not a separate project. If a developer adds a signup form, the PR also includes the rate limit, bot rule, email validation and denial behaviour. If they add an AI endpoint, the PR includes the controls for who can call it, how often and what happens when automation shows up.

That makes security review much more practical. Instead of asking “is this protected somewhere?”, the reviewer can inspect the feature and the protection together. Bot protection should ship with the feature, not arrive later as an incident response.

Advanced Bot Signals is available now through the Arcjet JS and Python SDKs. Existing customers can enable it immediately; new developers can get started with a free account.