COMPARISON

Proof of Actor vs API bot protection: keys say who pays, actor context says who is acting

API gateways, WAF bot rules, API keys and rate limits keep your API available and accountable. They were not built to tell you whether a request came from a person in an app, a person working with an assistant, or an autonomous agent. Here is how bot management for APIs compares with Proof of Actor, and how the two fit together.

Get Early Access Explore How It Works

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

APIs used to have a simple traffic model. A developer registered, got a key, wrote an integration, and that integration called your endpoints on a schedule or when a user clicked something. Bot management for APIs grew up around that model: authenticate the key, cap the volume, filter the obviously abusive traffic, and keep the service available for everyone else.

That model still holds, and the tools built for it still matter. What changed is who sits behind the calls. The same API key can now carry requests from a person using your customer's app, a person who asked an AI assistant to do the work, and an autonomous agent running a multi-step task overnight. Your existing controls see one key and one request rate. Your product, support and policy decisions often need to know more.

Proof of Actor fills that gap. It tells your API who or what is acting on each request and states the evidence, then leaves the decision to your code. This page compares it with the main layers of API bot protection so you can see where each belongs.

The short version

	API bot protection	Proof of Actor
Main question	Is this request allowed, authenticated and within limits?	Who or what is acting, and what is the evidence?
Typical layers	API gateway, WAF bot rules, API keys, rate limits	Actor classification inside your API or MCP server
Identifies	The account or integration that owns the key	The actor behind each request: Human, Human + AI, Agent or Unknown
Output	Allow, reject, throttle; sometimes a bot score	A class plus a basis: verified, declared, inferred or unknown
Unclear traffic	Usually allowed if the key is valid, or rejected by a rule	Unknown, with a fallback you choose per route
Who decides the response	Gateway and WAF configuration	Your application code
Default on install	Enforcement	Observation; nothing changes until you add a policy
Best at	Availability, abuse filtering, quotas, accountability	Serving each actor correctly and understanding API usage

The sections below explain each part.

What API bot protection does well

It is worth being specific about the job each layer does, because Proof of Actor is designed to sit beside all of them, not to replace any of them.

API gateways

A gateway is the front door for your API. It terminates connections, authenticates API keys or tokens, routes requests to the right service, enforces quotas and often records usage for billing and analytics. It answers "is this caller allowed in, and through which door?" quickly and consistently across every endpoint.

WAF bot rules

A web application firewall with bot rules inspects traffic for known attack patterns and abusive automation. It can filter injection attempts, block traffic from sources with a history of abuse, and challenge or drop requests that look like scraping or credential attacks. It is your best defence against traffic that should never reach your code.

API keys and tokens

Keys and tokens give you accountability. Every request maps to an account, so you know whose integration made a call, you can revoke access, and you can attribute usage. Scoped tokens go further and restrict what a caller may do.

Rate limits

Rate limits protect availability. They stop one integration from consuming capacity meant for everyone, and they slow down brute-force and enumeration attempts. Per-key and per-route limits are a standard, effective control.

Together these layers answer the protection and accountability questions very well. Keep them.

The question they were not built to answer

None of those layers is designed to tell you what kind of actor sits behind an authenticated request. A valid key says which account owns the integration. It does not say:

whether this specific call came from a person tapping a button in your customer's app,
whether a person asked an AI assistant to perform the action,
whether an autonomous agent made the call as one step in a longer task,
or whether nobody can tell.

That distinction matters more each month. An API that serves a CRM integration, a scheduling tool or a developer platform increasingly receives agent traffic through the same keys that serve human-driven apps. If you want to give agents a structured response, require confirmation for high-impact writes driven by agents, label AI-assisted submissions, or simply measure how much of your API usage is agent-driven, you need actor context.

What Proof of Actor adds to an API

Proof of Actor returns one of four classes for each interaction:

Human: the observable signals indicate human-directed interaction.
Human + AI: a person directed the interaction with AI assistance that was declared or observed through a supported integration.
Agent: automated or agent-origin interaction.
Unknown: the evidence does not support a reliable determination.

Every result also states its evidence basis:

Verified: for example, an HTTP Message Signature (RFC 9421) checked against a published key.
Declared: the client or your own application stated it.
Inferred: behavioral or contextual signals, clearly labeled as inference.
Unknown: no reliable basis.

For APIs, the verified basis is especially useful. Agents that sign their requests can be checked against their published keys, which is the approach behind the IETF Web Bot Auth work. Read the explainer on Web Bot Auth for product teams for background, and the guide on verifying signed agent requests for the implementation side.

One limit matters here. A valid signature proves which key signed the request. It does not prove the agent is authorized to perform the action. Authorization stays where it belongs, in your API's own access control. The agent authorization entry explains the difference.

Scores and keys versus actor evidence

Some bot protection products attach a score to each request. A score is efficient for a block decision. It is less useful for API product decisions, because it does not tell you whether a legitimate request was human-driven or agent-driven, and it does not separate verified facts from inference.

API keys have the opposite limit. They are precise about ownership and silent about the actor. One customer's key can carry all four classes in a single hour.

Proof of Actor keeps both distinctions visible. Your API sees the account from the key, the actor class from Proof of Actor, and the basis that supports it. Each layer answers the question it is good at.

Where each one runs

Gateways and WAFs run at the edge of your network or in front of your services. That position is right for protection and quotas.

Proof of Actor runs where your API logic lives. Founding teams can integrate through Node.js middleware, Next.js, an edge layer you control, the generic HTTP API, or an MCP server integration. See integrations for the full list. Because it runs inside your application, it can use what your API knows: the route, the workflow, whether a client declared itself, and whether a signature verified.

Routing decisions stay in your code

Proof of Actor does not block anything by default. It starts in observation mode, so installing it changes nothing about how your API responds. You see your actor mix by endpoint, review evidence for individual results, and watch your Unknown rate.

When you are ready, you write application-defined policies per route, per actor class and per basis. Typical outcomes are:

Allow: serve the request normally.
Adapt: return a structured or reduced response for a verified agent.
Challenge: require an extra confirmation step, for example a human approval on a high-impact write.
Review: queue the action for a person to check.
Rate-limit: apply a tighter limit to a specific class and basis on a specific route.

You can preview a policy against real traffic before enforcing it, then enforce route by route. The guide on rolling out actor-aware policies safely covers the process, and protecting sensitive actions without blocking agents shows common patterns.

Handling Unknown API callers

Every API receives traffic that cannot be classified with confidence. With traditional controls, a valid key usually means the request goes through, and an invalid one means it does not. There is nothing in between.

Proof of Actor gives you an explicit Unknown result and lets you choose the fallback per route. Read-only catalog endpoints can stay open. Account changes can keep your existing stricter checks. Bulk exports can go to review. See handling Unknown traffic and unknown automated traffic for the details.

How they combine

The strongest API setup uses each layer for its own job:

At the edge, the WAF filters abusive and malformed traffic.
At the gateway, keys are authenticated, quotas are enforced and usage is recorded.
Inside the API, Proof of Actor classifies each request that gets through and states its basis.
In your handlers, policies use the class and basis to choose the response: normal handling for a human-driven call, a structured response for a verified agent, a confirmation step for an agent-driven high-impact write, a fallback for Unknown.
In analytics, your team sees which endpoints and workflows each actor class uses, alongside the account data from the gateway.

Nothing in this stack is duplicated. The gateway knows the account, the WAF knows the threat patterns, and Proof of Actor knows the actor.

When to focus on which

Focus on API bot protection first when your main problems are abuse, availability or unmetered usage: credential attacks against auth endpoints, aggressive scraping, or one integration starving others.

Focus on Proof of Actor when your main questions are about your callers: how much of your API traffic is agent-driven, which agents call which endpoints, where human-driven and agent-driven usage differ, and which routes need an actor-aware policy. The APIs use case and AI agent identification for APIs go deeper.

Most teams running a production API need answers to both.

Get started

Proof of Actor is in private beta. Selected founding developer teams can receive up to 12 months of free access within agreed usage limits, with no automatic billing. Apply for early access and tell us about the API and the callers you want to understand.

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

Does Proof of Actor replace my API gateway or WAF?

No. Your gateway still authenticates keys and enforces quotas, and your WAF still filters abusive traffic. Proof of Actor runs inside your API and adds actor context to the requests that get through. Keep your existing controls.

If every caller has an API key, why do I need actor context?

An API key identifies the account that owns the integration. It does not say whether a given request was driven by a person clicking in your customer's app, a person using an AI assistant, or an autonomous agent running a task. Proof of Actor reports that, with its basis.

Can Proof of Actor verify which agent is calling my API?

When a client signs its requests with HTTP Message Signatures (RFC 9421) and publishes its key, Proof of Actor checks the signature and reports a verified basis. A valid signature proves which key signed the request. It does not prove the agent is authorized to act, so authorization stays in your code.

Will Proof of Actor start rate-limiting or blocking my API traffic?

No. It starts in observation mode and blocks nothing by default. Rate-limit is one outcome you can choose in a policy, per route, actor class and basis, and enforcement lives in your own code.

How do I add Proof of Actor to an API?

Founding teams can use Node.js middleware, Next.js, an edge integration or the generic HTTP API. MCP servers have their own integration. See the integrations page for details.

What happens to callers you cannot classify?

They are reported as Unknown, a first-class result. You choose the fallback per route, for example allow on read-only endpoints and keep your stricter checks on write endpoints.

Know who's using your app.

Private beta for a small group of founding developers.

Get Early Access View pricing

Prefer to talk first? Talk to the founders