Agent or Scalper: How Ticketing Platforms Tell AI Shopping Agents From Scalper Bots

Picture the first minute of a high-demand on-sale. One request asks for a ticket on behalf of a fan who asked an AI agent to buy it. The other comes from a broker's script, one of many copies, each asking for the posted maximum. To the systems guarding the on-sale, the two requests look nearly identical: automated, fast, and with no person clicking anything. What separates them is what the platform can verify about each one: which company runs the agent, and how many tickets the buyer behind it already holds.

Agentic commerce is changing how fans look for tickets, but it hasn't made ticket scalping any less of a threat, and it makes scalper bots harder to pick out. Ticketmaster, StubHub, and SeatGeek have all opened their catalogues to AI assistants, so the automated traffic reaching an on-sale now includes AI shopping agents a platform may actually want to serve. Telling the two apart has become a product decision, a security decision, and – after a federal court ruling this fall – a legal question as well.

We come to this from both the access side and the AI side. Softjourn has built ticketing software since 2005, including more than 20 access control applications for ticketing clients, so on-sales, queues, and purchase limits are familiar ground for our teams. More recently, our R&D team spent several months studying how AI assistants reach ticketing platforms and built the key pieces in a test environment, from signature checks to per-person limits. We now develop MCP servers that open a platform's catalogue to assistants on the platform's own terms.

This article looks at why traditional bot defenses struggle to separate a legitimate AI shopping agent from a scalper bot, what the newest identity standards can and can't prove, where per-person purchase limits fit, and what the BOTS Act means for a platform that lets agents in.

For more on why every major ticketing platform still sends buyers to its own checkout, read our article on agentic commerce in ticketing.

From "Is This a Human?" to "Whose Agent Is This?"

Most bot defenses on a ticketing platform are built to answer one question: is a person on the other end of this request? Mouse movement, browser fingerprints, CAPTCHAs, and waiting-room behavior all feed that answer. An AI shopping agent fails every one of those tests, because no person is clicking anything in the moment it acts, even though a fan sent it.

That leaves the platform with two poor options. If it keeps those defenses on, the agent a fan sent gets challenged or blocked like any other script. If it switches them off for agent traffic, the broker's script walks through the same opening.

The approach taking shape across bot vendors, card networks, and standards groups changes the question. Instead of asking whether a human is present, the platform asks whose agent this is and what it has been allowed to do. That question breaks down into four smaller ones, and an agent's signature and credentials can answer each of them.

Four Questions an Agent's Credentials Can Answer

1. Which operator sent it: Under Web Bot Auth, the agent signs each request, and the platform checks the signature against a public key the operator publishes. A valid signature names the company running the agent. Visa's Trusted Agent Protocol uses the same signature approach for agents shopping with Visa cards.
2. Whether it is browsing or paying: Visa's protocol tags each signed request as browsing or as payment (Cloudflare, 2025), so a platform can treat a request to look at seats differently from one trying to pay.
3. On whose behalf: Account linking ties the agent to a buyer who signed in to the platform and approved the connection. In Google's Agent Payments Protocol (AP2), the buyer signs a mandate that Google describes as "verifiable proof of a user's instructions" (Google Cloud, 2025).
4. Up to how much: An AP2 mandate can set "price limits, timing, and other conditions" before the agent acts on its own. A spending allowance attached to a linked account does the same job.

A platform that can answer all four knows a great deal about a request. It still doesn't know the one thing a scalper is counting on it not knowing.

The Question No Protocol Answers

The fifth question is the one that matters most in an on-sale: how many tickets has this person already bought, across every channel the platform sells through?

None of the protocols carry that answer. The IETF working group developing Web Bot Auth lists "authenticating the end user of a participating client or agent" and "tracking or assigning reputation to particular bots" as out of scope (IETF Web Bot Auth charter). A signature can confirm that OpenAI's agent sent a request, but it can't say whether the fan behind it has already bought tickets on the website, in the app, or through a different assistant.

The answer sits in the platform's own records, which means it's only as reliable as the identity it's tied to. A limit counted per account can be beaten by anyone willing to open more accounts, and a guest checkout has no identity to count against until payment.

Two working rules follow from our R&D work:

• An unsigned automated agent gets treated as a scalper bot: Without a signature, the platform has no technical way to confirm who sent the request or why.
• A valid signature never overrides a failed limit: Knowing which company runs an agent says nothing about how many tickets the buyer behind it already holds.

That makes the per-person limit the platform's job, whatever an agent can prove about itself.

What Web Bot Auth Proves and Where It Stops

Web Bot Auth works a lot like a signed letter. The company that runs an agent publishes a public key at a fixed address on its website, and its agent signs each request it sends. The platform reads the signature, fetches the key, and checks that the two match. If they do, the request really came from that company's agent.

The approach has moved quickly from proposal toward standard. The IETF chartered a working group to standardize it on October 23, 2025 (IETF, 2025), and Cloudflare already verifies these signatures (Cloudflare, 2026) for sites on its network. Cloudflare recommends that each signature expire quickly as protection against replay, noting that "a minute is often sufficient."

A valid signature is useful, but its reach is narrow, and the limits matter most at an on-sale.

Those answers come from other checks. Account linking or an AP2 mandate identifies the fan and records their approval, and only the platform's own records can answer the purchase-limit question.

How SeatGeek Verifies ChatGPT's Agent

SeatGeek is the one ticketing platform we found that has described its setup in public. Its engineers explained the reason plainly: without verification, "anyone could impersonate the ChatGPT Agent by crafting requests that look correct" (SeatGeek ChairNerd, 2025).

The team first looked at checking signatures at its content delivery network, the layer that sees every request before SeatGeek's own servers do. That layer "currently doesn't support Ed25519, the signing algorithm used by ChatGPT Agent." Rather than rebuild the check on a different edge product, the team moved it one step closer to its servers, to the API gateway, where the algorithm was already supported.

The check added between 600 and 900 microseconds to each ChatGPT request, roughly 3% of average gateway latency (SeatGeek ChairNerd, 2025).

Fans buying on the website never see that cost, because verification runs only when a request carries the signature headers. For production, SeatGeek said it "will adopt a 'fail-closed' security posture," rejecting any request whose signature can't be verified.

Setting Agent Access Stage by Stage

A ticket purchase is a chain of separate decisions, and agent access can follow the same chain. The early stages, where a fan asks what's on and which seats are left, carry little risk and a lot of value, because an assistant that answers them accurately sends better-informed buyers to the platform. The later stages, where seats are claimed and paid for, are where a scalper's script does its damage. A single policy for the whole chain forces a platform to be too open or too closed at every step.

The policy we'd recommend, stage by stage:

1. Discovery and availability: Open to signed agents, with rate limits at the edge so no single operator can flood the catalogue.
2. Seat selection: Open to signed agents, with session checks so each selection belongs to the conversation that made it.
3. Seat hold: Allowed for a signed agent acting for a signed-in buyer, or for a guest cart whose identity is captured at checkout, and only while the per-person limit has room.
4. Checkout and payment: Require a valid signature, a linked buyer identity, verified purchase authorization, and a purchase-limit check that includes existing holds and completed orders.

Our test build ran a simpler version: holds required a signed-in customer or a guest cart plus room under the per-person limit, while signature verification ran at the gateway to identify the operator.

The line between selection and hold matters most. Everything before it can be scaled and rate-limited like a public website. Everything after it takes inventory out of circulation, even if only for a few minutes, so the platform needs to know whose limit a hold counts against before an agent crosses it.

Setting access by stage has a practical cost: the platform has to know which stage each request belongs to. That's straightforward when an agent comes in through an MCP server or API built for the purpose, and much harder when the agent drives the same web pages a fan uses. An official connector gives the platform a front door it can watch, which makes it as much a security argument as a marketing one.

Our guide to what an MCP server is explains how that front door works.

Per-Person Limits Are the Platform's Job

A purchase limit is the rule a scalper is trying to break, so it's the rule a platform has the most reason to get right. No protocol enforces it. A signature names the operator, a mandate caps the spend, and account linking ties the agent to a buyer, but nothing in that chain counts tickets per person. The count lives in the platform's own records, and in the agent era that's where the burden stays.

The usual way around a limit has always been more identities. In its 2025 complaint against Live Nation and Ticketmaster, the FTC described brokers "creating thousands of Ticketmaster accounts and using proxy IP addresses" to get past posted limits.

According to the FTC, five brokers controlled 6,345 Ticketmaster accounts and held 246,407 concert tickets to 2,594 events (FTC, 2025).

Those are allegations in an ongoing case, and none of them involve AI agents. They still show what happens when a limit is counted per account rather than per person. Agents don't change that weakness, but they can make it cheaper to exploit, because a script that runs one account can run a thousand just as easily.

What a Limit That Holds Up Against Agents Looks Like

In our R&D team's test build, the per-person cap was the piece that made the rest of the access policy believable. Several design choices separate a limit that holds from one that only looks strict on the event page:

• Count holds as well as orders: A seat held for checkout is out of circulation, even if nobody has paid yet. A limit that only counts completed orders lets an agent sit on far more seats than the posted maximum while payments are pending.
• Tie the count to a person, not an order: A per-order cap of four lets the same buyer place a second order for four more. The count has to follow the customer record.
• Count across every channel: The website, the app, the box office, and every assistant connection should draw down the same number. A limit enforced separately in each channel is really several limits.
• Cover guests too: Guest checkout has no identity until payment details arrive. In our test build, guests were matched to a customer record by email at checkout, so the cap applied from that point, and anonymous holds before checkout were not counted. A true per-person limit also requires linking records that belong to the same buyer.
• Let a failed limit win: If the signature is valid and the limit is reached, the request stops. A trusted operator doesn't earn a buyer extra tickets.

None of this is new to ticketing. Platforms have enforced limits for years, and the hard part has always been identity: knowing that two accounts, two cards, or two channels belong to the same fan. AI agents add new places a purchase can start, and each one needs to report back to the same count.

When a European events booking platform asked Softjourn to get its system ready for a 20,000-ticket, five-minute on-sale, our team reviewed the full path from traffic to database. Along the way, we flagged that about 5% of the platform's web traffic came from a country that produced no transactions at all, a strong sign of bot activity. The biggest gains were in the database, where our recommendations showed how a slow query of over five seconds could run in 53 milliseconds.

Proving the Buyer Is Human Instead

Some platforms and artists come at the problem from the other side. Rather than vetting the agent, they make the buyer prove they are a real, single person before the tickets become available. A few approaches are already in use:

• Pre-registration: Programs such as Ticketmaster's Verified Fan ask fans to register before the on-sale, so access codes go to accounts the platform has already screened.
• Randomized waiting rooms: Assigning queue places at random when the sale opens takes away the advantage of arriving first, which is most of what speed buys a bot.
• Proof-of-personhood credentials: In April 2026, World launched Concert Kit, which lets artists "reserve a portion of tickets for verified humans" who verify with a World ID to claim them, then finish the purchase on the ticketing platform as usual (World, 2026).

Each approach trades some friction for stronger proof. A World ID requires an in-person scan at one of the company's Orb devices (Engadget, 2026), which suits a reserved allocation better than a general on-sale, and pre-registration adds a step some fans skip.

These approaches can sit alongside agent verification. A fan who proved they're human can still send an agent to shop for them, and the platform can link both facts to the same account and the same count.

Does the BOTS Act Apply to AI Shopping Agents?

Ticketing is one of the few industries where US federal law speaks directly to automated buying. A retailer that lets an agent buy ten pairs of sneakers has a good customer. A ticketing platform that lets an agent buy past a posted limit may have a legal problem.

What the BOTS Act Covers

The Better Online Ticket Sales (BOTS) Act of 2016 makes it unlawful for any person to get around the security measures or access controls a ticket issuer uses to enforce posted purchase limits, or to sell tickets obtained that way. The FTC and state attorneys general enforce it, and after the FTC's latest inflation adjustment the civil penalty can reach $53,088 per violation (Federal Register, 2025).

For most of its life, the law was aimed at brokers, and enforcement picked up only recently:

• December 2016: The BOTS Act becomes law.
• January 2021: The FTC brings its first BOTS Act cases (FTC, 2021) against three New York ticket brokers accused of using bots to buy more than 150,000 tickets.
• September 2025: The FTC and a group of states sue Live Nation and Ticketmaster, alleging the platform let brokers exceed its own posted limits.
• April 2026: A federal court in Maryland lets the FTC's case against broker Key Investment Group go forward.
• September 28, 2026: A federal court in California refuses to dismiss the case against Live Nation and Ticketmaster.

Our guide to global event and ticketing regulations covers the BOTS Act and comparable laws in other countries in more depth.

The FTC's Case Against Ticketmaster

The FTC alleges that Ticketmaster advertised ticket limits while knowingly letting brokers exceed them through large numbers of accounts. In its motion to dismiss, Ticketmaster argued, among other things, that it provides a marketplace and doesn't sell the resold tickets, that a platform can't circumvent its own controls, and that a ticket limit policy isn't a technological measure the law protects.

The court disagreed at this stage. On September 28, 2026, Judge Maame Ewusi-Mensah Frimpong denied the motion "as to each claim" and wrote that "the BOTS Act does not preclude platforms from facing liability, and the Court will not read it as doing so" (court order, 2026).

The order also pointed to the earlier Maryland ruling, which found that the BOTS Act reaches "non-bot users." In that case, the broker had argued it didn't use bots at all, and the court answered that the statute "unambiguously applies to 'any person' and not just to 'bots'" (Digital Music News, 2026).

Neither ruling decides that anyone broke the law. Both came at the motion-to-dismiss stage, which only asks whether the claims can go forward, and both cases continue.

What It Means for Platforms Letting Agents In

No court has applied the BOTS Act to an AI shopping agent, and neither case involves one. What the rulings establish for now is narrower and still significant for anyone opening an on-sale to agents: the law reaches people and not only bots, and a platform's own enforcement of its limits can be examined in court.

That points to a few practical steps for a platform that admits agents:

• Apply posted limits to agent purchases: If the event page says four tickets per person, an agent buying for that person counts against the same four.
• Keep the records: Log the signature outcome, the linked account, and the limit check for every agent hold and order. If a regulator asks how limits were enforced, those logs are the answer.
• Write down the policy for unsigned automation: Treating it as a bot is the safer default, and a written policy shows the decision was deliberate.
• Bring legal counsel in early: Who is responsible when a fan's agent tries to exceed a limit is an open question, and the answer will come from cases that haven't been filed yet.

This section describes the law and the rulings as they stand and isn't legal advice.

What Our Test Build Showed

In September 2026, our R&D team spent about ten days building the agent-facing pieces of a ticketing platform in a test environment. We wanted to see whether the access policy described in this article holds together once it runs in software rather than on paper. It's proof that the pattern works rather than a product, and any client version would be built inside that client's own systems.

The build covered the full path an agent takes, from reading the catalogue to handing the fan off to checkout. From the security side, four results stood out:

• Signature checks sorted traffic the way we expected: A forged or expired signature from a known operator was refused, a valid one named the operator, and ordinary fan traffic without a signature passed through untouched.
• One seat went to one buyer: When several requests raced for the same seat, the database picked a single winner, and every other request got an immediate answer that the seat was gone, rather than waiting on a seat that was already sold.
• Holds expired on time: Every hold had a fixed lifetime, so a seat claimed by an agent that went quiet returned to sale on schedule.
• The per-buyer cap counted the right things: It included live holds as well as confirmed orders, per customer record and per event. Guests were matched to a record by email at checkout, so the cap applied to them from that point.

Some decisions were left open on purpose. The build doesn't decide what to do with unsigned automated traffic, because that's a policy choice each platform makes for itself. It also stops short of letting an outside assistant sign a fan in to the platform. Consent and account access belong to whoever owns the relationship with the buyer, and we would rather design that step with a real platform than guess at it in a test environment.

Projects like this tend to start with an audit of what a platform already has: how its limits are counted, where its signatures would be checked, and which channels report back to the same records. That's often where we begin with ticketing clients.

Stopping Ticket Scalping When AI Agents Are Welcome

The two requests from the first minute of that on-sale still look alike at the network level. The checks around them can establish who operates the agent, which buyer authorized it, and whether the request respects purchase limits. They can't tell whether that buyer intends to resell, which is why the limit matters more than the label: a broker working through an approved agent still runs into the same per-person count as every fan. None of these checks is exotic, and most ticketing teams already run some version of them for their website. The work is making sure every new channel, assistants included, feeds the same checks before the next big on-sale tests them.

Much of this is still moving: Web Bot Auth remains a draft that few platforms verify today, no court has yet applied the BOTS Act to an AI shopping agent, and new rules are taking shape in the US and abroad. Whichever way those questions go, a per-person limit that counts holds and orders across every channel, along with logs that show how it was enforced, will keep its value, which is why it's the part we'd build first.

Softjourn has built ticketing software since 2005 and now develops MCP servers that open a platform's catalogue to AI assistants with access rules and limits built in from the start. Contact Softjourn to get started on agent access that keeps your on-sales fair.