Skip to main content
HUMAN VS AGENT TRAFFIC

Tell human, AI-assisted and agent traffic apart

Give every interaction a clear class and a clear basis, so your application can serve people, people working with AI and autonomous agents the way each one deserves.

Get Early AccessExplore How It Works
Toshendra Sharma

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

Two categories are no longer enough

For years, traffic was split into two buckets: humans and bots. Humans got the product. Bots got blocked, rate-limited or ignored.

That split does not hold any more. Some automated visitors are agents acting on behalf of real customers: an assistant comparing plans, an agent pulling data through your API, a tool calling your MCP server to finish a task. AI providers now document this kind of user-initiated access themselves: OpenAI states that its ChatGPT-User agent visits pages when a user asks ChatGPT a question (OpenAI crawler documentation), and Anthropic lists Claude-User for the same purpose (Anthropic crawler documentation). At the same time, some people work hand in hand with AI, drafting messages, filling forms and navigating products with an assistant at their side. Forcing all of that into human or bot produces bad decisions in both directions. Legitimate agents get blocked, and real people get challenged because their behavior looks unusual.

To distinguish human and AI agent traffic in a way that leads to good decisions, you need more categories and you need to know how much each result can be trusted. The blog post on how to tell if website traffic comes from AI agents walks through the signals that make this possible, and the SaaS apps use case shows where the distinction changes product decisions.

Four classes, each with a precise meaning

Proof of Actor classifies interactions into four classes. Each one has a definition and an explicit limit, so nobody on your team reads more into a result than the evidence supports. For the reasoning behind this taxonomy, read Human, AI-assisted or agent: a taxonomy for app traffic.

Human

The supported observable signals indicate human-directed interaction. This class is about who is directing the interaction, not about identity. A Human result does not verify who the person is, and it does not claim that no AI was used anywhere.

Human + AI

AI assistance was declared, or observed through a supported integration that can actually see it. Examples include a user marking content as drafted with AI through your own disclosure control, or your application reporting that its built-in assistant performed an action for a signed-in user. Read more in the AI-assisted interaction glossary entry.

Agent

Automated or agent-origin interaction, supported by verifiable identity, such as a valid request signature from a published key, or by a carefully qualified inference. An Agent result describes who is acting. It does not mean the agent is authorized, safe or acting with valid delegation from a person. Read more about autonomous agents.

Unknown

The available evidence does not support a reliable determination. Unknown is an honest and useful result: it shows where your coverage ends, and it lets your policies handle uncertain cases deliberately instead of by accident.

Every class comes with a basis

Separating human and agent traffic is only half the job. The other half is knowing how strong each conclusion is. That is why every Proof of Actor result carries a basis:

  • Verified: a checkable assertion validated, for example a request signature checked against a published key.
  • Declared: the client or your application stated it, for example an agent naming itself or a user disclosing AI assistance.
  • Inferred: a conclusion drawn from behavioral or contextual signals, always labeled as an inference.
  • Unknown: not enough evidence for a determination.

The combination of class and basis is what lets you build precise rules. A verified agent and an inferred agent are both agents, but you may want to give the first one a structured API and treat the second with a standard rate limit. A declared AI-assisted submission and a human session can both proceed normally, with a label that helps your support team. You can find the full taxonomy on Detection & Limitations.

How the classification happens

Proof of Actor follows the same evidence-first path for every interaction. The full explanation lives on How It Works.

The signals your integration can see

  • Request signatures from automated clients that publish their keys, using HTTP Message Signatures as defined in RFC 9421. The IETF Web Bot Auth working group is chartered to standardize how automated clients authenticate this way.
  • Declarations from clients that identify themselves, such as the documented user agents of AI crawlers and fetchers, and from your own application when it knows AI assistance is involved.
  • Request context available to a server-side integration, such as headers and protocol details.
  • Interaction signals from an approved browser integration on the pages where it runs.

From signals to a result

Signals are checked, labeled by basis and combined. Strong verified evidence produces a confident result. Weak or conflicting evidence produces a qualified inference or Unknown. A timeout or missing signal never becomes a Human result. The output is a class, a basis and an evidence summary that anyone on your team can read.

What you can do once the traffic is separated

Proof of Actor is organized around three capabilities: Detect, Understand and Route.

Detect the actor behind each interaction

Collect the signals available in each context and separate verified assertions from inferences. Keep Unknown visible.

Understand how each actor uses your product

See the mix of human, AI-assisted, agent and unknown activity by route and over time. Open any result to see what is known and what is not. Spot the routes where agents concentrate and the workflows where AI assistance is common.

Route each actor to the right experience

Apply your own policies once the evidence supports them. On a public website, the websites use case shows how these choices map to real routes:

  • Serve verified agents a structured response or API instead of human-shaped pages.
  • Keep the standard experience for human-directed sessions.
  • Label AI-assisted submissions so the right team handles them.
  • Ask for stronger credentials on sensitive actions when your own conditions call for it.
  • Choose an explicit fallback for Unknown on each route, such as allowing public pages and keeping existing checks on account changes.

The guide on rolling out actor-aware policies safely covers how to move from observation to enforcement one route at a time.

Why this matters for your users

Getting this right is good for everyone who uses your application.

People get a smoother experience because they are not challenged on the strength of a vague score. People working with AI get support for disclosed assistance in workflows where it fits. Legitimate agents get a reliable, structured way to do their jobs, which reduces scraping and load on your interface. Your team gets explainable decisions, so support conversations, incident reviews and policy changes rest on evidence instead of guesswork.

A login is not the actor

One of the most common sources of confusion is the account itself. A signed-in session tells you which account is in use. It does not tell you who is directing the current interaction. The same account can be used by its owner clicking through settings in the morning, by an assistant the owner asked to export a report at noon, and by an agent working through an API key in the evening.

Treating all three the same way creates problems in both directions. If every request on the account is assumed to be the owner, an agent can reach workflows that were designed for a person. If every unusual request is assumed to be an attack, the owner's own tools get blocked. Separating the actor from the account lets your application keep authentication and authorization exactly as they are, and add the missing context about who is acting right now. That context is what makes it possible to offer agents structured access without opening human-only workflows to them.

Start in observation mode

Every deployment begins in observation mode. Proof of Actor records results while your application responds exactly as before. Your team builds a baseline of human, AI-assisted, agent and unknown activity, compares it with outcomes you already know, and reviews any false positives before a single rule changes. When a policy is ready, you enable it for one workflow and expand from there.

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 feedback. You get direct integration support from our engineers, early access to capabilities, and influence over priorities.

If you need to distinguish human and AI agent traffic in your application, apply for early access and tell us about the interaction you most want to understand.

Explore Proof of Actor, read how it works, or see exactly what the evidence can 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 do you distinguish human and AI agent traffic?

Proof of Actor combines the signals your integration can observe, such as request signatures, client declarations, request context and browser interaction signals, and returns a class with an explicit basis.

Why is there a Human + AI class?

Some people work with an AI assistant at their side. Treating them as either fully human or fully automated loses important context. Human + AI covers assistance that is declared or observable through a supported integration.

Is an Agent result the same as a bad bot?

No. Many agents are legitimate participants. An Agent result describes who is acting, not whether the action is allowed. Your policies decide how each agent is served.

What if the traffic cannot be classified?

It is reported as Unknown, a first-class result. Unknown is never converted to Human and never treated as malicious by default.

Do I have to block anything?

No. You start in observation mode, review results, and enable policies only where your team is confident they fit.

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