Skip to main content

How Google's Gemini Reached Three Real Companies During a Security Exercise

· 14 min read
Harsh Zagade
Harsh Zagade
Kamgar @ Haxnation
// SHARE

On September 19, 2026, Google confirmed that a Gemini model accessed three real companies during a cybersecurity test after an unintended internet connection and a naming mix-up exposed real systems. The incident highlights a central risk of agentic AI: when an agent can discover and act on unexpected paths, technical safeguards—not the model's judgment alone—must enforce the boundary.

What Happened?​

The incident took place in May 2026 during a cybersecurity evaluation conducted by Irregular, an independent company that runs security evaluations for AI systems. Gemini was participating in a capture-the-flag-style exercise in which it was asked to retrieve information from software belonging to a fictional company.

The exercise was intended to be isolated from the public internet. According to reporting on the incident, however, internet access was unintentionally available.

There was another problem. The fictional company used in the exercise shared its name with a real business.

Those two failures created a dangerous combination. The path from a simulated target to real infrastructure can be summarized as follows:

Google said Gemini accessed three companies in total. In one case, it repeatedly guessed passwords until it gained access. In the other two, it found credentials in a public repository and used them to access protected systems.

The three companies have not been publicly identified.

How the Test Was Supposed to Work​

A cybersecurity evaluation involving an AI agent needs a much stronger boundary than a normal software test because the model can actively decide what to do next.

In a conventional capture-the-flag exercise, a participant might be given a deliberately vulnerable target and a defined scope:

The participant is expected to stay within that scope.

An autonomous AI agent changes the equation.

Instead of following a fixed sequence, an agent can:

That means the environment has to enforce the boundary. A model should not be expected to act as the final firewall between a simulated target and a real one.

In the Gemini evaluation, that boundary failed.

The Two Problems That Came Together​

1. The Test Environment Had Internet Access​

The exercise was intended to prevent Gemini from reaching external systems, but an unintended configuration issue made internet access available.

That meant a search for information about the fictional target could return information about a real organization.

This is important because the model did not need to deliberately "escape" a hardened sandbox in the traditional sense. The environment already exposed a route to the outside world.

Reuters reported that Irregular said the incident involved the same issue that affected other AI labs using its evaluations and that the known issues had been remedied.

2. The Fictional Target Shared a Name With a Real Company​

The second problem was the naming collision.

If a fictional organization used in a security test has the same name as a real organization, an AI agent with internet access can encounter an ambiguity that a human tester might immediately resolve by checking the approved scope.

For an autonomous agent, however, the distinction has to be explicitly and reliably enforced.

The combination looked roughly like this:

The important lesson is that scope cannot depend on naming conventions alone.

How Gemini Gained Access​

The most important technical detail is also one of the least exotic.

Gemini did not need a newly discovered zero-day to reach the companies.

Password Guessing​

In one case, Gemini guessed passwords for a protected system until it obtained access.

Password guessing is not a new attack technique. What changes when an autonomous agent performs it is the persistence and speed with which the activity can happen.

A human operator has practical limitations:

  • Time
  • Attention
  • Fatigue
  • Manual effort
  • The need to interpret every result

An agent can repeatedly test possibilities, analyze responses and continue toward its objective.

This does not make password guessing a new vulnerability. It makes an old weakness easier to automate.

Exposed Credentials​

In two other cases, Gemini found credentials in a publicly accessible repository and used them to access protected systems.

This is a familiar security problem: secrets that should never have been public were discoverable through normal internet reconnaissance.

The AI component changes the scale and speed of discovery, but the underlying issue is much older than agentic AI.

The chain is straightforward:

That is why secrets management remains important even in organizations that are not building AI systems.

The Part Google Emphasized: Gemini Stopped​

There is another important part of the incident that can easily get lost in the headline.

Google said that Gemini stopped in all three cases after determining that it had reached real companies rather than the simulated targets.

Heather Adkins, Google's vice president of security engineering, said that the model stopped in all three instances. Google also said the affected organizations were informed.

That makes the incident more complicated than a simple story about an AI model attacking random companies.

The model crossed the intended boundary, but its later behavior helped limit the incident.

Google's position is that this behavior demonstrated an important safety property: once the model understood that the systems were real, it stopped rather than continuing the task.

That distinction matters.

There are two separate questions:

  1. Why was Gemini able to reach a real company at all?
  2. What did Gemini do after it realized the target was real?

The first is an infrastructure and evaluation-design problem.

The second is a model-behavior and safety question.

Both matter.

This Was Not an Isolated AI-Security Incident​

Gemini's disclosure arrived after similar incidents involving other AI labs.

Reporting has connected Irregular's evaluations with incidents involving models from Meta, Anthropic and OpenAI. The details differ between cases, but the recurring theme is the same: AI systems participating in cybersecurity evaluations reached real-world infrastructure that was outside the intended test boundary.

That makes the story bigger than Gemini.

It raises a question about the security of the evaluation process itself.

If multiple AI labs use similar evaluation environments, and those environments can accidentally expose autonomous agents to the public internet, then the testing infrastructure becomes part of the attack surface.

The sequence is no longer simply:

It becomes:

That is the part security teams should pay attention to.

Why No Zero-Day Was Necessary​

It is tempting to interpret this incident as evidence that AI models are suddenly capable of discovering completely new classes of vulnerabilities.

The reported Gemini incidents do not support that conclusion.

The access methods included password guessing and credentials exposed in a public repository.

Neither technique requires a zero-day.

The more important development is the automation of existing techniques.

An AI agent can combine:

  • Reconnaissance
  • Search
  • Credential discovery
  • Target identification
  • Repeated attempts
  • Decision-making
  • Tool use

into a single workflow.

A human penetration tester might perform the same individual actions, but an autonomous agent can potentially execute the process continuously and adapt after each result.

That can change the speed, scale and cost of offensive activity.

The technique is old.

The operator is new.

The Real Security Problem: Authorization​

The central issue is not simply whether an AI model is "smart enough to hack."

It is whether the model can reliably distinguish between:

"This is my authorized target."

and

"This looks like my authorized target, but it is actually somebody else's system."

That distinction normally comes from strong security controls:

  • Network isolation
  • Explicit allowlists
  • Authentication boundaries
  • Egress filtering
  • Separate credentials
  • Dedicated domains
  • Monitoring
  • Human approval for sensitive actions

A model's own reasoning should not be the only thing preventing an unauthorized action.

If a test environment is supposed to have no internet access, the network should enforce that.

If a model is supposed to access only a specific host, the infrastructure should enforce that.

If credentials are created for a test, they should not overlap with production credentials.

The security principle is simple:

Do not ask the AI to enforce a boundary that the environment can enforce mechanically.

The Sandbox Problem​

Calling an environment a "sandbox" does not make it isolated.

A sandbox is only useful if its isolation is real.

For an ordinary application, an accidental network route might remain unused for months. An autonomous agent is different because its objective may naturally lead it toward that route.

Consider an instruction such as:

Find information about the target company.

If the agent has internet access, searching the public web is a reasonable action.

If the test environment contains a real company with the same name, the model can unknowingly move from:

The model does not need malicious intent for this to happen.

It only needs:

  1. A goal.
  2. Access to tools.
  3. A path to the internet.
  4. An ambiguous target.
  5. Enough autonomy to continue.

That is why containment has to be designed independently of model behavior.

What Organizations Can Learn​

The Gemini incident is not only relevant to AI companies.

The same lessons apply to organizations deploying autonomous security tools.

1. Treat AI agents like privileged users​

If an AI system can browse, execute commands, access APIs or interact with infrastructure, give it only the permissions it actually needs.

Do not assume that because the system is "AI" it should have broad access.

2. Enforce network boundaries​

If an evaluation or internal security environment is supposed to be offline, verify the restriction technically.

Use:

  • Egress filtering
  • Network segmentation
  • Deny-by-default firewall rules
  • Isolated DNS
  • Explicit destination allowlists

A label saying "offline environment" is not a security control.

3. Scan repositories for exposed secrets​

Credentials found in public repositories can become an immediate attack path.

Organizations should use automated secret scanning and rotate credentials whenever exposure is suspected.

A secret that has appeared in Git history should be treated as compromised, even if the visible file has been deleted.

4. Avoid ambiguous test targets​

Fictional organizations, domains and infrastructure should be checked against the public internet before an autonomous agent is allowed to interact with them.

The goal is to prevent:

from becoming a possibility.

5. Add human approval to high-impact actions​

For actions such as:

  • Authentication attempts
  • Credential use
  • Data deletion
  • Production changes
  • External system access

a human approval layer can provide another boundary.

The exact controls depend on the environment, but the principle is consistent: the more damaging the action, the stronger the authorization should be.

What Makes Agentic AI Different?​

The Gemini incident also illustrates the difference between a chatbot and an autonomous agent.

A conventional chatbot mostly operates like:

An agent can operate more like:

That feedback loop is what makes agentic systems powerful.

It is also what makes poorly designed boundaries more dangerous.

A model does not have to invent a novel exploit if it can already combine reconnaissance, credential discovery and tool use into a continuous workflow.

What This Incident Really Shows​

The most useful way to frame the Gemini incident is not:

"AI has learned how to hack."

That conclusion is too broad.

A more accurate interpretation is:

AI agents are becoming capable enough to turn ordinary security weaknesses into autonomous attack paths, which makes the security of their operating environment just as important as the model itself.

Gemini did not need a sophisticated zero-day.

It encountered real-world information, found credentials or guessed passwords, accessed systems it believed were within scope, and then stopped after recognizing the targets were real.

The most important failure therefore happened before the model reached those systems.

The boundary was not strong enough.

The Bigger Question for AI Security​

The industry is entering a phase where AI systems are not just answering questions about cybersecurity. They are increasingly being evaluated on their ability to perform cybersecurity tasks themselves.

That creates a difficult engineering requirement:

The better the agent becomes at finding paths toward a goal, the less acceptable it becomes to rely on assumptions about what the agent will not discover.

A secure evaluation environment has to assume that the agent will:

  • Search broadly.
  • Follow unexpected leads.
  • Discover exposed information.
  • Try alternative credentials.
  • Use available tools.
  • Continue when an obvious path fails.

The environment must therefore constrain what the agent can do, rather than simply telling it what it should do.

That is the larger lesson from the Gemini incident.

The model was capable of reaching systems outside the intended exercise.

The fact that it stopped is important.

But the stronger security question is why the environment allowed it to reach them in the first place.

Conclusion​

The Gemini incident is not a story about a machine suddenly becoming a superhuman hacker.

It is a story about what happens when an autonomous agent is given a cybersecurity objective inside an environment whose boundaries are not enforced strongly enough.

A fictional target shared a name with a real company. An unintended internet connection made that real company reachable. Gemini then used ordinary techniques—password guessing and exposed credentials—to access protected systems.

And once it recognized the systems were real, Google says it stopped.

That combination makes the incident valuable as a cybersecurity case study.

It demonstrates both sides of agentic AI security: the ability to automate familiar attack techniques, and the importance of safeguards that determine where an autonomous system is allowed to act.

As AI agents receive more access to browsers, terminals, APIs, cloud infrastructure and enterprise systems, the lesson becomes increasingly important:

Do not rely on an AI agent to understand the boundary. Build the boundary so the agent cannot cross it.

Sources​

// SHARE