Skip to main content
UNKNOWN TRAFFIC

Make unknown automated traffic visible

Most applications cannot tell what a large share of their automated traffic is. Proof of Actor keeps that traffic visible as its own class, so you can measure it, shrink it and handle it deliberately.

Get Early AccessExplore How It Works
Toshendra Sharma

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

The traffic nobody can name

Look closely at an application's logs and you will find requests that resist explanation. They come from clients without a browser context. Their user-agent strings are generic, empty or copied from a popular browser. They do not sign their requests. They do not say who sent them. Some are harmless scripts. Some are agents working for real users. Some are tools you would rather not serve at all.

This is unknown automated traffic, and most teams handle it in one of two ways. Either it is quietly counted as human, which distorts analytics and lets risky activity through, or it is treated as hostile by default, which blocks legitimate users and agents along with everything else. Both approaches share the same flaw: they replace missing evidence with an assumption.

Proof of Actor takes the opposite view. If the evidence does not support a reliable determination, the right answer is Unknown, and Unknown should be visible, measurable and handled on purpose. The blog post why Unknown is a valid result for AI traffic makes the full case.

Why Unknown is a first-class result

Proof of Actor classifies every interaction into one of four classes: Human, Human + AI, Agent or Unknown. Unknown is not an error state or a gap in the product. It is a deliberate result with a precise meaning: the available evidence does not support a reliable determination.

That honesty has practical benefits.

  • Your analytics stay accurate. Human and Agent counts only include interactions with supporting evidence, so they mean what they say.
  • Your coverage is measurable. The share of Unknown on each route tells you exactly where you need more evidence.
  • Your policies are safer. Uncertain cases flow into a fallback you chose, instead of being silently treated as trusted or blocked by a guess.

Unknown is never converted to Human, and it is never treated as malicious by default. You can read more in the Unknown classification glossary entry, on Detection & Limitations, and in why Unknown is a valid result for AI traffic. The websites and APIs use cases show how teams set Unknown fallbacks in practice.

Where unknown automated traffic comes from

Understanding the sources helps you decide how to handle it.

Unsigned automated clients

Request signing with HTTP Message Signatures, defined in RFC 9421, is optional, and the IETF Web Bot Auth working group is still standardizing how automated clients should authenticate this way. Without a signature, a client's identity rests on whatever it chooses to say about itself.

Copied or generic user agents

User-agent strings are trivial to set. A client claiming to be a well-known browser or crawler may be exactly that, or may be imitating it. The user-agent spoofing entry explains why this header alone cannot carry a classification. It is also why search engines document separate verification methods: Google describes reverse and forward DNS lookups plus published IP ranges for verifying Googlebot, and Bing describes the same DNS check for verifying Bingbot.

Routes without an integration

If a route has no browser integration and no server-side context beyond the basics, there is simply less to observe. Unknown on those routes is a sign of coverage, not of threat.

Missing or delayed evidence

A timeout, a blocked script or an incomplete request can leave a result without enough evidence. Proof of Actor reports that honestly instead of filling the gap.

How Proof of Actor makes Unknown manageable

Proof of Actor organizes its work into three capabilities. Each one helps with unknown automated traffic.

Detect: keep Unknown separate

Signals are checked and labeled by basis: verified, declared, inferred or unknown. When they do not support a determination, the result is Unknown with a summary of what was and was not available. Nothing is guessed into another class.

Understand: see where Unknown lives

The Understand view shows Unknown in every breakdown, by route and over time. You can see which routes have the most unknown activity, how it changes after you add an integration, and what evidence was present for individual interactions. This turns a vague worry into a concrete map.

Route: choose the fallback per route

Different routes deserve different fallbacks. A reasonable starting point for many applications:

  • Public pages and documentation: allow Unknown with your standard rate limits.
  • Signup and onboarding: keep your existing checks, and add review only when your own conditions call for it.
  • Account changes and other sensitive actions: rely on your existing authentication and step-up controls, never on an actor guess.
  • High-impact API operations: require the stronger credentials or controls your API already supports.

The guide on handling unknown traffic walks through designing these fallbacks, including fail-open and fail-closed choices for each risk tier.

Shrinking Unknown over time

The goal is not to eliminate Unknown overnight. It is to make it smaller every month, for the right reasons.

  • Add integrations where it matters. A browser integration on key pages and a server-side integration on key routes increase the evidence available.
  • Support signed requests. As agent operators adopt HTTP message signatures, traffic that was Unknown becomes verified Agent traffic.
  • Record declarations in your own app. When your application knows AI assistance is involved, say so. That evidence is precise and cheap.
  • Offer agents a front door. Publishing a structured path for agents encourages them to identify themselves rather than blend in.

Because Proof of Actor tracks Unknown by route, you can see each of these changes in the numbers.

How it works

Every interaction follows the same evidence-first path, described in full on How It Works: your application receives a request or event, the integration gathers the signals available in that context, signals are normalized and classified with an explicit basis, the result is recorded for analytics, and your application applies its own policy or simply observes.

Timeouts and missing telemetry are handled explicitly. Your integration uses the fallback you chose for that route, and the result is never upgraded to Human because evidence was missing.

What good looks like after a few months

Teams that handle unknown automated traffic well tend to reach the same healthy state. Unknown is a known quantity on every important route, tracked in the same dashboard as human and agent activity. Each route has a written fallback that the product, platform and security teams agreed on together. Verified agent traffic grows as more operators sign their requests, and those agents are served through a structured path instead of scraping pages. Sensitive actions are protected by the authentication and step-up controls the application already trusts, with actor context as an extra input rather than a gatekeeper.

Most importantly, nobody is guessing. When someone asks how much of last week's traffic was automated, the answer comes with its basis: this much verified, this much declared, this much inferred, and this much still Unknown. That is a number a team can plan around. It also changes the conversation with leadership, because the question stops being whether bots are a problem and becomes which routes deserve more evidence and which fallbacks need refining.

Start in observation mode

Proof of Actor does not block anything by default. In observation mode, results are recorded while your application responds exactly as before. Your team sees how much unknown automated traffic each route receives, compares it with outcomes you already know, and designs fallbacks based on real patterns. Policies are enabled one route at a time, only when your team is confident they fit.

Join the founding developer program

Proof of Actor is in private beta. Selected founding developer teams can receive up to 12 months of free access, within agreed usage limits, in exchange for hands-on product feedback, with direct integration support from our engineers.

If unknown automated traffic is clouding your analytics or your security decisions, apply for early access. Tell us about your application and the routes where Unknown matters most.

Explore Proof of Actor, read how it works, or see 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

What is unknown automated traffic?

It is activity where the available evidence does not reliably show whether a person, a person with AI or an autonomous agent is acting, often unsigned clients with no browser context and generic or copied user-agent strings.

Why not just block unknown traffic?

Unknown is not the same as malicious. It includes legitimate clients, privacy-focused browsers and tools that simply do not identify themselves. Blocking it outright causes real damage. A deliberate fallback per route works far better.

Does Proof of Actor ever turn Unknown into Human?

Never. An Unknown result stays Unknown, including when evidence is missing or a check times out. Your policy chooses the fallback for each route.

Can unknown traffic be reduced over time?

Yes. Adding integrations on more routes, supporting signed requests and recording declarations in your app all move traffic from Unknown into classes with a clear basis.

Where can I see unknown traffic?

In the Understand view, Unknown has its own class in every breakdown, by route and over time, with the evidence that was available for each interaction.

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