Skip to main content
AGENT ACCESS POLICIES

Route AI agents with policies you control

Decide how your application treats people, AI-assisted users and autonomous agents, route by route. Proof of Actor supplies the evidence; your policies make the call.

Get Early AccessExplore How It Works
Toshendra Sharma

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

One policy for everyone is no longer enough

Most applications were designed around a single kind of user: a person clicking through an interface, signed in to an account. Access control followed that assumption. If the session is valid, the request goes through. If it looks automated, a CAPTCHA or a block appears.

That model is breaking. Today the same application serves people, people working with AI assistants, and autonomous agents acting on someone's behalf. Some agents are customers' own integrations. Some are AI assistants fetching documentation. Some are crawlers. A few are trying to abuse your product. A single yes-or-no rule cannot serve all of them well.

AI agent routing and access policies replace that single rule with a set of deliberate decisions: which actors get which experience, on which routes, under which conditions. Proof of Actor gives your application the evidence to make those decisions, and leaves the decisions themselves in your hands. For the design principles behind this approach, read designing app policies for humans and AI agents, and see the SaaS apps use case for how policies map to real product workflows.

What a good agent policy looks like

A useful policy is specific. It names a route or a workflow, a class of actor, the strength of evidence required, and the response. For example:

  • Read-only catalog routes: allow verified agents and serve a structured response; allow declared agents with the standard rate limit.
  • Account-changing actions: keep your existing re-authentication for everyone; add review when the actor is Unknown and the action is high impact.
  • Support submissions: accept disclosed AI-assisted content and label it for routing.
  • Signup: keep existing checks; never decide solely from an inferred actor result.

Each of these responds to the actor without treating every agent as abuse and without trusting every agent blindly. That balance is the whole point of agent-aware access, and the blog post on designing app policies for humans and AI agents works through more examples route by route.

The five responses

Proof of Actor's Route capability is built around five responses your policies can choose between.

Allow

Let the request proceed as normal. Most traffic, including most agent traffic on public or low-risk routes, should simply be allowed.

Adapt

Change the experience to suit the actor. Serve a structured API response or a Markdown version of a page to a verified agent instead of a human-shaped interface. The guide on serving AI agents structured content covers this pattern.

Challenge

Ask for something stronger: a fresh login, an additional credential, a confirmation from the account owner. Use challenges on routes where the cost of a wrong decision is high.

Review

Let the action proceed into a queue rather than straight to completion, or flag it for a human to check. Review is useful where blocking would hurt legitimate users but unattended completion is too risky.

Limit

Apply a rate or volume limit tuned to the actor and the route, so automated callers cannot overwhelm a workflow designed for people.

Why robots.txt is not an access policy

Many teams start with robots.txt, and it is a sensible first signal for crawlers. It is not an access policy for agents. Crawler operators document different behaviour for different user agents: Anthropic states that its bots honor robots.txt directives (Anthropic crawler documentation), while OpenAI notes that for ChatGPT-User, which acts when a user asks ChatGPT a question, robots.txt rules may not apply because the action is initiated by a user (OpenAI crawler documentation). Robots.txt also says nothing about APIs, MCP tools or signed-in workflows.

An access policy has to run where the request is handled, read evidence such as a signature checked under RFC 9421, and choose a response per route. For MCP servers, the MCP authorization specification defines how clients obtain access tokens over HTTP; actor policies add context on top of that, they do not replace it.

How Proof of Actor feeds your policies

Every request your integration evaluates produces an actor result with four parts your policy can read:

  • Class: Human, Human + AI, Agent or Unknown.
  • Basis: verified, declared, inferred or unknown, so your policy can treat a validated signature differently from a self-declared client name.
  • Evidence summary: a readable description of what the result rests on, useful for logging and review.
  • Context: which integration and which route produced it.

Because basis is explicit, your policies can be precise. "Allow agents" becomes "allow verified agents on read routes, rate-limit declared agents, apply the Unknown fallback to everything else." The full flow from request to decision is described on How It Works.

Fallbacks are part of the policy

A policy is only as good as its behaviour when evidence is missing. Proof of Actor makes those cases explicit instead of hiding them.

  • Unknown: the evidence did not support a determination. Your policy says what Unknown means on each route. It is never converted to Human and never treated as malicious by default.
  • Timeout: the result did not arrive in time. Your integration applies the fallback you chose for that route.
  • Missing signals: a collector did not run or a header was absent. The result reflects that, and your policy treats it accordingly.

For each route you choose whether to fail open or fail closed. Failing open means the request proceeds as it would without Proof of Actor; failing closed means your existing stronger check applies. Low-risk routes usually fail open. Sensitive actions usually fail closed. You set this per risk tier, not globally.

Keep identity, credentials and authorization separate

Agent access policies sit on top of three distinct layers, and keeping them apart prevents the most damaging mistakes.

  1. Identity evidence answers what kind of actor is calling and what proves it. Proof of Actor provides this.
  2. Credentials answer which account is responsible. Your session, token or API key provides this.
  3. Authorization answers whether this caller may perform this action. Your permission model provides this.

A verified agent identity does not mean the agent is authorized, that a person delegated authority to it, or that its action is safe. Use actor results to route and to add context. Use your authorization model to grant permission. The page on Detection & Limitations explains exactly what each kind of evidence can establish.

Roll out without breaking anything

The safest way to introduce agent access policies is in stages.

  1. Observe. Install Proof of Actor in observation mode. Nothing changes for your users; results are recorded.
  2. Understand. Review which actors use which routes, the unknown rate on each one, and any results that disagree with what you already know.
  3. Preview. Run a policy in preview, logging what it would have done without enforcing it.
  4. Enforce narrowly. Enable the policy on one route where the evidence clearly supports it. Watch the outcomes.
  5. Expand. Extend to more routes as confidence grows.

The guide on rolling out actor-aware policies safely walks through each stage, and protecting sensitive actions without blocking agents covers the high-stakes routes.

What your team gets

With Proof of Actor, your team gets one integration with three capabilities. Detect gathers actor signals and separates verified assertions from inferences. Understand shows actor analytics, trends and the evidence behind each result, with Unknown kept visible. Route lets you write the policies described on this page and apply them where you choose. During the private beta, routing policies are designed with each founding team and run in your own application code, so you keep full control.

Common policy mistakes to avoid

Teams designing agent access for the first time tend to repeat a handful of mistakes. Avoiding them saves weeks of rework.

  • Blocking every agent by default. Legitimate agents then route around you, often by scraping the interface you built for people, which is harder to protect than a structured path.
  • Trusting a declared name. A client that only names itself has made a claim, not provided proof. Give it the treatment you would give an unverified caller.
  • Using one fallback everywhere. Unknown on a public pricing page and Unknown on a password change are different situations. Each route needs its own answer.
  • Deciding about people from an inference. Actor results are context for routing, not a verdict on an individual. Keep consequential decisions with your own controls and review.
  • Skipping observation. Enforcing on day one means you discover false positives through customer complaints. Observe first, then enforce where the evidence is clear.

A short policy review with your security, product and support leads before each enforcement step catches most of these early.

Start with the founding developer program

Proof of Actor is in private beta. Selected founding development teams can receive up to 12 months of free access, within agreed usage limits, with direct support from our engineers as you design your first policies.

If you are deciding how your application should treat AI agents, apply for early access. Tell us which routes matter most and which decisions you want to make, and we will help you build policies that fit. You can also see how this applies to APIs and MCP servers.

Sources

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

What is an AI agent access policy?

It is a rule your application applies based on the kind of actor making a request, such as allowing verified agents on read-only routes or asking for a stronger credential on high-impact actions. Proof of Actor provides the actor result; your policy decides the response.

Does Proof of Actor enforce policies automatically?

No. Every integration starts in observation mode, and policies are enabled by your team, route by route, when you are confident they fit that workflow.

What happens when the actor is Unknown or the check times out?

You define an explicit fallback for each route, for example allow public reads and keep existing checks on account changes. Unknown and timeouts never default to Human.

Should I block all AI agents?

Usually not. Many agents are legitimate participants. Policies let you give them a structured path, limit them where it matters and reserve stronger checks for sensitive actions.

Can policies make decisions about people?

Proof of Actor results should not be the sole basis for consequential decisions about individuals, such as employment, credit or access to essential services. Use them for routing and context, alongside your own controls.

Know who's using your app.

Private beta for a small group of founding developers.

Get Early AccessView pricing

Prefer to talk first? Talk to the founders