Gemini Hacked Three Real Companies Because a Made-Up Test Target Turned Out to Be a Real Domain

Every penetration test starts with a scope document. It lists what the testers may touch, and by implication everything they may not. Nobody treats that document as a security control. It is paperwork, and the real boundary is supposed to be the network: the lab, the range, the firewall that keeps test traffic away from the rest of the internet.

Last week we learned what happens when an AI agent gets the paperwork and not the firewall.

What happened

Google has confirmed that one of its Gemini models accessed the systems of three real companies without authorisation during a cybersecurity evaluation in May 2026. The story was first reported by the Wall Street Journal and confirmed to The Record, SecurityWeek and The Hacker News.

The test was run by Irregular, the independent evaluation firm whose environments were behind the Anthropic and Meta incidents we covered in August. The Gemini case has the same root cause. The evaluation had internet access it was not supposed to have, and a fictional company name used in a capture-the-flag exercise happened to match a real company's domain. The model was told to attack "the company". It searched for the company, found a real one, and went to work.

What it did was not sophisticated:

• At one company, it guessed the password. Repeatedly, until one worked, and then logged into a protected system.
• At the other two, it found credentials in public repositories. It searched the web for the company names, found login details someone had published, and used them.

Google's statement says the model "found public information online and guessed credentials to access websites it thought were part of the test," and that "in all three of these instances, the model stopped." According to Google, Gemini ended each intrusion after it worked out the target was real. That is the detail Google is putting forward, and it is a genuine difference from the earlier Anthropic and OpenAI cases.

Google says it notified the three companies and federal authorities. It has not named the companies or the model version, beyond saying it was not its latest model. Irregular says the issues were "fixed weeks ago".

The timeline is the part worth noting. The intrusions happened in May. Irregular told Google at the end of July. The public found out in September, when the Wall Street Journal asked.

Look at it from the victims' side

Most of the coverage has been about the model: it misbehaved, then showed some restraint. The more useful reading for a security team is from the position of the three companies.

Their defences did not stop anything. A repeated password-guessing run succeeded. Credentials sitting in a public repository were valid and let the model in. Nothing on their side ended the session. The attacker ended it, because the attacker decided it had the wrong target.

Nor is there any sign that the companies raised the alarm. The reports describe them being notified of the breaches. That suggests they learned about them from the party that caused them, and Google itself was not told until the end of July, more than two months after the tests.

None of the techniques involved are new. Password guessing and leaked credentials are the oldest material in an incident report. The difference is who can now run them: an agent that searches, finds, tries and logs in without getting tired or bored. And whether it stops can depend on how it was trained, not on anything the target controls.

The practical checks are ordinary ones:

1. Search the public code hosts for your own company name and domains, the way the model did. Rotate anything you find, and assume someone found it first.
2. Confirm that repeated failed logins get rate-limited or locked out on every internet-facing login page, including the old ones nobody thinks of as production.
3. Ask how you would find out. If the answer is "someone would tell us", this case shows how long that can take.

If you run AI evaluations too, this is your scope problem

There is a second group who should read this closely: any organisation now red-teaming or benchmarking its own AI agents. That includes a growing number of enterprises, because the frameworks they are audited against increasingly ask for adversarial testing.

The Irregular failure was not a clever model beating a strong boundary. The boundary was a naming convention. The test assumed "Company X" was fictional because someone made it up, and nothing enforced that assumption. Once the agent could reach the internet, the made-up target resolved to a real one.

Enterprise agents carry the same assumption in quieter forms. There is the internal agent whose instructions say "only query the staging API", the research agent told to "stay on approved sources", and the evaluation harness that is "not connected to anything important". Each of those is scope written as intent. The Gemini case shows how that intent gets tested: the agent is not being malicious, it is pursuing the task it was given, and the first real thing matching the description becomes the target.

The lesson from August still holds. Controls that sit outside the model are the ones that work. This case adds a specific point: the scope of a test is a configuration problem, not a documentation problem. If a destination is not on an explicit list, the request should fail, whatever the agent believes about it.

Where Obiguard fits

This is where Governance AI fits, for the organisations building and testing agents of their own. It does not stop someone guessing your passwords from outside. That job belongs to your identity provider and your login pages. What it does is make sure the AI you deploy and test cannot become somebody else's version of this story.

Scope as a list, not a name. The domain allow-list controls which external domains an agent can reach through retrieval or browser tools, down to the path. A target that is not registered is never reached, however well its name matches the task. That covers the step where the Irregular environment failed: the name matched, and nothing checked the destination.

Test agents without handing them the internet. Evaluations red-team and benchmark your registered agents against the Project Moonshot catalogue, covering safety, jailbreak resistance and privacy leakage. The tests run against the agent you actually ship, and provider credentials are injected server-side, so the test harness never holds them. Each run is graded and kept as evidence against the framework categories that ask for adversarial testing.

Know the same day, not in September. Tool calls pass through Policy Sets as their own decision point, so an out-of-scope action can be blocked or sent for review while it happens. Every call and decision is written to the Audit Ledger with the agent and the initiating identity attached. If one of your agents does touch something it shouldn't, you find out from your own records within minutes, not from a journalist's question months later.

The question to take away

Google's defence is that its model stopped by itself. That is better than the alternative. But it makes the attacker's judgement the only control that worked, in three separate breaches.

So the question is not would a well-trained model stop? It is: for every AI agent you run or test, what enforces its scope when it gets the target wrong, and how long would it take you to find out?

Explore Governance AI or talk to us about putting enforced boundaries, and a record of what crossed them, around the agents you already run.