Written by Jaiz Anuar

If Your AI Test Can Reach The Real Internet, It Is Not Really A Sandbox

Instructions can influence an AI agent, but only architecture can contain it. A credible AI security sandbox must make out-of-scope networks, credentials and tools technically unreachable.

A cybersecurity test is supposed to create a safe place to discover unsafe behaviour.

The target is controlled. The credentials are synthetic. The environment is isolated. Researchers can allow the system to behave aggressively because the consequences are contained.

That assumption becomes much more important when the thing being tested is an autonomous AI agent.

In May 2026, Google’s Gemini was being evaluated in a cybersecurity exercise run by Irregular. The test was intended to operate against simulated targets, but the environment unintentionally allowed access to the public internet. Gemini subsequently accessed systems belonging to three real companies before stopping after recognising that the targets were real. (SecurityWeek)

The interesting security question is not whether Gemini eventually stopped.

It is why the architecture allowed it to get there in the first place.

A Sandbox Should Enforce The Boundary

We often use the word sandbox as though it automatically means safe.

But a sandbox is only as effective as the boundaries around it.

If an AI agent can resolve public domains, establish unrestricted outbound connections, discover real credentials and interact with systems outside the approved scope, then the isolation exists mainly as an assumption.

That is not enough.

The agent should not need to understand that a target is out of scope. The architecture should make the target unreachable.

This principle is not unique to AI. In If a Security Scan Can Take Down Your System, What Will a Real Attacker Do?, I argued that security testing should reveal how systems behave under conditions that are less comfortable than normal operations. But realistic testing still needs controlled boundaries. The objective is controlled realism, not uncontrolled exposure.

AI makes that distinction even more important.

Instructions Are Not Containment

One of the emerging mistakes in AI security is relying too heavily on instructions.

Do not access production.

Do not contact external systems.

Only use the test environment.

Stop when the target is outside scope.

Those instructions are useful. They are not security boundaries.

An autonomous agent can misunderstand context, follow an unexpected reasoning path or interact with something the test designer did not anticipate.

This is where AI safety guardrails and security architecture need to be separated conceptually.

A guardrail attempts to influence behaviour.

A security boundary limits capability.

For a cyber-capable AI agent, the second matters much more when the first fails.

Default Deny Should Apply To AI Agents Too

A properly contained AI security environment should begin with a simple architectural assumption:

Anything not explicitly required for the test should be unreachable.

That means outbound connectivity should be restricted rather than broadly available. DNS resolution should be controlled. Test targets should be explicitly allowlisted. Credentials should be synthetic. Production identities should never be available to the agent.

The environment should also know exactly which tools the agent can invoke and which actions those tools can perform.

An AI agent with a browser is one risk.

An AI agent with a browser, terminal, credential store, code execution capability and unrestricted internet access is a very different risk.

Capability changes the threat model.

This is similar to the broader identity problem I discussed in The New Security Perimeter Is No Longer The Network. It Is Identity.. An AI agent becomes dangerous not simply because it is intelligent, but because of the identities, permissions and systems placed within its reach.

The Kill Switch Should Not Depend On The Agent

Another architectural question is who can stop the activity.

In the Gemini incidents, the models reportedly stopped after recognising that they had reached real companies. That behaviour limited the reported impact. (Ars Technica)

But an enterprise security design should not assume that the agent will always make that decision correctly.

There should be an independent mechanism capable of terminating the session, revoking credentials, blocking network access and stopping tool execution.

The control should exist outside the agent.

This is the same principle used elsewhere in security architecture: the system being controlled should not also be the only system responsible for controlling itself.

Logging Becomes Part Of Containment

Containment is also about visibility.

If an AI agent makes hundreds of autonomous decisions during a test, security teams need to know exactly what happened.

Which systems did it contact? Which credentials did it use? Which commands did it execute? Which tools were invoked? What data left the environment? At what point did its actions move outside the expected path?

Without that evidence, an organisation may know that something went wrong without being able to establish how far it went.

That turns an AI evaluation into an incident-response problem.

And once an external organisation is touched without authorisation, the exercise is no longer purely a simulation.

Third-Party AI Testing Is Still Your Risk

There is another lesson for enterprises adopting external AI testing platforms.

Outsourcing the test does not outsource accountability.

If a third party is running autonomous agents on behalf of the organisation, the architecture review should include the testing environment itself.

How is internet egress restricted? How are targets isolated? What credentials are available? Are production systems reachable? Who monitors agent activity? How quickly will the organisation be informed if the test moves outside scope?

These are not administrative questions.

They are architecture questions.

A provider saying that an environment is isolated should not be the end of the assessment.

The design should demonstrate how isolation is enforced.

Assume The Agent Will Eventually Do Something Unexpected

Good security architecture does not depend on every component behaving perfectly.

That principle becomes even more important with autonomous AI.

An AI agent may follow the expected path thousands of times. The architecture still needs to survive the one time it does not.

This is consistent with a broader principle I have written about before: security architecture should assume controls will eventually fail. The objective is therefore not only to prevent failure, but to limit what happens next.

For AI security testing, that means assuming the model may misunderstand scope, select the wrong target or invoke an unexpected tool.

The architecture should still contain the outcome.

Final Thoughts

The most reassuring part of the Gemini story is that the models reportedly stopped once they recognised that they had reached real companies.

The more important architectural lesson is that they were able to reach those companies at all.

AI safety should not depend entirely on the AI making the correct decision.

Network boundaries should restrict where it can communicate. Identity controls should restrict what it can authenticate to. Tool permissions should restrict what it can execute. Logging should reveal exactly what it did. Independent controls should be able to stop it.

The more autonomous the AI becomes, the less we should depend on instructions alone.

Because a sandbox is not defined by what we tell the AI not to do.

It is defined by what the architecture makes impossible for it to do.

Question assumptions. Share knowledge. Build trust.