How Proof of Actor works.
An evidence-first path from incoming interaction to application decision.
- /api/v1/catalogenforceAgentAllow · structured API
- /support/ticketsenforceHuman + AIAllow · label AI-assisted
- /account/*previewUnknownKeep existing checks
- /api/v1/orderspreviewAgentRequire stronger credential
From interaction to decision
- 01Application request or eventA page view, an API call, an MCP tool call or an in-app action.
- 02Signals from the supported integrationOnly what that integration can observe in that context.
- 03Evidence normalization and classificationSignals are checked, labeled by basis and combined.
- 04Actor result with basis and uncertaintyHuman, Human + AI, Agent or Unknown, plus what it rests on.
- 05Dashboard and analyticsTrends, routes and evidence for your team to review.
- 06Your application's own decisionObserve only, or apply a policy you have chosen.
What your code receives
Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.
{
"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
Observation mode is the default
Installing Proof of Actor does not block or change any request. Results are recorded so your team can compare them with real application outcomes, review false positives, and decide whether any policy is appropriate.
Types of evidence
The evidence available depends on the integration and the context. The checks for each workflow are agreed with the team during onboarding, and signal internals stay private so they are harder to imitate.
Request signatures
Cryptographic signatures from automated clients that publish their keys.
Declarations
A client naming itself as an agent, or an AI-assistance disclosure inside your app.
Interaction signals
Signals from an approved browser collector, on the pages where it runs.
Request context
Headers and protocol details available to a server-side integration.
How routing decisions fit in
Your application calls Proof of Actor, receives a result, and applies its own rules. You choose, per route and per risk tier, whether the integration fails open (the request proceeds as it would without Proof of Actor) or fails closed (your existing stronger check applies).
API timeout
If a result is not available in time, your integration uses the fallback you chose for that route. A timeout never becomes a Human result.
Missing telemetry
If the browser collector did not run or a signal is absent, the result reflects that. Missing evidence lowers what can be said; it is not treated as suspicious.
Unknown classifications
Unknown is a normal outcome. Your policy defines what Unknown means for each route, for example: allow public pages, keep existing checks on account changes.
Stale evidence
Evidence has a time and a scope. A result from earlier in a session should not be reused for a later, more sensitive action without a fresh check.
The beta integration workflow
- 01ApplyTell us about the app and the interaction you want to understand.
- 02ScopeAgree the integration, the routes, usage limits and data handling.
- 03Integrate in observation modeNo change to how your app responds.
- 04ValidateCompare results with ground truth you know: coverage, unknown rate, false positives, latency.
- 05DecideEnable a policy only where the evidence supports it.
What we measure with founding teams
Start in observation mode.
Apply to join the founding developer program.
Prefer to talk first? Talk to the founders