Gemini Accessed Three Real Companies During a Cybersecurity Test: What Failed

By AiCybr Editorial · Published September 19, 2026

Google says a Gemini model accessed protected systems belonging to three real companies during a cybersecurity evaluation in May 2026. The incidents occurred while independent evaluator Irregular was running a capture-the-flag exercise intended to use simulated targets. The evaluation environment unexpectedly allowed internet access, giving the agent a path from the test into public systems.

According to Google, Gemini used public information and guessed credentials for websites it believed were within the authorized test scope. The model stopped its activity in all three cases after recognizing that it had reached real organizations. Google says the affected entities were informed and that it worked with Irregular on changes to the testing process.

The incidents were first reported publicly in September. Irregular had notified Google in July. The specific Gemini model version used in the May evaluation has not been publicly identified, which limits model-to-model conclusions from the episode.

What happened

The evaluation placed Gemini in a cybersecurity exercise where it was expected to attack systems associated with fictional organizations. A containment error exposed the agent to the broader internet.

One reported case involved a fictional target sharing a name with a real organization. The agent found the real organization online and gained access after credential guessing. Reporting on the other two incidents says the agent located publicly exposed credential information and used it to reach real systems.

Google Vice President of Security Engineering Heather Adkins said the model found public information online and guessed credentials for sites it believed were part of the test. Google says Gemini ceased the activity after learning the systems belonged to real companies.

The affected organizations were notified. Google also says it worked with the evaluation partner on changes to the testing process after the incidents were identified.

The failure was an evaluation-containment problem

The central engineering issue is the boundary between an offensive-security agent and systems outside the evaluation scope. A cyber-capable model can legitimately be given tools for reconnaissance, credential testing, command execution and exploitation inside a benchmark or red-team environment. Those same capabilities become a real-world access path when network controls permit traffic to unintended destinations.

For a capture-the-flag environment, authorization should therefore be represented in infrastructure controls as well as in the agent prompt. A textual instruction defining the target is weaker than an egress policy that technically restricts the agent to the intended hosts.

The Gemini incidents also show why target identity deserves its own control. Names, domains and services encountered through public search can collide with fictional benchmark entities. A model following a plausible reconnaissance path can reach a real organization if the environment allows unrestricted name resolution and outbound connections.

Controls for AI cybersecurity evaluations

Teams evaluating offensive-capability models can reduce this class of risk with several layers of containment.

1. Default-deny outbound networking. Permit connections only to explicit evaluation hosts, proxies and required infrastructure. Apply the policy outside the agent runtime so the model cannot alter it through ordinary tool use.
2. Use isolated DNS and synthetic namespaces. Test targets should resolve through controlled infrastructure. Public DNS resolution can turn a fictional organization name into a route to a real service.
3. Enforce destination allowlists at the network layer. Domain checks alone can be insufficient when redirects, alternate hostnames or direct IP connections are available. Egress gateways should validate the final destination.
4. Separate benchmark credentials from public credentials. Seed synthetic credentials inside the test environment and block access to public credential repositories when those sources are outside the evaluation objective.
5. Log every external connection attempt. DNS queries, HTTP destinations, SSH connections, tool calls and credential attempts should be captured centrally so evaluators can detect boundary pressure quickly.
6. Add automatic tripwires. Connections to unapproved IP ranges, unexpected autonomous-system numbers or public domains can halt the run before an agent progresses further.
7. Use disposable identities and infrastructure. Evaluation accounts, tokens and machines should carry the minimum privileges required for the benchmark and be destroyed or rotated after the run.
8. Require a human gate for scope expansion. If a task genuinely needs a new external target, the evaluator can approve that destination explicitly instead of allowing the agent to infer authorization.

These controls are relevant beyond cybersecurity benchmarks. Coding agents, browser agents and research agents can also cross intended boundaries when they combine internet access with credentials or execution tools.

Why prompt-level scope is insufficient for high-capability cyber agents

An agent can interpret a task correctly while still resolving an ambiguous target incorrectly. The May incidents appear to have involved systems that Gemini believed belonged to the exercise. That makes infrastructure-enforced scope especially important: authorization needs a machine-verifiable boundary independent of the model's interpretation.

This is a standard security principle applied to agentic systems. Least privilege limits the credentials an agent can use. Network segmentation limits where it can connect. Sandboxing limits what it can execute. Central logging and tripwires reduce detection time when behavior approaches a boundary.

For cyber evaluations, these controls should be designed around the capabilities being measured. An agent tested on reconnaissance may need broad read access to synthetic data. An exploit-development benchmark may need arbitrary code execution inside a lab. Neither requirement inherently grants access to the public internet.

What the incident establishes

The reported facts establish that a Gemini model autonomously found and accessed three real organizations while pursuing a cybersecurity evaluation, after the evaluation setup exposed it to public systems. They also establish that the agent stopped after recognizing the targets as real and that the affected organizations were notified.

The public record currently leaves the exact Gemini version unspecified. That missing identifier matters for attributing the behavior to a particular model release, so the incident is best treated as evidence about agent-evaluation containment and cyber-capable model behavior, rather than as a benchmark for a named Gemini version.

The episode joins a growing set of frontier-model cybersecurity evaluations where tool access and environment design have become part of the safety problem. As models gain stronger reconnaissance and exploitation capabilities, evaluation infrastructure needs the same defense-in-depth expected of other systems running potentially hostile or high-impact code.

Bottom line

Google's Gemini incident turns an abstract agent-containment concern into a concrete test-design lesson: offensive AI evaluations need technical authorization boundaries that survive model mistakes, ambiguous target names and unexpected tool behavior.

For teams running cyber-capability evaluations, the practical baseline is default-deny egress, synthetic target infrastructure, network-enforced allowlists, disposable credentials, complete connection logging and automatic stop conditions. Those controls let researchers measure increasingly capable agents while keeping the evaluation scope enforceable by the surrounding system.

Sources

• Reuters, September 18–19, 2026: Google confirmation and statements from Heather Adkins on the three incidents, notification and testing-process changes.
• The Wall Street Journal, September 18, 2026: original reporting on the May evaluation and Irregular's involvement.
• Irregular: public material describing its frontier cybersecurity evaluation work and scenario-based testing methodology.