AI Agents Can Legally Visit Your Site. Now What?

On 4 August 2026, the US Court of Appeals for the Ninth Circuit vacated the preliminary injunction that had kept Perplexity's Comet browser from shopping on Amazon since March. It is the first federal appellate decision anywhere on whether an AI agent acting for a user can lawfully reach a platform that does not want it there.

If you operate a website, a storefront, or an API, this ruling changes the tool you reach for — not whether you can defend your infrastructure.

What actually happened

The timeline is short and worth getting right, because a lot of the commentary has it garbled:

Amazon's central claim was under the Computer Fraud and Abuse Act — the 1986 anti-hacking statute. Its theory: Comet disguised itself as Chrome, evaded Amazon's bot detection, logged into password-protected customer accounts, and therefore accessed Amazon's computers "without authorization" after the cease-and-desist revoked any permission.

The appellate panel did not buy it, on a technical rather than a policy ground. The question the CFAA asks is who accessed the computer. And the answer, on Comet's architecture, is: the user did.

The user's own browser makes the request to Amazon. It renders the page locally. It then forwards screenshots to Perplexity's servers so the model can decide what to click next. Perplexity's infrastructure never opens a connection to Amazon at all. As the court put it, the user's browser visits Amazon; Perplexity's servers receive what the user sends.

The court declined to treat the assistant as a legal actor in its own right, describing it as a tool rather than a person for statutory purposes, and noted there is little to no existing caselaw on how to ascribe responsibility for AI agents under the statute. Facing that ambiguity in a criminal statute, it applied the rule of lenity — construe the doubt against liability. The panel also observed that Amazon's reading would expose ordinary users to criminal exposure for the software they choose to run, and that an injunction against conduct which likely does not violate the CFAA would not serve the public interest.

What the court did not decide

This is the part most summaries skip, and it is the part that matters operationally.

The ruling is about the CFAA, at the preliminary-injunction stage, on one specific client-side architecture. It did not hold that:

• Your terms of service are unenforceable. Breach of contract is a live theory and was not resolved. Amazon's suit continues in the Northern District of California.
• Blocking agents is illegal. Nothing in the decision obliges you to serve anyone. Technical countermeasures remain entirely lawful.
• Server-side agents get the same treatment. The holding hangs on the user's own machine making the request. An agent that fetches your pages from a vendor's datacentre is a different fact pattern, and probably a different outcome.
• Trespass to chattels, unjust enrichment, or state-law claims fail. Untouched.

So the shape of the change is narrow and specific: the criminal-hacking hammer is no longer available against a user-delegated, client-side agent. Contract, technical controls, and commercial terms all still are. Amazon has said it disagrees and may seek rehearing or Supreme Court review.

The category the web was never designed for

The deeper problem the case exposes is a modelling failure. Every access-control system built before 2025 sorts traffic into two bins: humans, and bots. An agent acting under direct instruction from a logged-in customer is neither, and defaults written for that binary produce nonsense when applied to it.

Consider the practical consequences of getting this wrong in each direction. Block user-delegated agents indiscriminately and you are blocking your own paying customers, who increasingly experience your storefront through an assistant. Allow everything and you lose the ability to distinguish a customer's shopping agent from a competitor's price-scraping fleet — both of which now look like a real Chrome session on a residential IP.

User-agent string filtering is finished as a control. Comet's alleged masking as Chrome is exactly the failure mode: any client that renders your page locally can present whatever identity it likes, and the ruling gives it no legal reason not to.

Pick a posture, then build it

There are three coherent positions. Pick one deliberately per surface — the right answer for your public catalogue is rarely the right answer for account-authenticated checkout.

1. Welcome them. Treat agent traffic as a distribution channel. This is the right call for content, catalogue, and documentation surfaces where discovery is the whole point. It means publishing llms.txt, shipping clean structured data, keeping critical content out of JavaScript-only render paths, and considering an MCP endpoint so agents can query you properly instead of scraping screenshots.

2. Gate them. Serve agents through an authenticated, rate-limited, commercially-governed path. This is where most e-commerce and SaaS should land for transactional surfaces: an agent API with keys, quotas, and terms, rather than tolerating undeclared browser automation against your checkout.

3. Block them. Legitimate, and unchanged by this ruling — but understand that after Amazon v. Perplexity your enforcement leverage is contract and engineering, not federal criminal law. Say it explicitly in your terms, and expect to lose the traffic.

Engineering the middle path

The technical primitive that makes the gated posture workable is cryptographic agent identity. Web Bot Auth, built on HTTP Message Signatures (RFC 9421), lets a well-behaved agent sign its requests with a key you can verify against a published directory. Unsigned traffic is not automatically hostile; it is simply unattested, and belongs in a different bucket with different limits.

The classification you want is three-way, not two-way:

// middleware.ts — classify before you decide
import { NextResponse, type NextRequest } from 'next/server'
import { verifyBotSignature } from '@/lib/agent-identity'
 
type Visitor = 'verified-agent' | 'unattested' | 'session-user'
 
export async function middleware(req: NextRequest) {
  const signature = req.headers.get('signature')
  const hasSession = Boolean(req.cookies.get('session'))
 
  let visitor: Visitor = 'unattested'
  let agentId: string | null = null
 
  if (signature) {
    const result = await verifyBotSignature(req)
    if (result.valid) {
      visitor = 'verified-agent'
      agentId = result.keyId
    }
  } else if (hasSession) {
    visitor = 'session-user'
  }
 
  const res = NextResponse.next()
  res.headers.set('x-visitor-class', visitor)
  if (agentId) res.headers.set('x-agent-id', agentId)
  return res
}
 
export const config = { matcher: ['/api/:path*', '/products/:path*'] }

Three rules follow from that classification, and they are where the real work is:

Rate-limit on identity, not on IP. A signed agent key is a stable subject you can meter and revoke. An IP address is not — residential proxies and client-side agents make it noise. Budget verified agents generously and per key; budget unattested automation tightly and per behavioural fingerprint.

Separate read from write. A user-delegated agent reading your catalogue is cheap and probably good for you. The same agent completing a purchase, changing an address, or cancelling a subscription is a different risk class entirely. Consequential actions deserve a confirmation step that reaches the human, not just the agent — which is also your defence against prompt injection, since an agent that has been manipulated will submit a perfectly well-formed request.

Write the policy down. Your terms of service should distinguish user-delegated agents from unattended crawlers, and state your position on each. That document is now your primary enforcement instrument. If it still just says "no automated access" it describes a web that no longer exists.

Why this matters in the MENA region

There is no CFAA in Tunisia, Saudi Arabia, or the UAE. Regional operators never had the American criminal hook in the first place — enforcement here has always rested on contract, on Saudi and Emirati cybercrime statutes with quite different framing, and on whatever your infrastructure can actually enforce. The Ninth Circuit has, in effect, moved US platforms toward the position regional teams were already in.

The practical implication is competitive rather than legal. Assistant-mediated shopping is arriving in Arabic markets through the same global browsers and models, and the regional storefronts that are legible to an agent — structured data, stable selectors, clean Arabic markup, an actual API — will be the ones that get transacted through. The ones that are a JavaScript maze behind aggressive bot detection will simply be skipped, silently, with no error message and no analytics event to tell you it happened.

If you are building for agentic commerce, the ruling removes one source of uncertainty about whether the channel is legally viable. It does not remove the engineering work.

What to do this week

• Audit what fraction of your traffic is already automated, and how much of it your current rules would block.
• Decide your posture per surface: public content, authenticated read, transactional write.
• Review your terms of service for the user-delegated agent category. Most sets of terms do not have one.
• Move rate limiting off IP and onto identity where you can.
• Ship structured data and an llms.txt if you want the discovery traffic.

The court's message is narrower than the headlines suggest: the CFAA is not the right instrument for this dispute. The engineering message is broader. Agent traffic is a permanent access class, your infrastructure is the enforcement layer, and the default posture most sites still run was designed for a web where every visitor was a person.

For the identity and verification mechanics in depth, see our guide to engineering for AI agent traffic with Web Bot Auth and the WebMCP browser standard.

Need help defining an agent policy for your platform? Noqta works with e-commerce and SaaS teams across Tunisia and the Gulf on agent-ready architecture, from structured data and MCP endpoints to signed-identity rate limiting.