AI agent detection signals that still work when agents look human
Bots follow a script. AI agents work toward a goal and choose their own steps, which makes them harder to catch. In this Help Net Security interview, Zohaib Ahmed, CEO of Resemble AI explains how agents arrive as declared, undeclared or disguised traffic, and why binary bot detection misses the last two groups.
Ahmed walks through the signals that give agents away, like click timing or a batch of sessions all chasing one goal. For the agents employees set up on their own, he says to start with OAuth consent logs and outbound traffic.
A few years ago, “bot” meant a script hammering a login page. When you hear “AI agent” in a detection meeting now, what do you picture, and what do most security teams still picture instead?
A bot follows a script, and while it might read content, like a crawler or scraper, or carry out a fixed task such as filling out a form or logging in, it is restricted to the script. An AI agent works toward a goal, like booking a flight or completing a purchase, and decides which steps to take as it goes. This can be done through browser-use, which means it clicks and scrolls. Another layer of complexity is how AI Agents present themselves, which can be Declared, Undeclared or Disguised.
Declared: It identifies itself in its user agent or a signed header, which makes it easy to identify.
Undeclared: It doesn’t identify itself, but doesn’t try to hide either. It leaves the usual fingerprints of browser automation tools, more difficult to detect as any tool detecting it needs training data to identify the fingerprint.
Disguised: It changes its identity or browser fingerprint to look like a regular visitor, nearly impossible to detect with traditional tooling relying on fingerprints.
Because bot detection is largely binary (human or not), it often misses the Undeclared agents and almost always misses Disguised agents which appear human based on how they operate.
If an agent behaves like a slightly impatient human, what tells are left? Which signals would you put on a dashboard?
It’s very signal-based, including how the pointer moves, how clicks are sequenced and how rapid they are, how typing flows and how scrolling behaves, along with browser and environment tells as mentioned, such as request headers, automation flags and Web Bot Auth signatures from agents that identify themselves.
Then there is a layer of sessions where the user is behaving the same way or moving towards the same goal which could signal a swarm, which is what security teams are currently most worried about. Once you can identify all the signals, joining those to be read in real time and identify potential attacks is next.
Employees are wiring agents into email, calendars and SaaS tools through personal API keys and OAuth grants. How do you find the agents nobody told security about? Which logs do you pull first?
No one is telling security about their agents, especially as an early adopter. To them it’s a productivity tool they set up in five minutes and they gain more than they lose from not going through the proper process. The problem is those agents run on the employee’s credentials, so in most logs it just looks like that person being very busy.
I would start with your identity provider and pull the OAuth consent and app grant logs, since every agent that touches email or a calendar generated a token at some point, and look for third party apps with broad scopes like full mailbox or drive access that only one user approved.
Next is the audit logs in your core SaaS tools for personal API keys and tokens being created, and what they get used for after. Then egress or proxy logs for traffic going out to model provider APIs and agent platforms from machines with no business reason to call them. Once you have the list of grants, the activity tells you the rest, an employee doesn’t read 400 emails in two minutes at 3am or accept a calendar invite a second after it lands, so you’re looking for the same speed and timing patterns from earlier.
Realistically, this should be endorsed by companies who want employees to adopt AI, and policy should adapt to support it securely instead of trying to hunt it down or ban it.
If a CISO could fund exactly one agent detection investment next quarter, where would you point the money, and what would you tell them to postpone?
I would point them at agent detection that addresses the challenges we mentioned around Undeclared and Disguised sessions. We see this as a three step challenge: first, you need to have a good grasp on how much of your traffic on your properties (web and apps) is agentic.
Second, you can define policies around sensitive data, logins, basically all your risk surfaces and restrict access on those in a more broad initial sweep. Third, you can add in routing that is automated to address both the security risks and potential loss of revenue that comes with blocking all agents, even the authorized ones. This is what CISOs should aim to achieve within the next 12 months if they want to satisfy their customers and board members on safety that doesn’t tank their bottom line.
Which detection signal do you rely on now that you expect to be worthless within 18 months?
Any kind of metadata. This is already flimsy, relying on location or IP address, anything else that is supposed to indicate a human user, which can already easily be spoofed or hidden. This will not be a viable signal within 6 months, let alone 18.
Download: The IT and security field guide to AI adoption
