The full story
Background
A Series A startup offered an AI coding assistant that generated code, ran it, and returned execution results to developers. Its 24-person engineering team maintained the editor experience, model integrations, and a shared service that created short-lived execution containers.
The Head of Security engaged Bugb Technologies before a broader enterprise rollout. The assessment focused on the execution service: could submitted code reach outside its sandbox, obtain service credentials, or keep consuming resources after its allowed runtime?
Generated Code Was Untrusted Code
The team treated code produced by a model the same way it treated code submitted directly by a user. Neither source justified access to the host, other jobs, or the worker's credentials.
A container boundary alone did not answer those questions. The service selected mounts, inherited environment variables, and controlled job lifetimes. A mistake in that surrounding configuration could undermine isolation even when the container runtime behaved as designed.
Standing Up the Execution Service
The team gave Bravos the execution-service repository without a prepared pentest environment. Bravos established a local service, job queue, worker, and container runtime, then created authenticated test users and disposable execution jobs.
The assessment used a dedicated local host, synthetic credentials, and harmless marker files outside the assigned sandbox. Resource probes had independent stop conditions so a failed application limit would not become an uncontrolled load test.
Bravos orchestrated the assessment end to end. Developers did not have to assemble the environment or manually sequence the individual probes.
Mapping and Testing the Boundaries
GuardLink wrote threat annotations into the repository where untrusted job inputs reached process creation, container mounts, environment construction, and execution controls without the required restriction. Bravos built a code graph and prioritized the paths most likely to cross a trust boundary.
Bravos then drove Cert-X-Gen through authenticated job submissions and live probes against the running service. Six candidate escape paths were investigated. One demonstrated access outside the sandbox; the other five did not reproduce an escape under the tested conditions and were not reported as confirmed vulnerabilities.
The distinction mattered. A suspicious mount or launcher path was a reason to test, not proof that an attacker could use it.
Three Confirmed Findings
The assessment established three distinct failures:
- Sandbox escape through an exposed runtime socket: the job container could reach the host's container-management socket. A controlled probe used that access to start a separate container with access to a test-only host directory and read a marker unavailable inside the assigned sandbox. The returned marker proved that user code could bypass the intended isolation boundary.
- Execution-environment secret exposure: the launcher passed the worker's environment into user-code containers, including a seeded service credential. Submitted code read that credential and returned it in the job output. The evidence demonstrated the inheritance flaw without using a production secret.
- Missing server-side runtime enforcement: a job intended to stop after 120 seconds continued executing until the assessment stopped it at 180 seconds. The client timeout ended the request, not the worker process. This established a resource-control failure; the assessment did not claim to have demonstrated a production outage.
Each finding included the entry point, relevant configuration or code path, probe conditions, and observed result. Bravos did not report a theoretical escape as though it had succeeded.
Hardening the Service
Engineering removed the container-management socket from execution containers and kept runtime control in the trusted worker. User jobs no longer had an interface for creating containers or selecting host mounts.
The launcher switched from inheriting the worker environment to an explicit set of non-sensitive execution variables. Service credentials stayed in the worker rather than entering the sandbox.
The team also enforced the 120-second deadline server-side, terminating the job's processes and reclaiming its container when the limit was reached. The assessment covered these concrete changes rather than treating a new sandbox label as evidence of isolation.
Verification Within One Sprint
All three fixes were completed within 10 business days. Cert-X-Gen retested the updated service with the original probes and permitted coding workflows.
The socket-based escape could no longer reach the runtime interface, the seeded credential was absent from the execution environment, and the long-running probe was terminated at the enforced deadline. Ordinary short jobs still returned their output successfully. All 18 targeted remediation checks passed.
The result closed the three demonstrated findings. It did not turn the five unreproduced escape candidates into a guarantee against every possible escape.
Continuous Testing of Execution Changes
The startup added Bravos assessments before releases that changed the launcher, execution image, mount configuration, or job-control logic. GuardLink's in-code threat model kept those boundaries visible in pull requests, and Bravos repeated live testing on the corresponding running build.
GuardLink and Cert-X-Gen are open source. Bravos supplied the orchestration that turned code analysis, environment setup, and live probes into a usable assessment. The Head of Security gained a clear distinction between a concern worth investigating, a proven vulnerability, and a fix verified through observable behavior.