Until recently, AI agents capable of interacting with websites were mostly used by developers and technical users. Running one often required configuring an LLM, connecting it to a browser automation framework, and dealing with the limitations of these tools.
Things are changing quickly.
With products like Meta Muse, OpenAI Dots, Grok bot, and Perplexity Comet, AI agents are becoming increasingly accessible to regular users. Anthropic also recently announced Claude Duet, another consumer-facing agent designed to perform tasks across applications on behalf of its users.
These products are making it easier for people to delegate tasks that previously required interacting with websites manually: searching for information, comparing products, filling out forms, or making purchases.
For websites and applications, this raises several questions. How do you know when an AI agent is interacting with your platform? Which agent is it? What actions is it performing? And should you treat that traffic differently?
At Castle, we've been working on identifying these agents and exposing their identity to customers, so they can understand how agents interact with their applications and decide how to handle their traffic.
Why websites need visibility into AI agents
As AI agents become more popular, websites will increasingly receive traffic from automated clients acting on behalf of real users.
Much of this traffic is perfectly legitimate. Instead of browsing a website or interacting with an application themselves, users are simply asking an AI agent to perform these actions on their behalf.
For website operators, understanding this shift is useful for several reasons.
An e-commerce platform might want to measure how many customers use AI agents to browse products or complete purchases. A SaaS platform might want to understand which features are increasingly accessed through agents rather than directly by users.
In some industries, knowing who or what performed an action can also matter for auditing and compliance. For example, a financial application might need to record that a transaction or account modification was performed by an AI agent acting on behalf of a user, rather than by the user directly.
Beyond analytics and auditing, agent identification also makes it possible to define more specific policies.
A business might allow recognized agents to browse public content while requiring additional verification for sensitive operations such as account registration, payments, or changes to account settings. Other applications might want to restrict specific agents or monitor their activity before deciding how to handle them.
These decisions depend on the application and its requirements. But before making them, websites need to know which agents are interacting with their services.
And identifying an AI agent is not always as simple as checking its user-agent string.
Identifying an AI agent is not the same as authenticating it
There are several ways to identify AI agents, but they don't all provide the same level of confidence.
At Castle, we use different techniques depending on how the agent operates and what information it exposes.
Cryptographic authentication with Web Bot Auth
One of the strongest approaches is Web Bot Auth, which allows automated clients to cryptographically sign HTTP requests.
Instead of relying on a self-declared identity, the receiving service can verify the signature and establish that the request was signed using a key associated with a known agent operator.
This is particularly useful because user-agent strings and other HTTP headers can easily be spoofed.
However, authenticating an agent doesn't mean the request is necessarily safe. It establishes the identity of the signer, not whether the associated activity is legitimate or should be allowed.
A website still needs to decide what that agent is allowed to do.
Fingerprinting and network-level identification
Not every AI agent supports Web Bot Auth or another cryptographic authentication mechanism. Some agents don't explicitly declare their identity at all.
For those, we rely on fingerprinting and network-level information to identify their implementations.
For example, agents such as Meta Muse, Grok, and Instinct can be identified through combinations of browser characteristics and, in some cases, network infrastructure information such as their autonomous system (AS).
These signals can help distinguish agents even when they don't expose a dedicated user-agent string or authentication header.
However, fingerprinting is not cryptographic authentication.
An attacker who controls their browser can theoretically modify its properties to impersonate another browser or agent.
At Castle, we invest heavily in JavaScript obfuscation and techniques that make our client-side detection logic harder to inspect and manipulate. This raises the cost of fingerprint forgery, but doesn't make it impossible.
Network-level signals also have limitations, particularly when infrastructure is shared between different services or operators.
This distinction matters when websites want to give additional permissions to recognized agents. For example, an attacker could try to impersonate an allowed agent to benefit from the same permissions or reduced restrictions.
For this reason, cryptographic authentication is preferable when a website needs strong guarantees about an agent's identity. Fingerprinting and network-level identification remain useful alternatives for agents that don't support it.
User-agent identification
Finally, some agents explicitly identify themselves through their HTTP user-agent string.
This makes them easy to recognize, but provides no authentication guarantee. Any HTTP client can send the same string.
User-agent identification remains useful for visibility and analytics, but shouldn't be treated as proof that a request originates from the claimed operator.
How Castle identifies AI agents in practice
Castle combines the identification techniques described above to recognize AI agents, AI browsers, and browser automation tools interacting with applications.
This includes agents such as Meta Muse, OpenAI Dots, Grok Bot, ChatGPT agent, Instinct, and browsers such as Perplexity Comet.
Once identified, their identity is associated with the events they generate, making it possible to understand which agents interact with an application and what actions they perform.
AI agent and AI browser identification in Castle's event dashboard.
This information can be used for several purposes:
- Investigating agent activity: Filter events by agent identity to understand which users, accounts, and operations are associated with a particular agent.
- Understanding adoption and usage: Analyze agent activity over time to see which agents are becoming more popular and which parts of an application they interact with.
- Defining agent-specific policies: Allow, restrict, or require additional verification for specific agents or categories of agents, depending on the operation being performed.
Agent identity is also available directly in the Castle API through a top-level agent object:
{
"agent": {
"name": "ChatGPT agent",
"operator": "openai",
"category": "ai_agent",
"identified_by": ["web_bot_auth"]
}
}
The response includes the agent's name, operator, category, and the identification method.
Castle distinguishes between ai_agent, ai_browser, and browser_automation. The identified_by field can contain web_bot_auth, fingerprint, or user_agent, with multiple methods supported for the same agent. Fingerprint-based identification can also incorporate network information when relevant.
Agent identification, bot detection, and abuse detection serve different purposes. An AI agent performing automated actions should generally receive a high bot score, since the traffic is automated. However, automation doesn't necessarily imply abuse. Castle's abuse score focuses on detecting malicious or suspicious activity, regardless of whether it comes from a human, a traditional bot, or an AI agent.
Agent identity provides additional context that customers can use to investigate traffic and define their own policies.
For more details about the supported agents, API response fields, and authentication requirements, see our AI agent identification documentation.
AI agent identification, bot detection, and abuse detection
With all the attention AI agents are receiving, it's worth distinguishing AI agent identification from traditional bot and abuse detection.
We've previously written about how the anti-bot industry is increasingly focused on AI agents while classical bots continue to bypass commercial protections.
From what we observe, consumer AI agents aren't currently the main drivers of malicious automation. The impact of AI on bot attacks is more indirect: attackers use LLMs to reverse engineer protections, develop and maintain automation, and make their bots harder to detect.
For example, an attacker running large-scale credential stuffing or fake account creation is more likely to rely on purpose-built automation than on a general-purpose consumer AI agent, even if AI helped them develop that automation.
This is why we see AI agent identification, bot detection, and abuse detection as complementary capabilities.
Websites need visibility into legitimate agents interacting with their applications, but they also need to identify malicious automation that actively tries to hide its identity or bypass security controls.
This is why we're investing in AI agent identification alongside our existing bot detection and anti-abuse capabilities. As agents become more common, websites need visibility into this traffic without losing sight of the traditional automation and abuse problems they already face.
