Shrivu Shankar, a software engineer who writes about AI systems on his own blog, ran roughly 100 self-hosted AI agents against his own online accounts for five hours. Three accounts fell to software vulnerabilities, two more to password brute-forcing, and the agents made sixteen social engineering attempts. No agent found a third-party zero-day or reached what Shankar calls a tier-zero account: email, password manager, banking.
This was one person’s weekend project against his own footprint, not a controlled study, not peer reviewed, and not a claim about attacker success rates generally. Shankar built the test, chose the targets, and ran it once. Nothing here says one in twenty accounts falls to this treatment across the internet; the sample is a single subject with a single set of old side-projects and reused credentials.
The number worth sitting with is not five compromises. It is that five successes came out of a hundred parallel, unsupervised, cheaply-run attempts. That ratio is the finding. A hundred agents each running for a few hours on rented compute is a cost structure, not a capability breakthrough: the individual techniques Shankar describes, credential stuffing and old-project bugs, are unremarkable by security-industry standards. What changed is that a single operator could point a hundred of them at a target overnight without hiring a hundred people or writing a hundred custom scripts.
That is the shift defenders should track: not “AI can hack now,” which security teams have heard for years, but “the price per attempt just kept dropping.” Every control built on the assumption that probing a target is expensive, whether in operator time, infrastructure, or attention, gets weaker as that assumption stops holding. A defense that relies on an attacker not bothering to try the tenth password, the fifth stale login, or the second social engineering angle was never a defense against volume; it was a defense against apathy.
That is also why the sixteen social engineering attempts deserve a sentence on their own even though none is described here in any detail: a flood of low-effort attempts is precisely the case where no patch, no dependency update, and no code review helps, because the target of the attempt is a person’s judgment in the moment, repeated as many times as the attacker can afford to ask.
Shankar frames the experiment as a look at where this trend goes as abliterated open-source models get more capable and cheaper to run, and that framing is reasonable as a forward-looking prompt even though the data point behind it is small. The reportable conclusion is not that AI enables new attacks; it is that AI enables more attempts at old ones, and the controls that catch old attacks at scale were never glamorous. Rate limiting on login and password-reset endpoints, and a password policy that actually blocks reused or lightly-modified breached credentials, are the two boring items security teams have deprioritized for years in favor of newer tooling. Shankar’s own numbers argue for exactly the opposite prioritization: the sort of coverage that survives being tried on a hundred parallel loops is coverage that does not depend on the loops being expensive to run.
For any team auditing its own exposure, the actionable takeaway from this experiment is not to buy an AI-specific defense product. It is to check, this week, whether every account tied to your organization enforces rate limits on authentication and reset flows, and whether your password policy actually rejects known-breached and lightly-modified credentials rather than merely requiring length and a symbol. Those two unglamorous controls are what stop a hundred cheap parallel guesses regardless of whether the model running them refuses on principle or has had that refusal trained out.
Shrivu Shankar described the experiment on his own blog on September 8, 2026.
