Skip to main content
AI AGENT DETECTION

AI agent detection for websites, with the evidence behind every result

See which interactions on your website come from people, people working with AI, autonomous agents, or sources the evidence cannot yet identify. Every result shows what it is based on.

Get Early AccessExplore How It Works
Toshendra Sharma

By Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

Your website now has more than one kind of visitor

For most of the web's history, a website could assume a simple model: a person opens a browser, clicks around, and maybe signs in. Analytics, rate limits, onboarding flows and security checks were all designed around that person.

That model no longer describes real traffic. Today a single website serves people browsing on their own, people who ask an AI assistant to summarize or fill something in for them, autonomous agents that read pages and call endpoints on behalf of someone else, and a long tail of crawlers and scripts. AI providers document several of these visitors themselves: OpenAI, for example, publishes separate user agents for its search crawler, its training crawler and the fetcher that visits pages when a ChatGPT user asks a question (OpenAI crawler documentation), and Anthropic does the same for ClaudeBot, Claude-User and Claude-SearchBot (Anthropic crawler documentation). Some of these visitors are welcome. Some need a different experience. Some need a closer look before they can do anything sensitive.

The challenge is that most of these interactions look similar at first glance. A login tells you which account is in use. It does not tell you whether a person is clicking, whether an assistant is acting through that session, or whether an automated client is reading your pricing page for a user somewhere else. AI agent detection for websites is about closing that gap with evidence, so your team can respond to each kind of actor appropriately instead of treating all traffic the same way. For a practical walkthrough of the signals involved, read how to tell if website traffic comes from AI agents, and see the websites use case for how this looks on a production site.

Why a single bot score is not enough

Many tools answer this question with one number: a bot score, a risk score, a percentage that claims to describe how human a visitor is. The appeal is obvious. One number is easy to put into a rule.

The problem is that a single number hides the reasoning. When a score says a session is probably automated, your team cannot see whether that conclusion rests on a verified signature, a user-agent string that anyone can copy, or a pattern that also matches a fast human typist. When that score drives a block or a challenge, you inherit every mistake it makes without any way to explain it to a customer, a colleague or an auditor.

Proof of Actor takes a different approach. Every result is one of four clear classes, explained in Human, AI-assisted or agent: a taxonomy for app traffic, and every result says what it is based on. You see the conclusion and the evidence together, which means you can trust strong results, question weak ones, and build policies that match the quality of the evidence.

How to detect AI agents on your website in four steps

You can start detecting AI agents on your website with tools you already have. These four steps are vendor-neutral and work whether or not you use Proof of Actor; the blog post on how to tell if website traffic comes from AI agents covers each one in more depth.

  1. List the agents that announce themselves. Search your server or CDN logs for the user agents that AI providers publish. OpenAI documents OAI-SearchBot, GPTBot and ChatGPT-User, and states that ChatGPT-User visits pages when a user asks ChatGPT a question rather than crawling automatically. Anthropic documents ClaudeBot, Claude-User and Claude-SearchBot. This gives you a first, declared picture of agent traffic by route.
  2. Verify the claims instead of trusting the string. A user agent is self-reported and easy to copy. Check it against the operator's own verification method: Google describes a reverse DNS lookup followed by a forward DNS lookup, plus published IP range files, for Googlebot (Google: verifying Googlebot); Bing describes the same reverse and forward DNS check for Bingbot (Bing: verifying Bingbot); OpenAI publishes IP range files for each of its user agents. Where a client signs its requests with HTTP Message Signatures, defined in RFC 9421, check the signature against the operator's published key.
  3. Label every result with its evidence, and keep Unknown. Record whether each conclusion is verified, declared or inferred. Traffic that matches no verified or declared agent and shows no clear human pattern should be labeled Unknown, not forced into human or bot. This is the step that separates a useful report from a guess.
  4. Observe by route before you act. Break the results down by route and workflow for a few weeks: public content, signup, account settings, APIs. Only then write a narrow policy for the route where actor context matters most, with an explicit fallback for Unknown.

Proof of Actor automates these steps inside your application: it gathers the signals your integration can see, returns a class with its basis, tracks Unknown by route, and leaves the policy to your code.

How Proof of Actor detects AI agents on websites

Proof of Actor is built around a simple path: the signals your integration can observe, a classification with an explicit basis, and a decision that stays in your hands. You can read the full flow on the How It Works page. Here is the short version.

Signals from your integration

Each integration sees what its context allows. A server-side integration sees request context, protocol details and, when a client supports it, a request signature. A browser integration sees interaction signals on the pages where it runs. An application can also record its own declarations, such as a user marking content as drafted with AI assistance, or an agent client naming itself.

Proof of Actor works with the evidence that is actually present. It does not pretend to see things your website cannot observe.

Four classes that mean something specific

Every interaction lands in one of four classes:

  • Human: the observable signals indicate human-directed interaction.
  • Human + AI: AI assistance was declared, or observed through a supported integration that can see it.
  • Agent: automated or agent-origin interaction, supported by verifiable identity or a carefully qualified inference.
  • Unknown: the available evidence does not support a reliable determination.

Each class comes with a clear definition and a clear limit. A Human result is not a verified identity. An Agent result is not a statement that the agent is authorized. An Unknown result is not an accusation. You can read the complete taxonomy on the Detection & Limitations page.

A basis on every result

Alongside the class, every result carries its basis: verified, declared, inferred or unknown. A request that carries a valid signature from a published key is verified for that check. A client that names itself as an agent has declared it. A pattern of behavior consistent with automation is an inference. This distinction is what lets your policies be precise. A verified signed agent on a read-only route and a self-declared client on an account settings page should not be handled the same way, and with Proof of Actor they do not have to be. The evidence basis glossary entry explains each one in more detail.

What your team gets: Detect, Understand, Route

Proof of Actor is one product with three capabilities that work together.

Detect

Gather the actor signals available to your integration and separate verified assertions from behavioral inferences. Unknown traffic stays visible as its own category instead of being folded into a guess. You always know which interactions you can speak about with confidence and which ones need more evidence.

Understand

See your AI agent traffic in context. Explore interaction types by route and by time, follow trends in human, AI-assisted, agent and unknown activity, and open any classification to see what is known, what is not known, and what the result rests on. This is where product, platform and security teams get a shared, explainable picture of who is using the website.

Route

Use your own policies to allow, adapt, challenge, review or limit specific interactions. Serve a structured response to a verified agent reading your documentation. Keep the standard experience for human-directed sessions. Ask for a stronger check on a sensitive account change when your own conditions call for it. Choose an explicit fallback for Unknown results and for timeouts, route by route. Enforcement always happens in your application, under policies your team confirms.

Designed to fit into your website, not replace it

Proof of Actor sits alongside the tools you already run. It does not replace your authentication, your authorization model or your existing abuse controls. It adds actor context to them.

A typical website integration starts on the routes where actor context matters most: public content that agents read heavily, signup and onboarding flows, account settings and other sensitive actions, and any API that powers the site. Founding teams work with our engineers to choose those routes, agree the signals in scope, and confirm how data is handled before any code ships.

Because the decision layer lives in your code, you stay in control of the experience. You can show results in an internal dashboard for weeks before any rule changes, then turn on one narrow policy for one route, then expand once the results have earned your trust. The guide on handling unknown traffic walks through how to design those first rules.

Start in observation mode

The fastest way to get value from AI agent detection is to start by watching, not blocking. In observation mode, Proof of Actor records results while your website responds exactly as it would without it. Your team can then compare classifications against outcomes you already understand: support tickets, known integrations, internal tools, and the crawlers you already recognize.

This gives you three things before any enforcement:

  1. A baseline. How much of your traffic is human-directed, AI-assisted, agent-driven or unknown, by route.
  2. Confidence in the evidence. Which signals are strong on your website and where coverage needs to grow.
  3. Better policies. Rules designed around real patterns instead of assumptions, with false positives reviewed before anyone is affected.

When a policy is ready, you enable it for the specific workflow it was designed for, and you keep the ability to adjust it at any time.

Why evidence-backed detection wins over opaque scores

Websites already serve agents, assistants and people working with AI side by side. The teams that handle this well will not be the ones with the most aggressive filters. They will be the ones who can explain their decisions.

Evidence-backed results give you that explanation. When a support agent asks why a user saw an extra verification step, you can point to the evidence and the policy that applied. When an agent operator asks why its signed requests were served a structured response, you can show the verified basis. When the evidence is thin, the result says Unknown, and your fallback handles it in a way you chose deliberately.

This approach also scales with the web. As more agent operators sign their requests and standards work such as the IETF Web Bot Auth working group, which is chartered to standardize cryptographic authentication for automated clients, builds on HTTP message signatures, more of your traffic moves from inferred or unknown to verified, and your policies become more precise without being rewritten.

Join the founding developer program

Proof of Actor is in private beta with a small group of application teams. Selected founding developers can receive up to 12 months of free access, within agreed usage limits, in exchange for hands-on product feedback. You get direct integration support from our engineers, early access to capabilities as they become available, and real influence over what we build next.

If your website serves people, AI-assisted users and agents, and you want to know who is using it before you decide what happens next, apply for early access. Tell us about your website and the interaction you most want to understand, and we will review whether it is a fit for the current beta.

Want to see the details first? Explore Proof of Actor, read how it works, or review exactly what the evidence can and cannot establish.

Sources

FOR DEVELOPERS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent or Unknown.
basis
How strong the evidence is: verified, declared, inferred or unknown.
evidence
The signals behind the result, so your team can see why.

Start in observation mode: record results next to your logs and change nothing until you choose a policy. Read the Node.js integration guide

Frequently asked questions

How does AI agent detection for websites work with Proof of Actor?

Proof of Actor collects the signals available through your integration, such as request signatures, client declarations and interaction signals, and returns a classification with its basis: verified, declared, inferred or unknown.

Will installing it block any visitors?

No. Proof of Actor starts in observation mode. Your website behaves exactly as before while your team reviews results, and you decide later whether any policy should apply.

Can it tell when someone used AI in another tab?

No website can see activity in another tab or on another device. Proof of Actor reports AI assistance when it is declared or observable through a supported integration, and keeps everything else honest by design.

What happens when the evidence is not clear?

The result is Unknown. Unknown is a first-class result, never treated as human by default and never treated as malicious by default. Your policy decides how each route handles it.

Who is Proof of Actor built for?

Teams that operate SaaS applications, websites, APIs and MCP servers and want to understand who or what is acting before choosing an experience or access policy.

How do I get access?

Proof of Actor is in private beta. Apply for early access. Selected founding developer teams can receive up to 12 months of free access within agreed usage limits.

Know who's using your app.

Private beta for a small group of founding developers.

Get Early AccessView pricing

Prefer to talk first? Talk to the founders