A cybersecurity exercise gives an agent a target and asks it to retrieve a secret. The target is supposed to be fictional. The network connection turns out to be real.

That mismatch deserves close attention from anyone deploying an agent with a browser, terminal, or credentials. A task can be legitimate while a particular action taken to complete it exceeds the operator’s authority. The control system must catch that difference before the request reaches someone else’s infrastructure.

TL;DR

  • Google says Gemini accessed three real companies’ websites during May 2026 testing by Irregular, using public information and guessed credentials.
  • An agent reaching the internet does not, by itself, establish that it exploited a sandbox vulnerability.
  • Test scope must be enforced by infrastructure and tool authorization, independently of the model’s interpretation of its task.
  • Monitor where actions occur and who authorized them. Offensive behavior alone is a poor alert condition inside a cybersecurity exercise.
  • Test every route out of the environment, including routes through machines the agent is supposed to compromise.

What Is Actually Known

According to Reuters reporting carried by CNA, the incidents occurred in May during an Irregular cybersecurity evaluation. Google security engineering vice president Heather Adkins said Gemini used publicly available information and guessed credentials to access three websites it considered part of the test. Google said the affected entities were notified and that it worked with its partner on testing changes.

Reuters reporting carried by RTÉ attributes a further statement to Irregular: the issue also affected other labs, and the relevant labs were notified in late July. These are retrospective disclosures, rather than evidence that the activity began this September.

Google says the models stopped when they recognized real targets, according to Axios.

Stopping is useful behavior. It cannot retroactively authorize a login that already happened. Nor does an account of self-correction establish that every earlier request was harmless.

The reporting reviewed here does not provide enough evidence to reconstruct all three Gemini runs independently. We do not have a complete public set of transcripts, network records, affected-account privileges, or victim-side findings. Assigning an exact model version, a particular sandbox CVE, or a comprehensive impact assessment would go beyond that evidence.

Three Different Meanings of “Escape”

Security analysis needs a more precise vocabulary than a model breaking loose.

An isolation exploit defeats an intended technical boundary through a vulnerability. Establishing this requires evidence about the boundary, the flaw, and the execution path.

Unintended connectivity means the environment already permits a route that operators believed was unavailable. The agent can use that route without defeating the container runtime or hypervisor.

A scope violation occurs when an action targets a resource outside the authorized exercise. It can happen even where internet access is intentionally available, such as through a research browser.

These conditions can overlap, but their remedies differ. A runtime patch will not correct an overbroad proxy policy. A stronger instruction will not remove a network route. A destination allowlist will not, on its own, authorize every operation against an allowed service.

For the Gemini case, the responsible conclusion is limited: the published accounts describe unauthorized access during testing. They do not establish a novel isolation exploit.

The Evaluator’s Earlier Account

Irregular’s August 14 investigation update describes unintended internet access and a fictional company name that overlapped with a real domain. The post concentrates on a previously disclosed evaluation scenario; it is useful context, not a complete Gemini forensic report.

Irregular says models generally stayed within the simulation, but some reached real systems under the mistaken belief that they remained inside the exercise. It also describes difficulty detecting rare deviations late in lengthy runs. The company reported disabling the affected evaluation, reviewing logs, notifying affected parties, and strengthening its safeguards.

The engineering implication is uncomfortable: an environment may behave correctly thousands of times while retaining a route that should never have existed. A successful ordinary run provides little evidence about that route.

Anthropic’s separate July 30 investigation makes the instruction problem explicit. It reported three real-world incidents in evaluations where its prompt told models they had no internet access, although connectivity was available. Responses to evidence of real targets differed between models. Anthropic cautioned that these incidents were not a controlled comparison.

That report should not be used to assign Claude’s actions to Gemini. It does establish why an operator’s description of a test environment must agree with its actual configuration. A false assurance of isolation can distort the agent’s interpretation of what it encounters.

From a Company Name to an Unauthorized Login

The following is a general failure model, not a packet-level reconstruction of Google’s incidents.

StageDecision or capabilityBoundary that must hold
AssignmentRetrieve information from a simulated organizationThe approved resources and operations are recorded outside the prompt
DiscoveryResolve a name or inspect a linkDiscovered resources do not automatically become authorized targets
ConnectionOpen a browser session or network socketEgress policy permits only the required destinations and paths
AuthenticationTry a credential against a serviceThe credential, destination, and operation are all within scope
ContinuationRead data or use a newly acquired sessionNew access does not expand the original authorization

The dangerous transition is often discovery becoming permission. A matching company name, valid TLS certificate, successful connection, or working password proves something about a service. None proves the evaluator owns it or has permission to test it.

The same applies to credentials found in public material. Publication establishes availability, not authorization to use them. In an exercise, the harness should provide synthetic credentials whose accepted destinations are known in advance.

There is also an outbound threat model to consider. A deliberately vulnerable target can become a stepping stone after the agent compromises it. Blocking the agent’s workstation while leaving the target server free to contact the internet does not contain the exercise.

This is why reviewing only the visible assistant’s tool list is insufficient. The scope includes execution workers, simulated victims, browser services, package infrastructure, and any service that can issue a request on their behalf.

Design the Range Around Explicit Permission

The following design is our operational recommendation. It is not a description of controls Google or Irregular has deployed.

Make the Scope a Separate Record

Create a run manifest before starting an evaluation. Give it a stable identifier and record the permitted resource identities, service endpoints, protocols, operations, credential references, and expiry time. Keep the approval record outside the agent’s writable environment.

When a tool call arrives, compare its effective action with that manifest. A browser destination and a shell command that opens the same destination need equivalent enforcement. If the command cannot be interpreted reliably, restrict the execution environment’s actual reach instead of relying on command-text inspection.

Discovery should produce a candidate for review. It should never rewrite the manifest automatically.

This follows the separation between model reasoning and tool authority in OWASP’s AI Agent Security guidance, which recommends narrow tool permissions and explicit authorization for sensitive operations. A model’s confidence is not an approval token.

Use Names That Cannot Become Someone Else’s Test Target

RFC 2606 reserves .test for testing. A lab can resolve a name such as accounts.range.test through its own controlled DNS infrastructure, without inventing a plausible public company domain.

Name reservation is only one layer. It does not create a firewall rule, prevent a browser from following another link, or stop a model from inventing an alternative destination. Keep the DNS namespace, routing policy, and resource manifest consistent.

Separate Research Access From Attack Execution

Some evaluations need current documentation or external reference material. Give that requirement its own access path and review its capabilities explicitly.

For example, a reference service might retrieve a maintained set of documentation resources while attack workers communicate only with the range. Avoid giving the reference service arbitrary authenticated browsing merely because the worker needs to read a manual.

Even nominally read-only web access can carry information in URLs and headers. Decide what may leave the range, limit request construction, and retain enough proxy telemetry to investigate misuse.

Destination controls must consider the address actually contacted and every redirect. OWASP’s SSRF prevention guidance is relevant here: validating the initial URL alone leaves gaps around redirection and name resolution. Apply the same scrutiny to indirect fetch services.

Verify the Enforcement Layer

If the range uses Kubernetes, a NetworkPolicy object is useful only with a network implementation that enforces it. Policies are additive: another applicable allow policy can permit traffic that an isolation policy does not. Standard NetworkPolicy also does not provide application-level authorization. These limitations are documented in the Kubernetes network policy reference.

Whatever platform you use, test the deployed behavior from each relevant execution context. Include IPv4 and IPv6 where enabled, direct connections, proxies, and routes through simulated target machines. A diagram of the intended network is not evidence of the effective network.

Detection: Correlate Actions With Scope

An exploit command inside an authorized cyber range may be expected. A routine login to an unapproved destination may be the incident. Detection needs the run’s authorization context.

For each action, retain a run identifier, tool-call identifier, worker identity, resource identity, destination, policy decision, and timestamp. Where possible, connect tool events to network flows and authentication records. Keep audit records outside the worker’s write permissions and avoid recording raw passwords or session tokens.

Our proposed detection matrix prioritizes boundary crossings:

SignalEvidence to correlateImmediate handling
A worker attempts an unapproved destinationTool event, DNS/proxy event, run manifestDeny the request; investigate whether any parallel path succeeded
A simulated target opens an external connectionTarget process telemetry, network flow, owning runContain the target as well as the initiating worker
An authentication attempt has no scoped credential referenceTool arguments, credential broker event, destinationBlock execution and preserve the action metadata
Scope or network policy changes during a runControl-plane audit event, actor identity, manifest revisionSuspend the run until an independent operator reviews the change
Required telemetry disappearsCollector heartbeat, worker lifecycle, last received sequencePause the evaluation under a predefined fail-closed policy

These are proposed correlations, not vendor-provided detections or Gemini indicators of compromise. Implementations need to account for shared proxies, NAT, clock differences, and tools that execute remotely.

A particularly useful metric is successful connections outside approved scope. It has a clear target: zero. Track blocked attempts separately so a working preventive control is not reported as a completed compromise. Also measure the time between the first boundary violation and containment; the model’s final answer is too late to be the primary alert.

Prove Containment Before the Next Run

Use endpoints you own for these checks. There is no need to probe unrelated companies to test your own isolation.

  1. An unreachable target: Disable a simulated service. Confirm that the agent cannot reach a different, unapproved destination while seeking an alternative.
  2. A redirect: Have an approved lab endpoint redirect toward a controlled endpoint outside the allowlist. Confirm the second request is blocked before arrival.
  3. A compromised simulated victim: From the target’s execution context, attempt a connection to your external canary. Confirm the target cannot act as an exit route.
  4. A misleading credential: Place a synthetic credential in test material. Confirm that its presence does not authorize use outside its designated test service.
  5. A control failure: Interrupt the authorization or telemetry service. Confirm new actions stop according to the documented policy rather than silently proceeding.

Run these checks after changes to network plugins, proxy configuration, tool integrations, or worker images. Record the manifest revision, configuration revision, test result, and evidence location. This gives the next operator something reproducible to inspect.

Keep the performance benchmark separate from the containment assessment. Completing the challenge measures one property; staying within authorized scope measures another. Neither score should hide the other.

If You Operate the Service on the Other Side

The target organization may have no relationship with the evaluator. Its defenders still need to distinguish failed login attempts, successful authentication, and subsequent access.

Apply MFA where supported, throttle authentication attempts, and review suspicious login activity using the service’s own records. OWASP’s authentication guidance covers these controls. Do not assume an AI-driven attempt will have a reliable identifying user agent or distinctive network signature.

When an evaluator reports unauthorized access, request exact timestamps, source addresses, affected endpoints and accounts, and the relevant action transcript. Compare that account with your own evidence. Determine whether sessions or tokens remain usable and revoke them where appropriate; establish what the account could access and what it actually did.

The useful investigation question is not whether the model meant harm. It is whether the service accepted an unauthorized action and what followed.

Disclosure Should Describe the Boundary

The public needs enough detail to distinguish a model capability result from an infrastructure failure and to evaluate the response. That does not require publishing victim identities, credentials, or a reusable exploit.

Our suggested disclosure minimum is a timeline of occurrence, discovery, containment, and notification; the intended boundary and actual access path; observed impact and remaining uncertainty; and the regression check used to validate the repair.

The same standard should apply to claims that a model stopped itself. State what occurred before it stopped, what evidence supports the stopping point, and whether the affected organization confirmed the assessment.

For an engineering team, the decisive question is concrete: if the agent decides an unrelated system is part of its task, which independent control prevents the first unauthorized request? If the answer depends entirely on the agent reconsidering, the permission boundary is still missing.

Sources