Your Agent Doesn’t Have to Commit a Crime to Cost You the Tickets

Not legal advice; the author is not a lawyer.

---

This week a mainstream tech column recommended eight chores you can hand to the new wave of personal AI agents — OpenAI’s Dots and ChatGPT Work, Meta Muse, Gemini Spark. Most sound routine. Watch a flight price. Triage the inbox. Remember the free trial.

Number eight was different. The advice was to point your agent at things you can’t get your hands on — the booked restaurant, the doctor with no openings, the product that keeps selling out — and have it keep checking until an opening appears. The only caveat offered was that it depends on whether the website allows that kind of automated access.

For event tickets, that caveat is carrying more than it looks like. “Whether the website allows it” is three different questions with three different kinds of consequence: the seller’s terms, the seller’s security system, and — further out, with more conduct required to get there — the law. A recommendation to delegate the task, and a prompt asking permission to visit the website, does not necessarily explain any of those consequences. So here they are.

1. The terms you agreed to already cover “just checking”

Start with the document you clicked past when you made the account. Ticketmaster’s U.S. Terms of Use prohibit using any automated software or computer system “to search for, reserve, buy, or otherwise obtain tickets.” Read the verbs again: search for is first on the list. The same clause appears in the Account Manager terms that govern team and venue ticketing, and a federal court quoted it from Ticketmaster’s main-site terms as far back as 2018 in the Prestige bot case. The terms make you responsible for all activity conducted through your account, and reserve the right to cancel an account or deny access to the site for any reason.

So under those terms, using the prohibited automated method to watch availability is already within the restriction. Waiting to ask before purchasing does not resolve that problem. And the question is not whether automation exists somewhere in the seller’s ecosystem; it is whether this agent is authorized to perform this operation through this channel.

“Read-only” doesn’t rescue it. Read-only describes whether the agent changes the seller’s data. It says nothing about whether the agent’s activity is consequence-free for your account.

2. The first consequence is operational, and it can arrive during the on-sale

Ticketmaster’s help pages are unusually direct about this. The page titled “My activity has been paused or suspended — I’m a genuine fan” says the company pauses account activity when it detects unusual behavior, that you may need to wait a short period before you can get back in, and that your troubleshooting list includes turning off any automated tools or browser extensions and not refreshing or clicking multiple times. The queue page says the queue runs advanced security measures to detect bots and monitor traffic, and tells you not to refresh because your spot is held automatically.

Those pauses are described as temporary, and there are troubleshooting and support paths. So the honest statement isn’t “you’ll be banned.” It’s this: automation can get you flagged or blocked, and a brief interruption at the moment of an on-sale can be enough to cost you the thing you wanted. Separately, the terms permit cancellation of accounts or transactions for prohibited activity. Those are two different consequences — a security response and a contractual remedy — and neither requires anyone to have discussed liability.

You do not need a lifetime ban to see the failure. A brief pause at the wrong moment is the whole story.

3. Why “ask before buying” isn’t an access policy

Every consumer agent ships with controls, and they are not all the same control. OpenAI’s documentation for its ChatGPT agent (since succeeded by newer products) described user confirmations for high-impact actions, a takeover mode for sensitive inputs, a “watch mode” requiring supervision on certain sites, and a blocklist; the column that prompted this post describes agents asking permission before visiting a site; purchase approval is yet another thing. Each serves a purpose. And documented controls are not the same as demonstrated enforcement: in July 2025 users posted screenshots of that same agent clicking through Cloudflare’s “I am not a robot” checkbox on its own, narrating as it went. None of these controls is an answer to the problem in sections 1 and 2.

Purchase approval, specifically, is on the wrong side of the line in time. It governs the last step. The terms and the security system react to the steps before it — the polling, the retries, the session behavior. By the time the agent stops to ask whether it may click “buy,” the activity the seller objects to has already happened.

The website-access prompt fails differently. Asking “May I access Ticketmaster?” tells the user where the agent intends to go. It does not tell them that the method it intends to use is prohibited, that the activity could affect their account, or that their approval cannot waive the seller’s restriction. The right design assumption is that the user has not read the terms. The system should identify a known conflict and communicate its consequences before dispatch, not leave the customer to discover the conflict after approving the task.

For a workflow that falls within the cited prohibition, the warning should read closer to this:

The applicable terms prohibit the automated searching this workflow would perform. Using that method could put your access, account, or tickets at risk. I will not run this workflow through that channel.

Two things about that wording. It says the terms prohibit this method, not that the agent is legally barred from the site — ordinary visits are not the problem. And it is not an “accept the risk and proceed” checkbox. Disclosure informs the user; it does not grant an exception. The buyer’s approval and the seller’s permission are separate things, and the first cannot manufacture the second.

The same logic governs what happens when a restriction appears mid-task. An agent may distinguish legitimate recovery — Ticketmaster itself sometimes tells you to verify your session or refresh once — from evasion correctly, or it may misclassify the situation. The execution boundary should not depend solely on that judgment. Understanding a restriction is not authority to waive it. So the timing is explicit: a known prohibition prevents dispatch; a newly encountered security restriction stops autonomous workaround attempts; any recovery follows a path the target sanctions. A model that has read the terms is better informed. Its reading is information, not independent authority to continue.

4. The law is further out, and it requires more than this

The criminal and regulatory exposure is real, and it requires conduct and statutory elements that an ordinary “find me seats” instruction does not supply by itself. That distance is the point of this section.

The BOTS Act. The Better Online Ticket Sales Act of 2016 prohibits circumventing a security measure, access control system, or other technological control that enforces posted event-ticket purchasing limits or maintains the integrity of posted online purchasing-order rules, and prohibits selling tickets obtained that way when you knew or should have known. The terms help here, but not the way people assume: they may help establish the purchasing rules that a technological control protects. A terms violation is not, by itself, proof that the agent circumvented that control. The chain is a posted limit or ordering rule, a technological measure enforcing it, and conduct that circumvents that measure, subject to the statute’s other elements. Holding an ordinary queue position, retrying after an error, and running a second identity to get two draws are not the same facts, and they don’t establish the same things.

The BOTS Act is enforced by the FTC and state attorneys general as an unfair or deceptive practice. The first federal action, in January 2021, was against three New York ticket brokers who, the FTC alleged, used software to search for and reserve tickets automatically, software to hide their IP addresses, and hundreds of fictitious Ticketmaster accounts and credit cards to get around posted limits — more than 150,000 tickets in all. Judgments exceeded $31 million, most of it suspended for inability to pay, with the defendants required to pay about $3.7 million. That’s civil.

The criminal cases. The one that produced guilty pleas predates the BOTS Act. Wiseguy Tickets built a network that flooded Ticketmaster, Tickets.com, and MLB.com at the instant of on-sale and solved CAPTCHAs faster than a human could, buying roughly 1.5 million premium tickets between 2002 and 2009 and reselling them to brokers. Federal prosecutors in New Jersey charged the operators under the Computer Fraud and Abuse Act and with wire-fraud conspiracy. In November 2010 the principals pleaded guilty to felony conspiracy counts; a third pleaded to a misdemeanor CFAA charge. They were sentenced to probation and community service.

Be precise about what that case shows. The government’s announcement describes aliases, shell corporations, fraudulent misrepresentations, and a resale business — an organized scheme, not a fan with an assistant. It is evidence that deliberately organized ticket-acquisition misconduct can produce criminal charges. It is not evidence that an ordinary consumer instruction to find seats is a felony. The state analogue cuts the same way. New York’s ticket-bot statute makes any use of ticket purchasing software to buy tickets unlawful and subject to civil penalties — but the class A misdemeanor applies to someone who acts “for the purpose of selling or offering to sell tickets in order to derive a profit,” and who intentionally uses the software, controls its operation, or knowingly resells tickets obtained with it. A consumer with no intent to resell is not automatically in the criminal frame, though the civil prohibition does not ask about purpose.

The contract cases. hiQ v. LinkedIn is the reminder that a contract claim can survive when the hacking claim fails: after years of CFAA litigation that hiQ largely won, the district court ruled in November 2022 that LinkedIn’s terms prohibiting scraping and fake accounts were enforceable and that hiQ had breached them, while leaving hiQ’s waiver and estoppel defenses for trial; the parties then settled with a $500,000 consent judgment. That supports a warning about separate contract exposure. It is not a rule that every alleged terms violation produces an enforceable damages claim.

5. What the Ninth Circuit actually decided

On August 4, 2026, in Amazon.com Services v. Perplexity AI, the Ninth Circuit issued the first federal appellate opinion on who is legally acting when an AI agent does something online. Amazon had won an injunction stopping Perplexity’s Comet assistant from accessing Amazon.com under the CFAA. The court vacated it, holding that on the record before it, the agent was a tool, not a person; the agent could not itself “access” a computer under the statute; and it was the user, acting with the assistant’s help in the user’s own session, who accessed the site — not Perplexity.

Three things that opinion did not do. It did not announce a general transfer of agent liability from developers to users; it said in so many words that it was not establishing a new legal regime for agentic AI, reserved tort and other theories, and left open whether a developer exercising more control over its agent on a different record might itself gain entry to a site’s servers. It did not decide any contract question — attributing access to the user is not a finding that the user breached anyone’s terms, and the court added in a footnote that nothing in the ruling impairs Amazon’s ability to regulate access through its own terms of service. And it did not hold the users liable under the CFAA. The opposite: one of the court’s stated reasons for rejecting Amazon’s reading was that it could expose users themselves to criminal liability for facilitating the agent’s access, and the court said it was unlikely Congress would have exposed individual users to criminal liability on those facts.

One detail from the opinion belongs here because it reappears in the next section. The dispute began with Perplexity’s decision not to send a user-agent string that would have told Amazon an AI agent was active — which is to say, the whole case was about whether the receiving site could tell who was knocking.

So: on the record before the court, the user — not Perplexity — accessed Amazon through the assistant. That did not establish a general transfer of liability from developers to users, or decide whether different conduct would breach a contract or satisfy a criminal statute. For this article, its relevance is narrow and specific: when the terms you agreed to make you responsible for activity on your account, the ruling does nothing to move that responsibility somewhere else.

6. What the door would have to know

Receiving systems can already verify which company an agent came from: OpenAI’s cloud browser for ChatGPT Work signs its outbound requests under the Web Bot Auth draft, using the RFC 9421 HTTP Message Signatures standard, so that sites and CDNs can confirm traffic originated from ChatGPT and allowlist it. Payment-side work goes further on paper. Visa’s Trusted Agent Protocol, built with Cloudflare on the same signature standard, adds an agent-intent signal and a signed consumer-recognition object so a merchant can tell whether the person behind the agent has an account or a purchase history. Google’s Agent Payments Protocol describes three signed mandates — Intent, Cart, and Payment — that bound what an agent may buy and record what the user approved. Those are specifications and early implementations, not evidence that the ticketing problem is solved; but they show the shape of what’s missing from a provider signature alone.

Knowing which company supplied the agent is not the same as knowing which person it represents, what that person authorized, or whether this particular operation is permitted. Two authorities are involved, and neither substitutes for the other. The buyer authorizes the agent to represent them. The seller decides which operations it accepts, through which channels, and under which eligibility and allocation rules. And proof of permission is not evidence of behavior: a signed mandate describes what was authorized; it does not, by itself, demonstrate that execution stayed within those limits.

The durable fix therefore belongs on both sides. The dispatching system must enforce the permitted workflow — the known-prohibition stop in section 3. The receiving system must enforce its own acceptance rules. Either one alone leaves the user holding consequences that nobody disclosed.

The short version

An agent does not have to commit a crime to cost its user access. A generic request to visit a website does not explain that the proposed method is prohibited or could put the user’s account at risk. The system should identify that conflict before dispatch and enforce the boundary — not leave the customer to discover it after approving the task.

“Ask before buying” is not an access policy; it’s a checkout setting.

---

---

James Ford is the founder and chief architect of Equilateral AI and the author of the Governance Fidelity Theory working paper. More at equilateral.ai/blog.