Skip to main content
GLOSSARY

Unknown classification

Toshendra Sharma

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

The result reported when available evidence does not support a reliable determination of the actor. Unknown is neither Human nor suspicious by default.

Definition

An Unknown classification is the result an actor intelligence system returns when the evidence available for an interaction does not support a reliable determination. It says, precisely: we cannot tell from what we observed whether this is a person, a person with AI, or an agent.

Unknown is one of the four classes in Proof of Actor, alongside Human, Human + AI and Agent. It is a first-class result, not an error state and not a polite way of saying "probably a bot". Our post on why Unknown is a valid result when classifying AI traffic makes the full case.

Why Unknown is valuable

Classification systems that must always pick an answer end up making confident guesses. Those guesses look like data, flow into dashboards and policies, and quietly cause harm: a legitimate customer gets challenged, or an automated client gets treated like a person on a sensitive route.

Reporting Unknown instead gives teams three things:

  1. Honest coverage. The share of Unknown results tells you where your integration has visibility and where it does not.
  2. Safer policies. A policy can define exactly what Unknown means for each route rather than inheriting a hidden guess.
  3. A path to improvement. If a route shows a high Unknown rate, you can add a better signal source there, such as a browser integration or support for signed agent requests.

Common causes of Unknown

  • No supported integration runs on that route, for example a browser collector is absent.
  • The client does not run JavaScript and sends no identity evidence.
  • Too few interaction signals were observed, for example a very short session.
  • A request arrived without a signature and with a generic or missing client description.
  • The evidence that exists conflicts, and no part of it is strong enough to decide.

How applications should treat Unknown

Unknown should map to an explicit fallback that the application owner chooses per route:

  • Public, low-risk pages: allow, with no extra friction.
  • Read-only APIs: allow with standard rate limits.
  • Account changes and other high-impact actions: keep the application's existing checks, such as re-authentication, and do not decide anything based on the Unknown result itself.

The same thinking applies to timeouts and missing telemetry. Whether a route fails open or fails closed is a deliberate decision made in advance, not an accident.

Common misconceptions

"Unknown means suspicious." It means insufficient evidence. Many perfectly ordinary visitors produce Unknown results.

"Unknown should default to Human." Never. Converting Unknown to Human hides the gap and can grant human-level trust to automation.

"A good system has no Unknowns." A system with no Unknowns is one that guesses. A visible, explained Unknown rate is a sign of an honest classifier.

Unknown in Proof of Actor

Proof of Actor reports Unknown whenever the evidence basis does not support a determination, never converts it to Human, and keeps the Unknown rate visible in analytics. Teams define the fallback for each route while in observation mode, before enabling any policy. Read Detection & Limitations for the full model, or apply for early access.

See actor intelligence in your own app.

Prefer to talk first? Talk to the founders