AI Agent Permissions for Websites: What a Site Should Let Bots Do

What Should a Website Let AI Agents Do?

Allow public reading and search freely, require sign-in and narrow scopes for personal data, require confirmation for changes, and require a human decision for payments and anything irreversible. The dividing line is risk to the customer and to you, not whether the client is software.

Agents already act on sites. Some browse for people, some fill forms and some complete purchases. Waiting for a universal standard is not a plan, because your logs are being written today. A permission model gives you a consistent answer to "may an agent do this?" for every action on your site.

Four Tiers of Action Risk

Every action on your site fits into one of the four tiers. If you are unsure, move it up a tier. Cheap errors in tier one, such as reading a page twice, cost almost nothing. Errors in tier four can cost customers money and cost you refunds, disputes and reputation.

Public Reading and Search

For public content, the main issue is load, not authority. Publish a sitemap, keep pages fast and apply rate limits so no one client can drain capacity, as described in AI crawler rate limiting explained. Decide separately how you feel about training use, and say so in robots.txt and your machine-readable policies. Remember the difference between a crawler that collects content for an index and an agent acting on a user's request. Operators such as OpenAI, Anthropic and Google describe these as separate user agents, and Google says its user-triggered fetchers generally ignore robots.txt because a person asked for the fetch. That is why robots.txt alone is never your access control.

Signed-In Access and Changes

When an agent works on behalf of a logged-in customer, the risk is whose authority it uses. The worst pattern is giving the agent the customer's password or a full-power session cookie. If it is compromised, or simply confused by malicious page content, it can do anything the customer can do.

Better patterns limit both scope and time.

• Delegated authorization. Let the customer grant an agent specific abilities through a consent screen, using something like OAuth, with clear scope names such as orders:read or cart:write.
• Short-lived, revocable tokens. Expire access quickly and let customers see and revoke it in their account settings.
• Separate credentials per agent. If one integration misbehaves, you can cut it off without touching others.
• Idempotency keys. If an agent retries a submit, you create one record, not two.
• Clear responses. Return structured, specific results so the agent, and the customer reading its summary, know what happened.

The principle behind all of this is least privilege, which our article on why AI agents need the principle of least privilege explains in more depth.

Money and Irreversible Actions

For payments, deletions and other hard-to-undo actions, insist on a human decision. Practical designs include:

1. Review-and-confirm step. The agent gets the customer to the final summary, and the customer approves with a wallet payment, passkey or one-time code.
2. Step-up verification. Ask for an extra proof for high-value changes such as a new payout account, even inside an authenticated session.
3. Spending limits. Cap the amount an agent may authorize without additional approval.
4. Cooling-off delays. For account deletion or email changes, send a confirmation and wait.
5. Visible undo where possible. Give a short window to cancel an order.

Card networks and payment providers have announced programs for agent-initiated payments, and early protocols such as the Agentic Commerce Protocol exist, so this area is changing. A safe default remains a human in the loop until the risks and liability rules are clearer. See how to build an agent-friendly checkout page for the design side.

Protecting Agents From Your Own Pages

Permissions also run in the other direction. Agents read whatever is on your page, including text a visitor could plant. User-generated content such as reviews, comments and profile fields can contain instructions written to hijack an assistant, a technique often called indirect prompt injection. If your site lets customers post text that other people's agents may read, you have a shared responsibility to reduce harm.

• Sanitize and moderate user-generated content, and strip hidden text and invisible characters.
• Keep instructions about how your site works separate from user content in the page structure.
• Never put secrets, tokens or internal notes in HTML comments or hidden elements.
• Watch for reports from customers that an assistant behaved strangely on your pages.

For an accessible explanation of the attack, see how AI agents can be tricked by hidden instructions, and for a broader view of what agents should never be given, AI agent permissions: the most dangerous access to give an AI.

Knowing Who Is Asking

A permission model works better when you know who the client is. Signals improve in three ways. User agent strings are easy to fake but still useful for classification. Published IP ranges and reverse DNS let you verify some large operators. Cryptographic signing of requests, an approach known as Web Bot Auth that Cloudflare and Google have both experimented with, lets a site verify an agent without trusting a header. Support is uneven, so use identity to relax limits for verified clients, not to trust unverified ones. The guide on separating human visitors from AI agent traffic shows how to handle the mixed picture.

A Permission Matrix for a Small Online Bookstore

Applying the tiers to a concrete shop makes them easier to picture. Take a bookstore with public product pages, customer accounts and a standard checkout. The details are illustrative.

Viewing books, reading descriptions and using the public search box sit in tier one. They are open to any client with a rate limit per address. Viewing a customer's order history or saved shipping address is tier two. It requires sign-in, and if an assistant wants access on the customer's behalf it must come through a consent screen granting an orders:read scope that the customer can revoke.

Adding a book to the cart or joining a mailing list is tier three. The session must be authenticated or tied to a cart cookie, submissions must be idempotent so repeated clicks do not create duplicates, and the response must say plainly what changed. Placing the order is tier four: the agent may prepare it, but the customer approves the final summary with a wallet payment or passkey. Changing the account email or the stored card is also tier four, with a confirmation message to the previous email address.

Once this matrix exists on paper, engineering can implement it, support can explain it and legal can review it. It also gives you a ready answer if an agent vendor asks what your site permits.

Prepare for Misbehaving Agents

Even a careful model will meet a client that misbehaves. Have a simple plan before it happens. Decide who can approve an emergency block, and make sure they can apply it at the CDN or firewall quickly. Keep enough logs to answer three questions: who was the client, what did it do and which accounts were affected. Write a short customer-facing message for cases where an agent placed a wrong order, and make refunds for clear agent errors easy. Afterward, review whether the permission tier for that action was right. Incidents are the cheapest source of information about where your model is too loose or too strict, and each one should leave the policy slightly better.

A Permission Policy in Eight Steps

1. List every action your site allows, from browsing to account deletion.
2. Assign each a tier using the risk table above.
3. Decide the control for each tier: rate limit, sign-in, scoped token or human confirmation.
4. Implement server-side. Enforce rules where the request lands, not in front-end scripts.
5. Build consent and revocation screens for delegated access.
6. Add logging. Record client identity, action, time and account for tiers two to four.
7. Publish a short agent policy page in plain language, and link it from your footer.
8. Review quarterly, and after any incident, adjust the tiers and limits.

Frequently Asked Questions