Definition
AI agent traffic is the set of requests an application receives from software agents that use AI models to decide what to do. These agents browse pages, call APIs, fill in forms and invoke tools on Model Context Protocol (MCP) servers, usually on behalf of a person or a company. The defining feature is that a model, not a person, chooses the next action within the task it was given.
AI agent traffic overlaps with older forms of automation such as crawlers and scripts, but it behaves differently. Agents pursue goals, adapt to what they find, and often interact with parts of an application that were designed only for people.
Where it shows up
- Websites and SaaS apps: assistants reading documentation, comparing pricing pages or completing multi-step workflows inside a signed-in session. AI operators document some of this traffic: OpenAI's ChatGPT-User and Anthropic's Claude-User fetch pages when a person asks a question.
- APIs: agents calling endpoints directly with API credentials, often at a different pace and pattern from a human-driven integration.
- MCP servers: AI clients invoking tools, where every call is by definition automated and the question is which client is calling and what it may do. See MCP server.
How to recognise it
No single signal identifies agent traffic reliably. Teams combine evidence of different strength, as covered in how to tell if website traffic comes from AI agents:
Verified evidence
Some agent operators sign their requests using HTTP message signatures (RFC 9421), with keys published under a domain they control, following the IETF Web Bot Auth work. A signature that validates is strong evidence of which operator's client sent the request.
Declared evidence
Clients can describe themselves: a user-agent string, an MCP client name, a header. These are useful but easy to imitate, which is why user-agent spoofing is a standing concern.
Inferred evidence
Request timing, navigation patterns, missing browser context and protocol details can suggest automation. Inferences can be wrong, so they should always be labeled as inferences.
When none of these supports a determination, the honest result is Unknown.
Why it matters
Agent traffic is not inherently good or bad. A shopping assistant comparing plans, an internal agent syncing records and a scraper ignoring your terms can look similar at the network level. What changes is what your application should do:
- Offer a structured response or API to agents you are happy to serve.
- Apply route-level limits where automated volume could strain resources.
- Ask for stronger credentials before high-impact actions.
- Keep the human experience fast and uncluttered.
Treating all automation as abuse breaks legitimate integrations. Ignoring it means sensitive actions may run without the context your team assumes.
Common misconceptions
"Agents always identify themselves." Many do not, and declarations can be false.
"A signed agent is a trusted agent." A signature shows which key signed the request. It does not show that the action is authorized or safe. See agent authorization.
"Blocking automation protects the app." It often blocks the integrations customers rely on while determined bad actors adapt.
How Proof of Actor handles agent traffic
Proof of Actor classifies each interaction as Human, Human + AI, Agent or Unknown (the taxonomy is explained here), and states whether the result is verified, declared or inferred. Teams observe first, then route agent traffic with their own policies. See How It Works or apply for early access.
Sources
- Model Context Protocol specification (2026-07-28): the current MCP revision as of November 2026
- RFC 9421: HTTP Message Signatures: the standard behind signed agent requests
- IETF Web Bot Auth working group: standards work on authenticating automated clients
- OpenAI: Overview of OpenAI Crawlers: ChatGPT-User and other documented OpenAI user agents
- Anthropic: crawler and fetcher documentation: Claude-User and other Anthropic bots