Understand who's calling your API.
Add actor context to every API request: which client is calling, how strong the evidence is, and what your API should do about it, route by route.
POST /api/v1/orders
Evidence
API-key traffic with no browser context and an automated request pattern
Your policy: Ask for the stronger credential before creating the order
An API key is not an identity, and identity is not permission.
Most API traffic arrives with a credential that says which account is paying, not which client is calling or who instructed it. Some clients sign their requests, many only declare a name, and many say nothing at all.
Proof of Actor separates the three questions every API has to answer, so each one gets the right evidence and the right control.
- Who is calling?Actor identity: signature, declaration or inference
- Which credential?Your API key, OAuth token or session
- What may it do?Your authorization and policy
Proof of Actor answers the first. Your stack keeps the other two.
What API teams do with actor context
Recognise signed clients
Check request signatures against published keys and see which operator a request belongs to.
Treat declarations as declarations
Record self-declared client names, and keep them separate from verified identity.
Policies per route
Allow low-impact reads freely and ask for more on writes and high-impact endpoints.
See every caller
Understand which clients use which endpoints, including the unknown ones.
Keep credentials separate
API keys and OAuth still decide access. Actor context adds who is calling.
Plan for Unknown
Define what happens when a caller provides no usable evidence, per route.
01 · Detect
Evidence from every request.
Server, edge and HTTP API integrations read request signatures, declared client details and request context, and label each with its basis.
- HTTP message signatures verified against published keys.
- Declared client names recorded as declarations.
- Request context from your server, gateway or edge.
- Request signaturevalid · sample-crawler.exampleverified
- Client declaration"research-assistant/2.1"declared
- Browser interactionpointer + keyboard eventsinferred
- No supported signalsroute not instrumentedunknown
02 · Understand
Know who uses which endpoint.
See the actor mix on each route, which operators call you most, and where unknown callers concentrate.
- Callers by route and operator.
- The evidence behind every classification.
- Unknown rate per endpoint.
- /dashboardUnknown 7%
- /api/v1/catalogUnknown 15%
- /support/ticketsUnknown 8%
- /signupUnknown 21%
03 · Route
Controls that match the impact.
Write route-level policies: structured responses for verified agents, standard limits for declared clients, stronger credentials for high-impact actions.
- Policies by route, class and basis.
- Step up to stronger credentials when it matters.
- Observe, preview, then enforce.
- /api/v1/catalogenforceAgentAllow · structured API
- /support/ticketsenforceHuman + AIAllow · label AI-assisted
- /account/*previewUnknownKeep existing checks
- /api/v1/orderspreviewAgentRequire stronger credential
Example decisions
From request to result to your decision.
A verified agent reads your catalog
Request
GET /api/v1/catalog
Result
Agentbasis: verifiedYour decision
Allow with the agent rate limit and the structured response.
An automated client places an order
Request
POST /api/v1/orders
Result
Agentbasis: inferredYour decision
Ask for the app's stronger credential before creating the order.
A client with no evidence
Request
GET /api/v1/catalog
Result
Unknownbasis: unknownYour decision
Read-only route: allow with the default rate limit.
Roll out without risk
Teams start in observation mode and move route by route.
- 01
Observe every route
Add the middleware or HTTP API in front of your API. Signatures, declarations and Unknown callers are recorded per route.
- 02
Preview route policies
Check what agent rate limits or step-up credentials would have done on real traffic before they apply.
- 03
Enforce by impact
Keep reads open, tighten writes, and keep API keys and OAuth in charge of access.
Works with your stack
- Founding teams
Web server middleware (Node.js)
Server-side
Request-level signals for server-rendered apps and APIs.
- Founding teams
Next.js
Server-side and edge
Middleware for page and API routes.
- Founding teams
Browser script
Browser signals only
Interaction signals from browser sessions, alongside a server-side integration.
- Founding teams
Cloudflare and edge runtimes
Edge
Signals at the edge before requests reach your origin.
- Founding teams
Generic HTTP API
Any stack
Send request context to an API and receive a result with its basis.
- Founding teams
MCP server
MCP
Actor context for MCP tool calls.
- Roadmap
WordPress
Plugin
Plugin for WordPress sites.
- Roadmap
Native mobile
iOS and Android
Native iOS and Android SDKs.
Integrations are delivered hands-on with each founding team during onboarding. Using a different stack? Tell us when you apply.
Frequently asked questions
Do clients need to sign their requests?
No. Signed requests give the strongest evidence, but Proof of Actor also records declarations and inferences, each labeled with its basis, and reports Unknown when there is not enough.
Does a valid signature mean the client is allowed to act?
No. It shows the request was signed with a key tied to a published identifier. What that operator may do is decided by your authorization and policy.
Does it replace API keys or OAuth?
No. Credentials still control access. Proof of Actor adds who or what is calling, so you can apply better policies on top.
Can we set different rules per endpoint?
Yes. Policies are written per route, so read-only endpoints and high-impact writes can be treated differently.
What does it cost?
Selected founding developer teams can receive up to 12 months free within agreed usage limits.
Know who's calling your API.
Join the Proof of Actor founding developer program.
Prefer to talk first? Talk to the founders