Human, AI-assisted or agent: a practical taxonomy for application traffic

A practical taxonomy for application traffic has four classes: Human, Human + AI, Agent and Unknown. Each result also states its basis, verified, declared, inferred or unknown, so a validated signature and a guess from request patterns never look alike. The account tells you who signed in; the class and basis tell you who or what is acting now, and how sure you can be.

Most applications were designed around a simpler assumption: a person sits at a keyboard, signs in, and clicks through the interface. Every analytics dashboard, rate limit and fraud rule quietly inherits that assumption. It still describes many interactions, but it no longer describes all of them.

Today the same application serves people working on their own, people working with an AI assistant, and autonomous agents that call pages and APIs with no person watching each step. Some of those agents are welcome. Some are the reason a team is suddenly looking at its logs. All of them share the same front door.

This article sets out that taxonomy in detail (the short version is on distinguishing human and AI agent traffic). It is the model we use at AgentCredia, and it is designed to be useful whether or not you ever use our product: four classes, a separate statement of basis, and a few rules that keep the result honest enough to build decisions on.

Why the account is not the actor

Authentication answers one question well: which account is this request associated with? It says much less about who or what is producing the request at this moment.

Consider a few ordinary situations:

• A user signs in, then asks a browser assistant to fill in a long settings form for them.
• A developer creates an API key on their account and hands it to an automated workflow that runs overnight.
• A support agent writes a reply with the help of an AI drafting tool inside your own product.
• A crawler run by an AI assistant fetches your public documentation because a user asked it a question. Operators document user-triggered agents of this kind, such as OpenAI's ChatGPT-User and Anthropic's Claude-User.

In every case the account, if there is one, is legitimate. The actor is different each time, and so is the experience that makes sense. A long form filled in by an assistant may be perfectly fine. An automated workflow probably belongs on your API rather than in a headless browser. A drafted support reply might deserve a label. A documentation crawler might be best served a clean Markdown version of the page.

None of those choices can be made from the account alone. They need a second piece of context: the actor behind the interaction, and how sure you can be about it.

The four classes

A useful taxonomy has to be small enough to drive decisions and precise enough not to mislead. Four classes meet both tests.

Human

The observable signals indicate human-directed interaction. A person is driving the session in the context your integration can see: interactive input on the page, timing and navigation consistent with someone using the interface.

What Human does not mean matters just as much. It does not mean that no AI was involved anywhere. A person can ask a chatbot on their phone and type the answer into your form, and nothing in ordinary web traffic will show it. It also does not mean the person's real-world identity has been verified. Human is a statement about who is directing the interaction, not about who the person is.

Human + AI

AI assistance was declared, or detected by an integration that can actually observe it. The clearest examples are inside your own product: a user selects "drafted with AI" on a submission, or your built-in assistant generates a report on the user's behalf. Your application knows these things directly.

Human + AI does not mean that every hidden use of AI can be found. Assistance in another tab, another application or another device is outside the view of a normal web integration. A taxonomy that pretends otherwise produces confident labels on guesses, and confident labels on guesses are worse than no labels at all.

Agent

The interaction is automated or agent-originated, supported by verifiable identity or a carefully qualified inference. A request signed with a key that validates against an operator's published key, using HTTP Message Signatures as defined in RFC 9421, is strong evidence of which automated client sent it. A high-frequency API pattern with no browser context is weaker evidence that the caller is automated, and should be labeled as such.

Agent does not mean the agent is authorized, safe, or acting with valid permission from a person. A valid signature tells you which client signed the request. Whether that client may perform a given action in your application is an authorization question, and your application answers it.

Unknown

The available evidence does not support a reliable determination. A request without browser signals, a client that runs no JavaScript, a short session with too few interactions, a route where no integration is installed: all of these can end up as Unknown.

Unknown does not mean suspicious. Plenty of legitimate traffic is unknown, from privacy-conscious browsers to simple scripts a customer wrote years ago. Treating Unknown as hostile punishes the wrong people. Treating it as Human hides it. The right move is to keep it visible and decide what it means for each route.

Category and basis are different things

The single most important design decision in this taxonomy is to separate the class from the basis behind it. A result should always answer two questions: what is this, and how do we know?

We use four bases:

• Verified: a checkable assertion validated. A cryptographic request signature that verifies against a published key is the clearest example; the IETF Web Bot Auth working group is standardizing this for automated clients. A crawler IP confirmed through an operator's documented method, such as Google's crawler verification, is another. Each proves exactly what the check covers and nothing more.
• Declared: the actor or your application stated it. A client that names itself as an agent, or a user who discloses AI assistance, has declared something. The MCP specification, for instance, describes the clientInfo a client sends as self-reported and not verified by the protocol (MCP base protocol). Declarations are useful and can be untrue.
• Inferred: a conclusion drawn from behavioral or contextual signals. Inferences can be wrong, and they are always labeled as inferences.
• Unknown: not enough evidence for a determination.

Why does this matter? Because a security-sensitive application should treat "Agent, verified" and "Agent, inferred" very differently, even though they share a class. The first can safely open a structured API for a known operator. The second might justify a rate limit and nothing more. If your data model only stores the class, that distinction disappears, and someone will eventually make a high-impact decision on an inference that looked like a fact.

A practical rule follows: never let a class disguise its basis. In dashboards, show both. In APIs, return both. In policies, branch on both.

A minimal result record

You do not need an elaborate schema to apply this model. A record like the following is enough to drive analytics and policy:

{
  "actor_class": "agent",
  "basis": "verified",
  "evidence_summary": "Request signature validated for the operator domain docs-assistant.example",
  "context": "api",
  "observed_at": "2026-11-12T10:42:07Z",
  "mode": "observe"
}

A few properties make this record useful in practice:

• Evidence summary in plain language. An engineer reviewing a decision should be able to read why a result was produced without opening a second tool.
• Context. Evidence from a browser, an API call and an MCP tool call are different things. Recording the context keeps comparisons fair.
• Time. Evidence has a moment and a scope. A result observed at sign-in should not quietly justify a sensitive action an hour later.
• Mode. Knowing whether a result was only observed or actually used by a policy is essential when you review outcomes later.

Notice what is missing: a precise percentage such as "97.3% human". A confidence number is only meaningful when it comes from a tested, calibrated model in a specific context. Without that, qualitative evidence strength (strong, moderate, limited) communicates more honestly and leads to better decisions.

How the taxonomy maps to decisions

Classes are only worth having if they change what your application does. Here is how the four classes typically map to experience and policy, route by route.

Public, read-only routes

Pricing pages, documentation and catalogs are usually open to everyone. The taxonomy helps you serve each actor well rather than restrict anyone. Verified agents can be pointed at a structured or Markdown version of the content. Unknown traffic gets the normal page. Human traffic sees nothing different.

Account and settings changes

Sensitive actions deserve care, but the actor class should rarely be the only input. A sensible pattern is to keep your existing safeguards (re-authentication, confirmation emails) for everyone and use actor context to decide when to add a step, not when to remove one. An Unknown result on a password change is not alarming on its own. It simply means your existing checks keep doing their job.

High-impact API actions

Creating orders, deleting data or changing permissions through an API are good places to combine actor context with authorization. A verified agent from a known operator might proceed with its normal credential. An inferred agent with no identity evidence might be asked for a stronger credential, or held to a lower rate limit, according to your rules.

Content submissions

Where AI assistance is acceptable, declared Human + AI submissions can be accepted and labeled. Where your workflow needs unassisted work, a declaration lets you route the submission accordingly. In both cases the decision rests on something the user or your application stated, not on a guess about what happened in another window.

Rules that keep classification honest

Over time we have settled on a short list of rules. They are as much about product design as about detection.

1. Never convert Unknown into Human. If a timeout or missing signal falls back to Human, your Human numbers quietly fill up with traffic you know nothing about.
2. Never treat Unknown as malicious by default. Decide what Unknown means per route: allow on public pages, keep existing checks on sensitive ones.
3. Show the basis wherever the class appears. A badge that says "Agent" should also say how that was established.
4. Keep evidence scoped in time and context. Re-evaluate before sensitive actions instead of reusing an old result.
5. Observe before you enforce. Run in observation mode, compare results with outcomes you already know, and review false positives before any policy changes a response.
6. Keep people out of consequential automated decisions. Actor results should not be the sole basis for decisions about employment, credit, education or access to essential services.

These rules are simple, but they are the difference between a classification system that teams trust and one they route around.

Where to start

You can apply this taxonomy with nothing more than your existing logs. Pick one route that matters, such as a public API endpoint or a sign-up flow in your SaaS app. For a week, label each interaction with a class and a basis using the evidence you already have: signed requests, user-agent declarations, interaction signals from your front end, in-product AI features. Count how much lands in Unknown. That number is the honest measure of how much you currently know, and our guide on handling unknown traffic covers what to do with it.

From there the next steps are natural: add better evidence where Unknown is high, design the right experience for each class, and only then introduce policies that act on the result.

How Proof of Actor applies this model

Proof of Actor is built directly on this taxonomy. It detects available actor signals and keeps verified assertions separate from behavioral inferences. It helps your team understand interaction types, routes, trends and the evidence behind each result. And it lets you route interactions with your own policies, starting in observation mode so nothing changes until you decide it should. Every result is Human, Human + AI, Agent or Unknown, with its basis stated, and enforcement always stays with the application owner.

If you operate a SaaS application, website, API or MCP server and want to see your own traffic this way, apply for early access. To go deeper on what the evidence can and cannot establish, read Detection & Limitations.

Sources

• RFC 9421: HTTP Message Signatures, IETF.
• Web Bot Auth (webbotauth) working group charter, IETF Datatracker.
• Model Context Protocol specification, base protocol and _meta fields (2026-07-28).
• Verifying Google's crawlers and fetchers, Google.
• Overview of OpenAI crawlers, OpenAI.
• Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.