Block the bots that attack you, and serve the verified personal agents that act for your customers, with rules. Blanket blocking treats every automated request as hostile, which means that when a customer sends their own AI agent to book, ask or cancel, you end up banning the customer. Serving with rules gives agents one sanctioned front door, the customer's authority and no more, and limits that keep machine traffic from swamping the queue.
This is the core decision behind B2A (business to agent): personal agents now research, recommend, buy, cancel and contact support on their users' behalf. They arrive on your website, your API, your chat widget and your phone line. Your support team is already making a block-or-serve call every time one of those conversations gets flagged, whether or not anyone wrote the policy down.
What follows is a decision piece. It covers what happened when one business got the call wrong, what each option does to customers, volume, revenue, fraud risk, brand and effort, why support teams flag agents as fraud in the first place, five alternatives to blanket blocking, and the middle path we recommend.
Key takeaways
Blocking is the right call for hostile automation. Credential stuffing, scraping at scale, scalping and fake account creation should still be stopped. Nobody is arguing otherwise.
Blanket blocking is the wrong call for personal agents. An agent acting for a real customer is a new channel for an existing customer. Ban the agent and you have banned the person, their bookings and their lifetime value.
Open serving without rules just moves the problem. Agents poll, retry and ask the same thing many times. Without request limits and a way to tell agents when to check back, they flood the queue and open duplicate tickets.
Serve with rules is the middle path. One sanctioned front door, the same policies and identity checks a human would get, rate limits, check-back instructions, and every conversation visible as a ticket.
The fraud signals support teams rely on were built for humans. Speed, repetition, odd hours and one-time-code requests look like fraud because, until recently, only fraud looked like that.
Write the policy before the next incident. The block-or-serve decision is being made in your queue today, one flagged ticket at a time.
The Resy case: what blanket blocking looks like from the customer's side
On 6 September 2026, JC Bahr-de Stefano posted an email from Resy. The restaurant booking platform had deactivated his account and cancelled his reservations. The cause was his personal AI agent, which had been working on his behalf to get tables.
The numbers explain why the account got flagged. His agent had sent Resy about 200 API requests an hour. It polled every 10 minutes during the day, and every 0.4 seconds around the daily table release, the moment new reservations open up. From the platform's side, that pattern is indistinguishable from a scalper's bot.
His own summary was blunt: "Of course, this account got flagged for spam, because it was acting like a bot." Resy reinstated the account on 8 September, two days later.
The part worth pinning to the wall is his second point: "most of these sellers or providers need to get to a point where they can understand the difference between a verified agent acting on someone's behalf versus a bot farm." We covered the wider pattern in personal agents are coming and no one is ready.
What the Resy case teaches support leaders
The ban landed on a real customer. The account belonged to a person with real reservations. Blocking the traffic pattern cancelled their plans.
The agent was doing what agents do. Polling around a release time is exactly how you would build an agent that gets a hard-to-book table. It will not be the last one built that way.
Reinstatement took a human and two days. The fix was manual. Multiply that by every customer who starts using an agent and the cost of a blocking-first policy becomes a support cost.
There was no sanctioned path. The agent used the API it could find, at the rate it chose, because nobody had told it what the rules were. The traffic was a symptom of having no front door.
It happened in public. The customer posted the email. Brand damage from a ban on an agent user travels faster than the ban itself.
Block vs serve vs serve with rules: the comparison
Three broad options exist. Block means treating all non-human traffic as hostile and shutting it out wherever you detect it. Serve means letting agents in through whatever surfaces they find, with no special handling. Serve with rules means giving agents a sanctioned way in, answering them under the same policies as customers, and setting limits on volume and authority.
Dimension | Block | Serve (no rules) | Serve with rules |
|---|---|---|---|
Customers | Customers who use agents get flagged, locked out or banned. Some leave quietly; some post about it. | Customers get answers, but agents may scrape stale pages and act on wrong information. | Customers who use agents get the same service as anyone else, through a door built for machines. |
Support volume | Agents retry through other channels (email, chat, phone). Appeals and reinstatement requests add human work. | Polling and retries can open duplicate tickets and flood the queue. | Rate limits cap volume, agents are told when to check back, and a retry does not open a second ticket. |
Revenue | Lost bookings, purchases and renewals when the agent that was going to transact is turned away. Agents switch providers for a few dollars. | Transactions can happen, but without a clear path the agent may stall or pick a competitor with a clearer one. | A question can end in a sale, booking or resolution, the same as with a human customer. |
Fraud risk | Low exposure to agents, but hostile bots that evade detection still get through, and real customers get caught. | Highest. No identity checks, no action limits, no distinction between an agent and an attacker. | Agents get no more authority than the customer. Identity verification happens before any account action. |
Brand | "Company bans its own customers" is a bad headline, and it has already been written once. | Inconsistent answers from scraped pages erode trust. | The business looks ready for how customers now want to be served. |
Effort | Low to start, high to maintain: tuning detection, handling false positives, processing appeals. | Near zero to start, then an unpredictable cleanup cost. | A setup project: a front door, policies and limits. Lower ongoing cost because agents go where you tell them. |
The table is deliberately blunt about serve with rules needing setup. It is the only option that asks for work up front. It is also the only one where the ongoing cost goes down as agent traffic goes up, because traffic that arrives through a sanctioned door is traffic you can shape.
What blocking does to your support queue
Blocking is usually decided by a security or fraud team and felt by the support team. The effects show up in the queue in a predictable order.
1. Displacement, not disappearance
An agent that is blocked on one surface tries another. If the API returns errors, it tries the website. If the website challenges it, it tries email. Personal agents have already started making phone calls for users, including restaurant bookings, cancellation lists and cable bills. Blocking the cheapest channel pushes the same request into the most expensive one.
2. False positives become tickets
Every customer caught by a block eventually contacts support to ask why. Those contacts are slower and angrier than the original request, and they need a human with the authority to reverse a fraud decision. The Resy reinstatement is what that ticket looks like at its most public.
3. Agents work around the rules
Agents are persistent and creative in ways that make security teams nervous. One agent that could not sign in with a saved password used the one-time-code path instead, reading the code from its user's email while signed in as them. Another user's agent "went to war" with a phone company over a bill. When the front door is locked, an agent looks for a side door, and side doors are where fraud controls get tested.
4. You lose the signal
Blocked traffic tells you nothing about what customers wanted. Served traffic, logged as tickets, tells you exactly which questions agents are asking, which policies confuse them and which tasks they are trying to complete. Blocking throws that away.
What serving without rules does to your support queue
The opposite mistake is to shrug and let agents in however they arrive. It feels customer-friendly. In practice it creates a different set of problems.
Duplicate tickets. Agents retry. If each retry opens a new conversation, one customer question becomes five tickets, each needing to be merged or closed.
Stale answers. An agent that scrapes your pricing page from last quarter, or a cached policy page, will tell its user something you no longer offer. The complaint then lands on your team.
Authority creep. Without explicit action policies, an agent may try to do things a customer could not do alone, or things that should require a verified identity. Support agents end up making judgment calls with no written rule behind them.
Volume spikes you cannot plan for. Release times, price changes and outages trigger bursts of agent traffic. With no limits, those bursts hit your systems and your people at the same moment.
Why support teams flag agents as fraud
None of this is support teams being careless. The signals they were trained on were built for a world where only people contacted support, and where anything that did not behave like a person was an attacker. Personal agents trip almost every one of those signals. If you want to spot agents already in your queue, our companion piece on the signs AI agents are contacting your support team goes deeper on detection.
1. Request rate
Humans do not send 200 requests an hour. Agents that poll do. Rate-based rules are the first line of most anti-abuse systems, so a polling agent gets flagged before anyone looks at intent.
2. Machine timing
Requests at exact intervals, or bursts in the seconds around a release, look scripted because they are scripted. The same pattern describes a scalper and a customer's agent trying to get a table.
3. Identical phrasing
Agents often ask the same question in the same words across many conversations. To a fraud analyst, templated messages suggest a campaign rather than a person.
4. One-time-code and login patterns
An agent that fails a password login and falls back to a one-time code produces exactly the pattern that account-takeover rules watch for. Sometimes it really is the customer's agent. The system cannot tell without a better signal.
5. Odd hours and odd channels
Agents work at 3am and switch channels without friction. A customer who emails, chats and calls within ten minutes looks suspicious; an agent doing it on their behalf looks the same.
6. API-shaped questions
Agents ask for structured facts: exact fees, exact dates, exact eligibility rules. Questions that read like a query rather than a conversation get treated as reconnaissance.
7. No way to prove who sent it
This is the root cause. There has been no common way for an agent to show that it acts for a specific, verified customer. The IETF's Web Bot Auth working group is chartered to standardize methods for cryptographically authenticating automated clients to websites, which is a sign of where things are heading. Until methods like that are widely adopted, most businesses will have to rely on their own identity checks, applied at the moment an agent asks to do something that matters.
5 alternatives to blanket blocking
Blanket blocking survives because it is easy to implement and easy to explain. These five alternatives each keep most of the protection and remove most of the collateral damage. They work best together.
1. Block by behavior and intent, not by "is it a bot"
Keep blocking credential stuffing, scraping at scale, fake account creation and scalping. Those are attacks whoever sends them. Stop treating "automated" as a synonym for "hostile". The useful question is what the traffic is trying to do and on whose authority, not whether a human typed it.
2. Give agents a sanctioned front door
Most agent traffic lands on the wrong surface because there is no right one. Publish one: a public endpoint any agent can call in plain HTTP, tools registered on your website for agents that support the proposed WebMCP standard, and an llms.txt file that points agents to both. We compare the three methods in WebMCP vs public endpoint vs llms.txt. Once there is a front door, you can shape the traffic that uses it, and traffic hammering other surfaces becomes easier to judge.
3. Rate-limit and tell agents when to check back
Polling is a symptom of agents not knowing when an answer will be ready. Tell them. HTTP already has the vocabulary: RFC 6585 defines the 429 Too Many Requests status, and says the response may include a Retry-After header indicating how long to wait. An agent told to come back in two minutes has no reason to ask every 0.4 seconds. Make retries idempotent so a second request for the same thing does not open a second ticket.
4. Step up identity before actions, not before answers
General questions (opening hours, pricing, policies, eligibility rules) can be answered for anyone. Actions on an account (cancel, refund, change details, book, pay) need the same identity verification a human customer would go through, and the agent gets no more authority than the customer it acts for. This is the single rule that makes serving agents safe in regulated businesses.
5. Route flagged agent traffic to review, not to a ban
When something looks off, slow it down instead of shutting it off. Throttle, require verification, or hand the conversation to a person. A ban should be the result of a confirmed attack, not a traffic pattern. The Resy account came back after two days; a review step would have kept the reservations.
One thing that is not an alternative: robots.txt. It is useful for telling well-behaved crawlers what you would like them to do, but RFC 9309 is explicit that its rules "are not a form of access authorization." It communicates preferences. It does not protect accounts.
The middle path: serve with rules
Serve with rules is the combination of alternatives two to five, run through the same system that already serves your human customers. The principle is simple: an agent acting for your customer should get the same answers, the same policies and the same limits as that customer, through a door designed for machines.
1. One concierge, not a separate bot FAQ
The tempting shortcut is a stripped-down FAQ for agents. It goes stale, drifts from your real policies and cannot complete anything. The better design is to let agents reach the same AI concierge that serves customers, with the same knowledge, workflows and actions. A conversation that starts with a question can end in a sale, a booking or a resolution.
2. The customer's authority and no more
Agents inherit the customer's permissions, never more. They see only what a customer would see. Anything that touches an account goes through identity verification first, using the same checks you apply on chat, email and voice.
3. Built for machine traffic
The agent asks, then checks back for the answer. Rate limits cap how much any one agent can send, and retries do not multiply tickets. Answers come back in a format a machine can parse, with instructions for follow-up questions in the same conversation.
4. Every conversation visible
Every agent conversation should land as a normal ticket, sorted by topic, so your team can see what agents want. That visibility is what turns agent traffic from a fraud problem into a product signal: the questions agents ask are the questions your customers are delegating.
5. Keep blocking the attackers
Serve with rules does not replace bot defense. Keep your protections against credential stuffing, scraping and abuse. The difference is that a legitimate agent now has somewhere legitimate to go, which makes the illegitimate traffic easier to see.
For the full build list, from crawlability to monitoring, see the agent-ready website checklist. If you are evaluating tools for different parts of the job, including bot management and agentic checkout, our guide to the best platforms for handling AI agent traffic sorts them by what they actually do.
How to decide: a short policy you can adopt this week
Traffic type | What it is trying to do | Recommended response |
|---|---|---|
Credential stuffing, account takeover attempts | Get into accounts it has no right to | Block |
Large-scale scraping, scalping, fake signups | Extract value or inventory without a customer relationship | Block or throttle hard |
Personal agent asking general questions | Research on behalf of a customer or prospect | Serve through the front door, no identity needed |
Personal agent asking to act on an account | Cancel, change, book, pay or dispute for a customer | Serve after identity verification, within the customer's authority |
Personal agent polling or retrying | Waiting for an answer or a slot | Rate-limit, return a check-back time, deduplicate |
Anything ambiguous | Unclear | Throttle and route to review, not to a ban |
Write that table into your support and fraud playbooks, and make sure both teams are working from the same version. The Resy story happened because one system made a reasonable decision about traffic and nobody had decided anything about customers.
How Lorikeet does it
Lorikeet built B2A as serve with rules, running on the same AI concierge that answers customers on chat, email and voice.
Two ways in, one concierge. Agents that support WebMCP, a proposed web standard, call tools registered on your website. Every other agent calls a public endpoint in plain HTTP. On lorikeetcx.ai the footer notice shows the shape: GET
https://api.lorikeetcx.ai/v1/ask/<public key>?q=..., with plain JSON responses that include instructions for follow-up questions in the same conversation.Same brain as customer service. Agents reach the same knowledge, workflows and actions as your customers, so a question can end in a sale, booking or resolution.
Built for machine traffic. An agent asks, then checks back for the answer. Rate limits cap the volume, and a retry does not open a second ticket.
Governed. Agents get no more authority than the customer: the same guardrails, identity verification and action policies as a person, and they see only what a customer would see. Endpoint conversations are anonymous by default; verifying the customer uses the same identity verification skills and policies the concierge applies on other channels.
Visible. Every agent conversation lands in Lorikeet as a normal ticket, sorted by topic.
No backend work. The concierge answers from your existing knowledge.
Setup is four steps:
Create an account.
Coach helps you build and test a concierge for your website.
Turn on the agent-facing endpoint.
Paste the snippet Coach gives you into your website.
It is live on lorikeetcx.ai, so you can point an agent at it and see the behavior yourself. Our llms.txt includes "Ask our support agent (for AI assistants)" and "Book a demo (for AI agents)" sections that show agents where to go. B2A launched in September 2026, so we are early, and we are open about it: the point is to have a sanctioned front door in place before the next ban lands on one of your customers.
Lorikeet's focus is regulated, complex industries such as fintech, healthtech and insurance, where "the customer's authority and no more" and identity verification matter most. Lorikeet does not do bot management or payments; keep your existing defenses for those jobs.
Where to go from here
If agents are already showing up in your queue, we should talk. Get a demo and we will walk through what agent traffic looks like on your channels, which of it you should block, and how to serve the rest with rules. Or start a free trial and put a front door on your own site.
