The most dangerous thing a security agent can say is 'no findings'

AI agents are only as honest as the cybercrime data behind them, and most of that data is thinner than anyone admits

Security teams have stopped debating whether to use AI agents. Today, the pertinent question is how much to believe them.

That’s the right question, and I don’t think it gets asked often enough. Agent frameworks are mature. Model Context Protocol (MCP) has made connecting an agent to an outside data source almost effortless. Two years ago, the hard part of building AI-driven security was the reasoning. Now, the reasoning is largely solved, the plumbing is largely solved, and what’s left is the least fashionable layer of the stack – the data.

Consider how a good analyst answers a question. If you ask whether a client’s credentials are circulating on the dark web and the evidence is patchy, they’ll say so. They’ll tell you where their visibility runs out and what they haven’t been able to check. That kind of candour is useful. It lets you decide how much weight the answer deserves.

An AI agent, however, gives you a result with no findings. There’s no caveat, no note what wasn’t searched. The agent has no way of knowing what it hasn’t seen, and no way of telling you. Whoever reads the output takes it as reassurance.

Is that a surprise? It shouldn’t be. Yet I’d argue it ought to concern us far more than it currently does.

Plenty of teams decide to build their own cybercrime data collection, and the appeal is obvious. Stealer logs appear in public channels. Credentials surface on paste sites. Forums can be crawled. The first iteration looks convincing in a demo and everyone goes happy.

The problems then begin to arrive slowly. The channels you monitor stay fixed while the ecosystem moves on, so the newest batches of stolen credentials are posted where you aren’t looking. A fresh infostealer variant uses a log format your parser hasn’t met, and instead of failing, it quietly returns less. An agent runs on top of that for weeks, enriching alerts from an ever-smaller slice of reality, and nobody notices because the alerts keep arriving.

Then there is the clock. Attackers using stolen credentials now operate in hours. A pipeline that surfaces an exposure two weeks after the infection is documenting the breach rather than stopping it. None of this shows up as a warning on a dashboard. It shows up as an account takeover, a fraud campaign that scaled before anything flagged it, or an investigation that stalls because the history was never collected.

So, what does an agent actually need? Seemingly counter-intuitively, more than a person does. Dashboards were designed for humans who can cope with messy data, cross-reference by hand and plug gaps with experience. An agent can do none of that, so the data has to carry the load.

It has to be fresh, with latency measured in hours. It has to be broad enough that an empty result is meaningful, because an agent that declares a customer clean when they aren’t does more harm than having no agent at all. And it has to see past human logins. The stealer log that captures a developer’s passwords also captures their API keys, OAuth tokens, service-account secrets and CI/CD credentials. Today it captures model API keys and MCP server credentials as well. The agents we’re deploying have become targets themselves, and an agent that only watches for human identities is blind to the exposures nearest to it.

Get the data right and the output changes character entirely. A thin pipeline reports that a credential turned up in a stealer log. While accurate, it is nonetheless as informative as a smoke alarm. Connected, historical data turns the same event into a route. One credential opens the identity provider’s admin console; another is a deployment key with production access. A listing for that access went up on a Russian-language forum three days ago, linked to an actor known for ransomware against financial firms, whose tooling has previously exploited a flaw sitting unpatched on this organisation’s VPN appliance. An agent traverses that chain in seconds. An analyst would need hours, assuming they assembled it at all.

Which brings us to the conversation with legal. Dark-web collection runs into GDPR, the US Computer Fraud and Abuse Act, wiretap law and a patchwork of national rules. The moment an AI system ingests that material, its provenance becomes a liability matter rather than an engineering detail. Telling a risk committee that the agent simply pulled it from Telegram is not an explanation that survives with the room.

Building comprehensive cybercrime data infrastructure takes years and keeping it at a level an agent can safely rely on takes longer. Most teams would get more from pointing their engineers at the agent logic that sets their product apart and sourcing the data from someone who has already absorbed the cost of collecting it.

The agents worth trusting are the ones whose builders can answer a simple question, what did it not look at? If we want AI in security to earn its place, that question needs to be asked every time.

to your network

No yet. Be the first to your thoughts.