AI AGENT IDENTIFICATION

AI agent identification for APIs

Your API already knows which key made a request. Proof of Actor tells you what kind of actor was behind it, what evidence supports that, and lets your code decide what happens next.

Get Early Access Explore How It Works

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

Your API knows the key. It does not know the actor.

Every API request arrives with some proof of who is paying for it: an API key, an OAuth token, a session. That proof answers one question well. It tells you which account is responsible for the call. It does not tell you what is actually making the call right now.

A single API key can be used by a developer testing in a terminal, by a backend job running on a schedule, by a person working through an AI assistant, and by an autonomous agent that was handed the key and told to finish a task. Those are very different actors. They have different rhythms, different failure modes and different risk profiles. Treating them all the same way means you either over-restrict the legitimate automation your customers rely on, or you under-protect the parts of your API that should never be driven by an unattended agent.

AI agent identification for APIs closes that gap. Instead of inferring everything from the key, you get a classification of the actor behind each request, together with the evidence that supports it. That is what Proof of Actor is built to deliver, and the APIs use case shows how API teams apply it route by route.

Why API teams need actor context now

Automated traffic to APIs is not new. Scripts, integrations and crawlers have always been part of the picture. What has changed is the kind of automation. AI agents can read documentation, chain calls together, retry creatively and act on behalf of people who are not watching every step. Many of them are useful and welcome. Some are poorly built. A few are hostile.

Without actor context, API teams tend to fall back on blunt tools:

Rate limits per key, which slow down good agents and bad agents equally.
User-agent rules, which break the moment a client changes a header.
Blanket blocks, which push legitimate automation to scrape your web app instead.

Actor context lets you respond with precision. A signed agent from an operator you recognise can get a higher limit on read routes. An unknown caller hitting a write route can be asked for a stronger credential. A human using an AI assistant can keep a normal experience. The point is not to stop agents. The point is to give each kind of caller the right path. For what a signed request can and cannot tell you, read what signed AI agent requests prove.

How AI agent identification works in Proof of Actor

Proof of Actor follows the same evidence-first flow for every request. You can read the full walk-through on How It Works; here is the short version for API teams.

1. Signals from your integration

Your integration passes Proof of Actor the signals available in that context. For an API, that typically means request context such as headers and protocol details, any cryptographic request signatures the client provides, and any declarations the client makes about itself. Each signal is labelled with where it came from.

2. Classification with a basis

The signals are checked and combined into one of four public classes:

Human: the observable signals indicate a human-directed interaction.
Human + AI: AI assistance was declared or detected by an integration that can observe it.
Agent: automated or agent-origin traffic, backed by verifiable identity or a carefully qualified inference.
Unknown: the evidence does not support a reliable determination.

Every result also carries its basis: verified, declared, inferred or unknown. This is the part API teams value most. A request whose HTTP message signature, as defined in RFC 9421, validates against a published key is reported as verified. A client that simply names itself as an agent is reported as declared. A pattern that looks automated is reported as inferred. You never have to wonder whether a result rests on cryptography or on a heuristic. The evidence basis is part of the answer.

3. A result your code can act on

The result comes back to your application with the class, the basis and a readable evidence summary. Your code decides what to do with it. In observation mode, you simply record it. When you are ready, you route on it.

What your team gets: Detect, Understand, Route

Proof of Actor is one product with three capabilities.

Detect

Gather the actor signals your API can see and separate verified assertions from behavioural inferences. Signed agent requests, declared clients, automation signals and Unknown results are all kept distinct, so nothing is silently merged into a single score.

Understand

See which actors call which routes, how that changes over time, and what evidence sits behind each classification. The unknown rate stays visible, which tells you exactly where your coverage ends and where a stronger signal would help.

Route

Write policies per route and per risk tier: allow, adapt, challenge, review or rate-limit. Keep a structured, generous path for verified agents on read-only endpoints. Ask for stronger credentials on high-impact operations. Define an explicit fallback for Unknown and for timeouts, so your API behaves predictably whatever happens. You decide how each policy fails, open or closed, based on the cost of a mistake on that route.

Identity evidence, credentials and authorization are three different things

The most common mistake in agent-aware API design is collapsing three separate questions into one. Proof of Actor keeps them apart, and your design should too.

Identity evidence: what kind of actor is calling, and what proves it? This is what AI agent identification provides. A verified signature associates a request with a key and its published operator identifier. The IETF Web Bot Auth working group is chartered to standardize this kind of cryptographic authentication for automated clients, and its scope covers authenticating the agent rather than the end user.
Credentials: which account is responsible for this call? This is your API key, token or session, issued and managed by you.
Authorization: is this caller allowed to do this specific thing? This is your permission model.

A verified agent is not automatically an authorized agent. A valid signature does not prove that a person delegated authority to the agent, and it does not make the requested action safe. Proof of Actor gives you trustworthy context for the first question and leaves the second and third exactly where they belong: in your application. Read more on agent authorization and on what the evidence can and cannot establish on Detection & Limitations.

Unknown is a feature, not a failure

Request signing is optional, and an unsigned client can describe itself however it likes. A system that forces every request into Human or Agent will be confidently wrong some of the time, and you will not know when.

Proof of Actor reports Unknown when the evidence does not support a determination. Unknown is never converted to Human and is never treated as malicious by default. Your policy defines what Unknown means for each route: allow it on public reads, keep your existing checks on account changes, queue it for review where the stakes are high. Keeping Unknown visible is what makes your other classifications trustworthy. The guide on handling unknown traffic shows how to design for it.

Where AI agent identification fits in your stack

Proof of Actor sits alongside your existing gateway, authentication and rate limiting. It does not replace any of them. Typical placements include:

Server-side middleware in front of your route handlers, so every request is evaluated before your business logic runs.
At the edge, so signals are evaluated before requests reach your origin.
A generic HTTP integration, so any stack can send request context and receive a result with its basis.

Integrations are delivered hands-on with each founding team during onboarding, so the path matches your architecture rather than the other way round. The developer hub shows the integration paths available today. If you run tools for agents, the MCP Servers use case covers the specific patterns for tool calls.

Start in observation mode

Installing Proof of Actor does not change how your API responds. Results are recorded so your team can compare them with the outcomes you already know, see where agents actually go, measure the unknown rate on each route, and review any classification that looks wrong. Only then do you enable a policy, route by route, where the evidence supports it.

This is how you roll out AI agent identification without surprising your customers or breaking the integrations they depend on. The guide on rolling out actor-aware policies safely walks through the sequence step by step.

Join the founding developer program

Proof of Actor is in private beta with a small group of founding development teams. Selected teams can receive up to 12 months of free access, within usage limits agreed during onboarding, along with direct integration support from our engineers and real influence over what we build next.

If you operate an API and want to know who is really calling it, apply for early access. Tell us about your API, the routes you care about most, and the decisions you would make differently with actor context. We will tell you how Proof of Actor fits.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

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

How is AI agent identification different from API key authentication?

An API key tells you which account sent a request. AI agent identification tells you what kind of actor is behind the request and what evidence supports that conclusion. You need both, and they answer different questions.

Can Proof of Actor identify every AI agent that calls my API?

Proof of Actor classifies every request it sees as Human, Human + AI, Agent or Unknown, and states the basis for each result. When the evidence is not strong enough, the result is Unknown rather than a guess.

Does identifying an agent mean it is allowed to act?

No. Identification and authorization are separate. Proof of Actor gives your application context about the caller, and your own authorization rules decide what that caller may do.

Will Proof of Actor block requests to my API?

Not unless you decide it should. Every integration starts in observation mode, and enforcement only happens through policies your team writes and enables.

How do I get access?

Proof of Actor is in private beta. Apply for early access and selected founding developer teams can receive up to 12 months free within agreed usage limits.

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