What Proof of Actor can establish, and what it cannot.
A plain description of the classifications, the evidence behind them, the contexts they apply to, and the limits we design around.
- Request signaturevalid · sample-crawler.exampleverified
- Client declaration"research-assistant/2.1"declared
- Browser interactionpointer + keyboard eventsinferred
- No supported signalsroute not instrumentedunknown
The short version
| What Proof of Actor can tell you (when supported) | What it cannot guarantee |
|---|---|
| Whether a supported agent request signature validates | That the agent is honest, safe, or permitted to perform any action |
| Whether a session exposes certain interactive or automation signals | That a human used no AI outside your observable integration |
| Whether AI use was declared or observable in a supported workflow | Universal detection of AI assistance, copied content, or another device |
| That evidence was insufficient | That an unknown interaction is malicious |
Availability depends on your integration and enabled checks. The application owner retains control of enforcement decisions.
Classifications
Four public classes. Each has a defined meaning and an explicit limit.
- Human
The supported observable signals indicate human-directed interaction.
Does not mean: That no AI was used, or that the person's real-world identity is verified.
- Human + AI
AI assistance was declared, or detected by a supported integration that can actually observe it.
Does not mean: That all hidden AI use can be detected, including another tab or another device.
- Agent
Automated or agent-origin interaction, supported by verifiable identity or a carefully qualified inference.
Does not mean: That the agent is authorized, safe, or acting with valid delegation from a person.
- Unknown
The available evidence does not support a reliable determination.
Does not mean: That the interaction is suspicious or malicious.
Verified, declared, inferred, unknown
Every result carries a basis. A class never disguises an inference as cryptographic verification, which matters most for security-sensitive applications.
- verified
- Verified. A cryptographic or otherwise checkable assertion validated, for example a request signature against a published key. It proves that check, nothing more.
- declared
- Declared. The actor or your application stated it, for example an AI-assistance disclosure or a client that names itself as an agent. A declaration can be untrue.
- inferred
- Inferred. A conclusion drawn from behavioral or contextual signals. Inferences can be wrong and are always labeled as inferences.
- unknown
- Unknown. Not enough evidence for a determination. The result is reported as Unknown rather than guessed.
Where a confidence figure would need a tested, calibrated model behind it, we use qualitative evidence strength instead. You will not see a figure like 99.7% human from us unless it has been measured and explained.
Supported contexts and their limits
Browser
A browser collector sees interactive sessions on the pages where it runs. It cannot see clients that do not run JavaScript, activity in other tabs, applications or devices, or text a person copied in from elsewhere.
Server and API
A server-side integration sees request context and, where clients support it, request signatures. It cannot see a person's screen, and most unsigned clients can describe themselves however they like.
MCP
An MCP server sees the client's declared details and the tool calls it makes. A declared client name is a declaration, not a verification.
Two limits worth understanding
AI-generated text from another tab or device
If a person asks a chatbot in another tab, or on their phone, and pastes the answer into your form, ordinary web traffic usually shows nothing about it. The session looks human-directed because a human directed it.
Proof of Actor reports Human + AI only when assistance was declared, or observed by a supported integration that can actually see it, such as your app's own assistant feature.
What a signed bot request proves
An HTTP message signature that validates against a published key shows that the request was signed with a key associated with that identifier, such as an operator's domain.
It does not establish the real-world identity of whoever is behind the request, whether a person delegated authority to it, or whether the action is safe or permitted. Standards in this area, including the IETF Web Bot Auth work, are still Internet-Drafts.
No default blocking
Proof of Actor does not block, reject or challenge anything by default. We recommend against blocking or rejecting solely on an inferred actor result, and especially against consequential decisions about people (employment, credit, financial services, education or access to essential services) based on one.
Enforcement happens in your application, under policies your team chooses and confirms, with explicit fallbacks for Unknown and for timeouts.
Unknown and abstention
When the evidence does not support a reliable determination, the result is Unknown. Unknown is never converted to Human, and it does not mean suspicious. Keeping it visible tells you where your coverage ends, which is information you need before enforcing anything.
Privacy and governance principles
Purpose limitation
Evidence describes interactions to the application owner. It is not used to build cross-site profiles.
Minimal collection
Each integration collects what its context needs. Sensitive telemetry requires explicit opt-in.
Tenant isolation
One customer's evidence is never visible to another customer.
Configurable retention
Retention is agreed with each founding team during onboarding.
Customer-controlled access
You decide who on your team can see evidence and results.
No identity checks
No biometric collection and no identity verification are part of Proof of Actor.
Agreed with every team
Performance and methodology
Coverage, the unknown rate, false positives and calibration are measured with founding teams in each supported context, against outcomes those teams already know. Methodology and results are published here as each context matures.
Questions about privacy or security? [email protected]