The incident review you convene one morning is not about an outage. A customer's assistant, carrying valid delegated credentials, was blocked at checkout by a bot rule your security team tightened the week before, and the customer's complaint describes a product that failed. In the same meeting, someone shows that an unidentified crawler has spent a month pulling your entire documentation set through an endpoint nobody limited. Every team defends a reasonable local decision: security tightened defenses after a scraping spike, growth kept signup frictionless to court assistant referrals, support hand-approved one platform's crawler after an escalation. Then a director asks for the company's actual position on agent traffic, and the room goes quiet: the position lives in configurations owned by different teams, and no two of them agree.
This part has settled the decisions about agent users one at a time, and each one lives wherever it was made: a gateway config, an analytics segment, a pricing memo. This chapter moves them onto one signed page.
One page that states your position on agent traffic
The Agent Access Policy is the deliberate decision about how agents may use your product, made before traffic makes it for you: what visiting agents may do, how they prove who sent them, what they pay, and when the answers get reviewed.
We keep a fillable Agent Access Policy, written per product, and its sections each compress one chapter of this part into fields a team can complete in an hour. The document has a sibling: in Write the Agent Charter and ship with authority you chose you wrote down what the agents you build may do, and this policy answers the same questions about the agents other people send you.
The Charter governs the agents you ship, and the Policy governs the agents that visit. A product that runs its own agents and receives other people's holds both pages, and neither may contradict the other.
The rest of this chapter walks the page section by section.
What agents may do, and how they get in
What agents may do. The first section is a grant table: every action your product exposes to agents, with the autonomy each one gets. Some run freely (search, read, quote), some run only with confirmation (create, modify, spend), and some stay human-only whatever credentials arrive (deleting an account, changing ownership, accepting terms). This restates the storefront work from The tool interface is the storefront: design actions agents choose as policy: every listing that persuades an agent is also authority handed to a guest, and an action missing from the table is closed by default rather than undecided.
How agents authenticate. The second section lists the proof tiers you accept and what each one buys:
- Anonymous reads get public documentation at public rate limits, nothing else.
- Declared bots, identified only by a user-agent string, get courtesy (honest errors, a documented crawl policy) but no privilege, since anyone can copy a string.
- Signed agents, whose requests carry a verifiable signature from the sending platform, get real quotas and a front door.
- Delegated customer agents, presenting proof that a customer authorized them, are the only tier permitted to take actions with consequences.
The proof for consequential actions, and the limits at the door
Delegation requirements. The third section states what a consequential action demands before it runs, drawing on Delegation: check whose authority the agent carries: scopes that name the permitted actions, a spend ceiling, an expiry on every grant, and checkpoint rules that return irreversible or above-threshold actions to a human as a structured confirmation request. Write each requirement as a number or a rule a gateway can enforce, because "reasonable limits" enforces nothing.
Limits and quotas. The fourth section sets the traffic rules from Guardrails for guests: rate limits, abuse, and the malicious agent: rate limits and quotas per tier, keyed to organizations rather than to easily minted keys; refusals returned as machine-readable reasons with a retry time; and the degradation path when a budget runs out, stating what queues, what slows, and what refuses.
Injection defenses and the pricing stance
Injection and abuse defenses. The fifth section records the security floor: every call is authorized on the server against the presented grant, whatever the client says about itself; text your product serves or ingests is sanitized and labeled; and monitoring watches for probing, the scope-walking and parameter fuzzing that precede real abuse. The policy states that this floor applies to every tier, with no exception negotiated away in a sales cycle.
Pricing stance. The sixth section takes a position per wave. Reads are either free and legible, because reads feed the comparisons that become purchases, or metered under a crawl-pricing scheme if your content is itself the revenue. Actions and purchases are priced in the unit the agent consumes, usage-based or per action, at the same published price a human pays unless the page says otherwise. What stays free gets written down with a reason, because "we never got around to charging" is a default, not a stance.
The metrics to watch and the review date
Metrics to watch. The seventh section lists the instruments, each with an owner:
- Agent share of traffic, by tier: which waves have arrived and how fast the mix is moving.
- Task completion rate for agent sessions: whether your storefront and docs actually work for this user.
- The funnel from crawl to purchase: whether the reads you serve free feed revenue later.
- Block rate on legitimate delegated agents: the one to watch hardest.
The silent failure is a blocked legitimate agent: it files no ticket and reports to its customer that your product failed, so the block rate on delegated agents catches what no complaint ever will.
Review cadence. The eighth section is a date. The protocol layer this part stands on (signature schemes, agent-to-agent protocols, payment mandates) stabilized only recently and is still moving, so the policy freezes no protocol fact: names, versions, and adoption figures live in the dated Interop Ledger, and the page points there. Set the review a quarter out at most, and reopen early when a protocol you rely on changes or a metric moves.
One person signs it
The last field is a name: the person accountable for how the product treats agent traffic, the way the Inference Budget and the Security Posture each carry one. Every team in the opening scene held a defensible local position, and the signature makes one of those positions the company's. An unsigned policy is a wish; the signed page is what support checks before approving a crawler and what security checks before tightening a bot rule.
Try it now
The drill is the part's capstone: fill the whole page for one product, in no more than an hour.
Get the policy and your evidence. Print the fillable policy and gather what this part's drills produced: the wave classification, the storefront read-through, the delegation grant design, the tier limits, and the pricing verdict. Most fields are already drafted in those notes.
Fill it in one pass. Work the sections in the order this chapter walked them, holding the one-hour limit. Where your evidence gives an answer, write it as the decision. Where you have to guess, write the guess anyway, mark the section as an open question, and put a person's name next to it as its owner.
Read back the open marks. The marked sections are this part's homework: each one points at the chapter to reread and the evidence its drill produces. Scale it down: where a field depends on instrumentation you do not have yet, such as agent share or block rate, enter an order-of-magnitude estimate, mark it open, and make wiring the real number the owner's first task.
Sign it and set the date. Put a name at the bottom, set the review date, and file the page where every team that touches agent traffic can check it before changing a rule.
Chapter Summary
- The Agent Access Policy is one signed page stating how agents may use your product, decided before the traffic decides for you.
- The Charter governs the agents you ship, the Policy governs the agents that visit, and the two must not contradict each other.
- What agents may do is a grant table: open actions with their autonomy, human-only actions, and everything unlisted closed by default.
- Authentication comes in tiers (anonymous read, declared bot, signed agent, delegated customer agent), and privilege follows proof.
- Consequential actions demand scopes, spend ceilings, expiry, and human checkpoints, written as rules a gateway can enforce.
- Limits are set per tier, refusals are machine-readable, and an exhausted budget degrades predictably instead of going silent.
- The security floor applies to every tier: server-side authorization on every call, sanitized content in both directions, and monitoring for probing.
- The pricing stance takes a position per wave, including what stays free and why.
- Watch agent share, agent task completion, the crawl-to-purchase funnel, and above all the block rate on legitimate delegated agents, the metric that catches the silent failure.
- The protocol layer is still moving, so the page carries a review date, leans on the dated Interop Ledger for current facts, and carries one person's signature.
That closes When Your Users Are Agents. You met the three waves, built the storefront, verified the authority, set the limits, and priced the visit. The fillable Agent Access Policy and the dated Interop Ledger leave with you, ready for the next product that needs a position on agent traffic.
Sources
- Cloudflare (2025). Web Bot Auth and signed agents documentation for verifying automated traffic (last verified July 2026).
- Cloudflare (2025). Pay Per Crawl announcement and documentation.
- OpenAI and Stripe (2025). Agentic Commerce Protocol specification and merchant documentation (last verified July 2026).
- Google (2025). Agent Payments Protocol specification and mandate documentation (last verified July 2026).
- Anthropic (2025). Model Context Protocol specification, authorization and security guidance (last verified July 2026).