Skip to content
camada
Menu
How it worksFrameworksPricingSecurityDocs
Sign inGet started

In-app SDKs for Node, Next.js, Hono, Python, Go, PHP, Ruby, Java and .NET

An AI watchkeeper that keeps bad actors out of your app.

Watchkeeper is camada's AI analyst. Every few minutes it reviews your traffic and catches attackers, and AI agents that act like them. Your app blocks them before your code runs. Customers and verified search crawlers get through. One package and one middleware on most stacks. If camada goes down, your app keeps serving.

Get started freeSee how it works ↓

Free needs no card. A 14-day trial of Starter or Growth needs a card. Nothing is charged today. Cancel before the trial ends (the date is shown in the app) and you pay nothing. Otherwise the plan's monthly price starts on day 15. The analyst runs every few minutes while your project has traffic.

Illustration: Watchkeeper, camada's AI analyst, looks back over requests your app already served and picks clients to block or challenge. Once enforcement is on, your app refuses a blocked client's next request and shows a challenged client a challenge page. Customers and verified crawlers like Googlebot get through.

Illustration. Watchkeeper reviews requests your app already served, every few minutes. Your app enforces what it finds.

The problem

Bots aren't the problem. Bad actors are.

For product teams with logins, signups or a checkout to protect, and no security team. Half the web is bots, and plenty of them are fine. The danger is the ones sent to attack you.

Gets in

  • Your customers
  • Search engines like Googlebot. Fakes pretending to be Googlebot get caught.
  • Bots you trust, on your allow-list

Gets blocked

  • Attackers using AI to find holes and break in
  • AI agents and scripts that act like attackers
  • Credential stuffers testing stolen passwords
  • Scrapers copying your prices and content

Why now

53%

of web traffic in 2025 came from bots, not people.

Thales Imperva, 2026 Bad Bot Report, 2026

12.5×

more AI-driven bot attacks than a year earlier: 2M a day became 25M.

Thales Imperva, 2026 Bad Bot Report, 2026

80–90%

of a state-backed intrusion campaign was run by an AI agent, with humans stepping in at a handful of decisions.

Anthropic, Disrupting AI-orchestrated espionage, 2025

−7 days

mean time to exploit: attacks now start before the patch ships.

Mandiant, M-Trends 2026, 2026

How camada handles each: credential stuffing, scraping, AI agent abuse and CVE exploit scans.

camada can't patch your code or stop a one-off exploit request. It finds clients that scan, probe and keep coming back, and once enforcement is on, keeps them out from its next run.

Attackers now have AI

People use AI models to scan your app, write exploits and try stolen passwords faster than any human team could.

Some AI agents act like attackers

Automated agents scrape what they should not, abuse signups and hammer logins. camada judges them by what they do, whoever sent them.

Both look like customers

Real browsers, home IP addresses, valid requests. One request at a time they look normal, so rate limits miss them. camada looks at the whole session.

The AI analyst

Meet Watchkeeper, your AI analyst

Every few minutes it reads what your app saw and investigates the clients that look wrong. Each verdict says why, with the requests behind it.

Example verdict · IP · 203.0.113.x

Scanner

Malicious · 96% confidence

Blocked for 12 hours

This address walked a list of well-known admin and config paths in a few seconds. Nearly every request ended in a 404, which is how a probe looks and not how a visitor does.

  • 212 requests in 40 seconds across 187 distinct paths
  • Hit /wp-login.php, /.env, /.git/config and /phpmyadmin in sequence
  • 94% of responses were 404 or 403
  • No cookies kept and no static assets fetched

In the app, you can lift this block or change how long it lasts.

Example verdict · Session · ses_7f3a9c1e04b2

Credential stuffing

Malicious · 91% confidence

Blocked for 6 hours

This session submitted login attempts for many different accounts with one password pattern. The failure rate and pacing match a stolen-credential list being replayed.

  • 38 login attempts for 36 different usernames in 3 minutes
  • 97% of attempts returned an invalid credentials response
  • Requests spaced at near-identical intervals of about 4.7 seconds
  • Login form posted with no prior page view of the form

In the app, you can lift this block or change how long it lasts.

Example verdict · IP · 198.51.100.x

Injection

Malicious · 88% confidence

Blocked for 3 days

Query parameters on several endpoints carried SQL fragments and encoded script tags. The same payload shapes were tried against each parameter in turn.

  • Parameter values containing ' OR 1=1 -- and UNION SELECT
  • Encoded <script> payloads in the query string of the search page
  • Same 9 payloads cycled across 14 endpoints
  • Server returned 500 on 6 of the requests

In the app, you can lift this block or change how long it lasts.

Example verdict · TLS fingerprint · tlsx_b81d52ce9a07

Scraping

Suspicious · 72% confidence

Challenge recommended for 4 hours

This client fetched product pages in catalog order at a steady pace from many addresses that share one TLS fingerprint. The pattern fits bulk collection, though the volume is below what would justify a block.

  • Same TLS fingerprint seen from 23 different addresses in one run window
  • Product pages requested in ascending ID order
  • No images, scripts or stylesheets loaded
  • Pace held within a narrow band of 1.2 to 1.5 seconds per page

In the app, you choose what this category does: block, challenge, alert or ignore.

Example verdict · Session · ses_c20e6d8f19a5

Automation

Suspicious · 64% confidence

Challenge recommended for 2 hours

This session completed a sign-up form faster than a person could type it. The interaction timing was uniform from the first field to the submit.

  • Form submitted 1.1 seconds after page load
  • No key presses or pointer moves recorded before submit
  • Browser reported properties typical of a headless client

In the app, you choose what this category does: block, challenge, alert or ignore.

Example verdict · IP · 66.249.66.x

Cleared

Benign · 97% confidence

Allowed

This address belongs to a verified search crawler and is reading public pages at a normal rate. Nothing in its behaviour calls for action.

  • IP matches Google's published crawler ranges
  • User agent claims Googlebot and the address backs it up
  • No logins, signups or form posts
  • Request rate stayed under 2 per second

In the app, you can still block this address by hand.

Examples written for this page in the format the app uses. Not live traffic or customer data. Confidence is the model's own estimate.

How a verdict gets made

  1. 1

    Rules

    63 rules score each client three ways: by IP, by session and by TLS fingerprint. 6 of them look for signs of a real person and lower the score.

  2. 2

    Triage model AI

    Reviews the suspects 15 at a time and picks the ones worth a closer look.

  3. 3

    Investigation agent AI

    Pulls raw request samples and the facts you recorded about your site, then writes a verdict with evidence. When one of your facts explains the traffic, it quotes it.

  4. 4

    Verdict

    Malicious, suspicious or benign, with a confidence, an action and how long it lasts.

  5. 5

    Your blocklist

    Your app pulls it every 30 seconds and checks each request against it in memory.

Stages 2 and 3 are the AI. Today triage runs on Llama 3.3 70B and the investigation agent on DeepSeek V4 Flash, both open-weight models on Cloudflare Workers AI.

The 63 rules only pick suspects. The models decide what each one is, how sure they are and what they recommend.

Fake Googlebots get caught against Google's published IP ranges. The real one gets through.

The AI is not on your request path.

Your app never waits for a model. The analyst works on events after your app has answered them, and the SDK checks each request against a blocklist it already holds. A model can't add latency to a request or change its answer mid-flight. Enforcement is a plain blocklist, and you can see each entry and its reason in the app.

Guardrails

Two come straight from its instructions.

  • Never block on a user agent alone. (from its instructions)
  • Prefer challenge over block when unsure. (from its instructions)
  • A block needs a malicious verdict at 80% confidence or more, by default.
  • Each new project starts in a learning window that only recommends. A person on your team turns enforcement on.
  • If the model answers with junk, camada marks the client suspicious with a placeholder confidence. That can never block it, and at most it gets a challenge. If a model call fails, the run stops and writes no verdicts.

The prompts have a small test set: 15 hand-labelled and prompt-injection cases, run on Workers AI. A case labelled as a real person that comes back blocked scores zero. It catches prompt mistakes. It is too small to prove how well the detection works.

You're in control

  • Learning window. See what it would block, and why, before it blocks anything.
  • Allow-list. Clients on your allow-list stay off the blocklist.
  • Overrides. Unblock or extend any block, turn rules off, and choose what each category does: block, challenge, alert or ignore.
  • Audit log. On Enterprise, admins can see who changed blocks, the allow-list, rules and facts.

Spikes reach you by email, Slack or signed webhook, depending on your plan. On Growth and Enterprise you can ask the chat agent why a client was blocked.

Why its verdicts hold up

It knows which account.

With track(), camada sees which account a failed login, signup or declined payment was for, as a hash, and what happened. A service in front of your app sees the request and the response, but learns your app's outcome only if you send it separately. track() is one extra call in your code for each outcome you report.

It learns from other customers, privately.

An address flagged by 3 or more other paying organizations scores higher for you. camada never shows you who flagged it.

It keeps the evidence.

Each verdict is stored with its summary, evidence and the run report, so you can check its work later.

Forrester renamed this market in October 2025, from bot management to bot and agent trust management. camada works on the bad-actor side: finding them and keeping them out. camada does not check signatures from AI agents today, so it can't vouch for the agents you want to let in. It judges agents by what they do, and your allow-list lets in the ones you trust.

Why camada

Your edge sees packets. Your app sees customers.

camada runs inside your backend, where a scripted signup and a real one look different.

Runs in your process

The blocklist lives inside your backend and refreshes every 30 seconds. Nothing waits on camada while a request is served.

Fails open

Every SDK call sits in a try/catch. An outage or a bug in camada never returns a 5xx from your app.

Shows its work

The analyst writes a verdict for each client it flags, with the requests behind it, so you can read why it acted.

Open source SDKs

MIT licensed and public on GitHub, linked below. Read the redaction code yourself.

Source on GitHub: Node · Next.js · Hono · SvelteKit · Python · Go · PHP · Ruby · Java · .NET. PHP, Java and .NET install from GitHub until they are on Packagist, Maven Central and NuGet.

How camada compares

Setup

camada
A package in your app. Your CDN stays as it is.
Edge bot management
Route your traffic through it, usually with a DNS or CDN change
In-app rule libraries
A package in your app

Where it runs

camada
Enforcement inside your app. The analysis runs in a separate Cloudflare Worker.
Edge bot management
In front of your app, usually at the CDN
In-app rule libraries
Inside your app

When it decides

camada
Every few minutes, over whole sessions, IPs and TLS fingerprints. Each request only checks a blocklist your app already holds.
Edge bot management
On each request, as it arrives
In-app rule libraries
On each request, as it arrives

Account outcomes

camada
Your track() outcomes, through the same package that enforces, tied to a hashed account id
Edge bot management
Sent separately, if the product supports it
In-app rule libraries
What your code passes in on each request

camada runs inside your app, so you can keep your CDN in front of it. Side by side with named products: camada vs Cloudflare Bot Management · camada vs Arcjet.

Judging after the fact has a cost. A new client's first requests reach your app until a run flags it and your app pulls the new blocklist, unless a path entry or one of your rules already covers it.

Leaves your app

  • Method, path and query shape
  • Status, latency, header names and order
  • Client IP, session id, browser beacon fields
  • A hash of the user id you pass to track()

Never leaves your app

  • Authorization and Cookie values
  • Request and response bodies
  • Tokens, keys and passwords in query strings
  • Raw user ids and emails

The full list, and how redaction works →

How it works

Install, watch, enforce.

  1. 1

    Install

    Add the package and its middleware, then set one env var. Events ship in the background, off the request path.

  2. 2

    Watch

    A learning window runs in recommend-only mode. You see what camada would block and why.

  3. 3

    Enforce

    You turn it on. Matching requests get a 403 before your handler runs.

Express · @camada/node
npm i @camada/node

import camada from '@camada/node';
app.use(camada.express());
Next.js · @camada/next
npm i @camada/next

// middleware.ts (Next ≤15) or proxy.ts (Next 16) at the project root
import { camada } from '@camada/next';
export default camada();
export const config = { matcher: ['/((?!_next/|favicon.ico).*)'] };

// app/api/camada/[...camada]/route.ts
import { camadaRoute } from '@camada/next';
export const { GET, POST } = camadaRoute();

// app/layout.tsx, inside <head>
import { CamadaBeacon } from '@camada/next';
<CamadaBeacon />
Get started freeAll 14 frameworks →The full pipeline →

What changes

Same app. Fewer fake users.

Without camada

  • Scrapers copy your prices and content.
  • Credential stuffers test leaked passwords on your login.
  • Fake signups burn trial credits and skew your metrics.
  • AI crawlers run up your compute bill.

With camada

  • Signups and logins come from real customers.
  • Every block shows up in the app with its reason.
  • Your code never sees the attackers camada blocks.
  • You hear about an attack from an alert, not a customer.

What camada does not do

Outage or bug: your app keeps serving

CAMADA_DISABLED=1 is a per-request kill switch.

Cold start passes traffic

A fresh serverless instance lets its first request through while the blocklist loads.

In-app blocks: IP, path and your own rules

Your custom rules can also match user agent and headers. ASN, country and TLS-fingerprint entries fail open inside your app, except on Cloudflare Workers with @camada/hono, or with @camada/sveltekit on adapter-cloudflare.

You decide when to enforce

camada never switches a project to enforce on its own.

Get started

See what's hitting your app today.

The free plan shows you everything camada sees. Paid plans turn on blocking and add Slack alerts. Growth and Enterprise add webhooks.

Get started freeSee pricing →