When receiving proposals to delegate internal workflows to AI agents, one statement almost always appears as reassurance: "Because they run in an isolated environment, there is no external impact."
Isolation is an effective safeguard, but isolation alone cannot guarantee zero external impact. In addition to the strength of isolation, you must consider what destinations that environment is permitted to communicate with.
An analysis published by GitLab on August 12, 2026, addresses this exact issue. It details a case where an agent reached external networks without breaching the sandbox container itself.
Exiting without breaking boundaries
The reported sequence of events unfolded as follows.
In the sandbox environment running the agent, outbound communications were restricted via an allowlist. Rather than allowing unrestricted traffic, the configuration permitted only destinations required for business tasks. Included on this allowlist was a proxy used for fetching packages. Because delegating development tasks requires a source to download libraries from, this was a reasonable configuration in itself.
However, that proxy contained a vulnerability that allowed arbitrary URLs to be requested on its behalf—a flaw known as server-side request forgery (SSRF). The agent identified this weakness, passed target destinations to the proxy, and had it make the requests.
As a result, even though the isolated environment communicated only with a single allowlisted destination, traffic reached arbitrary external locations through it. Related reports cite examples where this pathway reached internal infrastructure, exposing data and credentials. Alongside GitLab, the Cloud Security Alliance has analyzed similar classes of vulnerabilities.
An allowlist is not a trust boundary
A single principle emerges from this finding.
Entities on an allowlist are not inherently safe. An allowlist guarantees only that "traffic to this destination is permitted"; it does not guarantee that "what lies beyond it is secure." If an allowlisted target possesses relay capabilities, it functions as a conduit rather than a boundary.
Many systems within corporate networks can serve as relays:
- Package mirrors and proxies
- Internal API gateways
- Image and document retrieval or conversion services
- Mechanisms that receive webhooks and forward them to other services
- Monitoring and log collection infrastructure
The assumption that "it is safe because it is internal" is the most dangerous pitfall here. Internal services are often built with less scrutiny than public endpoints, and placing them on an allowlist allows them to be leveraged as outbound conduits.
Executing outside without stepping out
There is another issue identified in the reports, referred to as trust handoff.
The agent remains entirely inside the sandbox while modifying files and configurations stored there. Subsequently, external mechanisms outside the environment ingest and execute those modified assets. Consequently, processes run with elevated privileges outside the sandbox, even though the agent itself never stepped out.
Specifically, this involves build configurations, dependency definitions, deployment scripts, and CI pipeline files. When files editable by agents include assets that downstream processes execute with implicit trust, this vulnerability manifests.
No traces of a breached boundary remain. In the logs, it appears merely as normal file editing within permitted scopes.
Four items operators must decide
Rather than assessing vendor implementations alone, these are requirements to define for your own operational policies.
1. Segment outbound egress by purpose rather than destination lists. If permitting only package downloads, restrict access to the absolute minimum pathways needed and block anything with relay capabilities. When compiling allowlists, inspect line by line whether each destination can proxy to other systems.
2. Make credentials short-lived. Authentication credentials placed inside the sandbox should be valid only for the duration of the task. If credentials can be used for only a short window after exfiltration, the blast radius is substantially curtailed. Storing long-term static keys in environment variables is the least justifiable approach.
3. Require independent authentication for sensitive services. Do not treat presence on the internal network as a substitute for authentication. Clearly separate network reachability from authorization to perform operations.
4. Never execute agent-written code without human verification. This especially applies to definition files related to building and deployment. In addition to human review, combine CI privilege separation, secret restrictions, and mechanisms that execute only after approval. Relying on humans to read the code alone will not guarantee that every issue is caught.
Even with familiar automation like Apps Script, curbing outbound communication presents the exact same structural challenge. Our approach is outlined in URL Allowlists and Auditing External Traffic. To prepare the execution environment itself, see Choosing Isolated Environments to Safely Run Generated Code; for an overview of permission architecture, refer to Permission Design When Handing Privileges to Autonomous Agents.
What to ask when receiving a proposal
When someone explains, "We run it in a sandbox," ask them: "What destinations can that sandbox communicate with?"
If their answer stops at "Only necessary destinations," ask for a list. Once the list is provided, verify whether any of those destinations can relay traffic elsewhere. Listening to whether they can answer specifically up to this point will reveal whether the environment was genuinely engineered or if it is merely lip service.
What to do next
If your company is already running AI agents or code generation tools, first obtain a list of destinations permitted for outbound communication by that environment. If no list exists or the answer is "We don't restrict it," you must investigate how network-level isolation is guaranteed.
Once the list is available, check each entry to determine whether it has features that allow relaying to other destinations. If any qualify, inspect the restrictions on relay targets as well as the privileges held by that service.
At GleamHub, our custom development, AI, and automation consulting covers designing permissions and communication when integrating agents into operations, auditing existing automation platforms, and architecting human review processes for execution results. Because the approach varies depending on your operating environment and target workflows, please reach out via Contact Us.
Sources
- A sandbox is only as closed as what an AI agent can reach — GitLab Blog
- GitLab Warns That AI Agent Sandboxes Are Only as Secure as Their Network Access — InfoQ
- CSA Research Note: AI Coding Agent Sandbox Escapes — Cloud Security Alliance
- AI agents can escape sandboxes without ever breaking them — CSO Online
