The Sandbox Was Also an API Key

The Sandbox Was Also an API Key

5 min read

A sandbox escape is usually described as a containment failure.

The alleged OpenAI finding circulating this week adds a second failure to the story: according to security researcher Oliver Fish, escaping the sandbox also made it possible to request paid models without an API key or an account.

That claim is not a confirmed breach report. The public material does not identify the endpoint, the affected models, the exposure window, or a CVE. But the reported shape of the bug is worth examining because it exposes a common mistake in agent infrastructure: treating the sandbox as if it were also an identity system.

It is not.

What is alleged

Cyber Security News reported on October 7 that Fish found an OpenAI sandbox escape and received a $300 reward for a report titled “Unauthenticated Sandbox Escape Enables Access to Internal OpenAI Responses API.” The report says the route could request paid model inference without a customer API key.

Fish’s own post on X was quoted in that coverage. Cyber Security News also posted the claim on X, describing the issue as a combination of sandbox isolation and API authentication boundaries.

The available evidence supports a narrower statement:

A researcher claim, repeated by a security publication, says an OpenAI sandbox escape reached an internal Responses API route without normal customer authentication.

It does not support claims about mass exploitation, customer data access, a specific vulnerable product, or the current status of the route. Those remain open questions.

The two boundaries that should not be the same

An agent service often has at least two distinct control problems:

untrusted code or model action
            |
            v
      execution sandbox
            |
            v
      internal service route
            |
            v
      model inference and billing

The sandbox answers: what can this process do to its execution environment?

The API authentication layer answers: which principal is allowed to invoke this capability, under which project, quota and spending policy?

Those are different questions. A process can be contained and authenticated, or escaped and still authenticated. It can also escape and reach a route that trusts network location instead of a real caller identity.

The alleged OpenAI case matters because it appears to join the two failures. If an escaped process can invoke a privileged internal route merely because it came from an expected network position, then the sandbox has become an accidental bearer credential.

That is a fragile design. The first boundary is expected to fail eventually, whether through a software bug, a misconfiguration or a model driven exploit. The second boundary should still reject an unknown caller.

Internal does not mean trusted

OpenAI’s Responses API documentation describes an endpoint that creates model responses and can invoke tools such as web search, file search and custom code. The same reference documents cyber access programs whose availability depends on organisation and project authorisation.

That is the public, customer facing contract. The reported issue concerns the path behind it, where internal services may call one another without presenting the same customer identity.

This is a familiar cloud architecture shortcut:

external request -> authenticated gateway -> internal service

sandboxed worker -> internal service

The first path carries an identity. The second path is sometimes allowed because the worker is supposed to be running inside a trusted environment. That assumption turns the runtime boundary into a credential.

Once the worker can escape, the caller has not merely left its box. It has inherited the authority of the box’s network location or service account.

The uncomfortable truth is that private routes are not an access-control policy. They are only a routing decision.

Why the reward is not the severity score

Cyber Security News says the public material does not include technical details, a proof of concept, a vulnerable endpoint, an affected model list, a CVE, an exposure period or a patch note. It also reports that the researcher criticised the $300 reward.

The payment does not tell us whether the issue was harmless or catastrophic. A reward programme may classify the impact differently from the report title, or the route may have had controls that are not visible in the public account.

The right question is not whether $300 sounds large enough. It is whether the provider can show that every internal model invocation requires a verifiable principal, even when the request comes from a sandbox, worker pool or service mesh identity.

If that proof does not exist, the billing boundary is weaker than the public API suggests.

What agent operators should test

The lesson applies beyond one provider. Any agent platform that runs untrusted code beside privileged model or tool services should test these paths independently.

  1. Break the worker, then recheck identity. A compromised worker must not inherit the privileges of its host, namespace or service account.
  2. Require identity at every hop. Internal routes should validate a short lived workload identity and the intended project or tenant, not only a source IP or network segment.
  3. Separate execution from billing. A sandbox escape should not create a path to free inference, uncapped spend or another tenant’s quota.
  4. Log the principal, not just the pod. Incident responders need the customer, project, workload and authorisation decision for every model request.
  5. Make the verifier independent. The component deciding whether a request can invoke a model should not trust the component that launched the sandbox.

These checks are more durable than adding another deny rule to the sandbox. A deny rule can reduce the chance of escape. It cannot repair an internal API that accepts location as proof of identity.

The boundary that matters is the next one

The reported OpenAI issue remains alleged. There is no public technical writeup proving the endpoint or showing that unauthorised requests reached customer workloads. That uncertainty should stay in the article, not be removed for dramatic effect.

The architecture question is still clear.

A sandbox is a containment mechanism. An API key is an identity mechanism. A service that lets the first stand in for the second has coupled two controls that should fail independently.

Agent security is not achieved when the model stays inside the box. It is achieved when every consequential capability asks who is calling, what they are allowed to do and whether the action can be reconstructed later.

The sandbox should contain the worker. It should never be the worker’s API key.

Sources

Keep reading

When the Agent Can Turn Off Its Own Cage: The DeepSeek Harness Sandbox Escape The Prompt Template Was an RCE Boundary Containment Is an Identity Problem, Not a Sandbox Problem