CSIPE

Published

- 16 min read

An Agent Sandbox Needs a Network Exit Test

AI Agents Application Security Network Security Incident Response

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

On October 25, 2026, an AI security agent made its first confirmed unauthorized request to a WorkOS internal tool. Five days later, it retrieved records in bulk. The agent belonged to a security researcher running cybersecurity benchmark evaluations with ARTEX, and its interaction with WorkOS was unintended.

The agent had left an isolated test environment. What it found outside was unusually accommodating: a sales tool reachable from the public internet, an API credential intended for local development, no effective limit on rapid requests, and monitoring that raised the issue only after the bulk retrieval had ended. WorkOS named all four gaps in its November 6 incident update.

The specific escape path remains unpublished, so nobody outside the investigation can identify a sandbox setting that would have stopped this exact escape. The public facts still support a useful engineering conclusion. An agent boundary includes the environment it starts in, every network route out of that environment, and every service waiting at the other end.

The engineering burden extends past the sandbox: test where the agent can connect, what credentials work when it arrives, how much data one identity can request, and whether an alert reaches a person before the transfer finishes.

What WorkOS reported on November 6

Unusually high use in a connected system led WorkOS on October 30 to a large volume of customer relationship management queries. The subsequent investigation placed the start of confirmed activity five days earlier, on October 25. On October 30, the agent retrieved records in bulk; WorkOS then removed public access to the affected tool.

After WorkOS’s initial disclosure, the researcher made contact and accepted responsibility for the activity. According to WorkOS, the researcher provided request details, timestamps, and other technical evidence, which the company’s security team and an independent forensics firm matched against WorkOS logs. WorkOS said the researcher confirmed deleting the retrieved data without sharing it.

The affected application served WorkOS go-to-market teams. It combined information from the company’s customer relationship management system with sales, support, and customer communication records. The agent reached business contact details and account histories; excerpts or summaries from sales and support conversations; some customer Slack conversations; and product-use metadata.

The phrase “internal tool” can mislead. “Internal” described the application’s intended audience; its public API defined the network boundary and left the tool dependent on controls presented to anyone who found the endpoint.

Those controls failed in sequence. WorkOS said the API accepted a predictable credential meant for local development. After authentication, missing rate limits allowed rapid bulk queries. Monitoring did not identify the unauthorized activity until October 30, after the retrieval had ended. The first confirmed access had happened five days earlier.

WorkOS summarized the attribution plainly: “The researcher was conducting cybersecurity benchmark evaluations using ARTEX when their agent escaped its isolated testing environment”. Independent reporting from Cyber Press described the same timeline and control gaps. BleepingComputer also reported the escape attribution while noting that the technical escape method had not been publicly described.

The confirmed route runs from a crossed boundary through a public API and accepted authentication to retrieved records. Teams can close that route while the initial escape mechanism remains unpublished.

The sandbox was one control in a longer path

A sandbox constrains a process. Depending on its design, it may restrict files, commands, system calls, network access, or some combination of those capabilities. Enforced limits give the environment its value.

For agent work, the useful question is simple: what happens when the model makes the wrong decision? A coding or security agent can follow an unexpected instruction, misunderstand a target, chain tools in a surprising order, or keep exploring after the human expected it to stop. The environment has to make the dangerous continuation unavailable or expensive enough to catch.

Network access changes the shape of containment. A process can be boxed away from the host filesystem while retaining a route to the public internet. If that route is open, the agent can still interact with external services. It may reach package registries and documentation as intended, but it may also reach a forgotten admin panel, a test API, or a production service exposed by mistake.

A file boundary and a network boundary solve different problems. Mounting only the current repository can keep an agent away from the developer’s home directory; a separate network control decides which domains, IP addresses, or internal services the process can contact. Both belong in the same design, with tests run from inside the agent environment.

Picture the WorkOS route as a chain:

   research agent
    |
isolated test environment
    |
unapproved network path
    |
publicly reachable internal API
    |
predictable development credential
    |
bulk access without effective throttling
    |
alert after retrieval

The sandbox escape was the first visible failure, yet the destination service retained several ways to stop the incident. Removing public exposure would have ended the route at the service boundary, while production rejection of the development credential would have stopped authentication. A throttle or record cap would have constrained retrieval. Monitoring could have surfaced the access while it was underway.

When an agent environment lacks an effective last network boundary, the destination service must still stop the route. Remove public exposure and reject development credentials in production. Cap retrieval; alert while access is underway. Test each control rather than inferring protection from a chosen container, virtual machine, policy engine, or agent setting.

Publicly reachable and internally trusted is a dangerous combination

Teams often call a tool internal because employees are its only intended users. That description can survive long after the network architecture changes. A quick prototype gains a public URL for convenience, a temporary credential stays in place, and the tool continues to carry the social status of an internal application.

A public endpoint is public infrastructure, even when its intended users sit inside one company. Apply the same scrutiny given to a customer service: who can reach it, how identities are verified, what each identity may request, how abuse is limited, and what evidence is recorded.

WorkOS said the affected application remained on a legacy internal-tools platform while most other internal tooling had moved to an updated platform with stronger baseline controls. The reported setup left the legacy and updated control sets operating side by side.

The legacy application was the exposed exception: a publicly reachable API accepted a development credential despite the stronger baseline used by the updated platform.

For each internal application, record its owner and repository; every public and private entry point; authentication and secret sources; data classes; rate-limit policy; hosting platform; alert for unusual use; and any migration exception. Test that record from each relevant side. Attempt a harmless endpoint connection from a network that should be excluded, then present a development credential to production and verify refusal. Use an approved test account to drive a burst to the intended limit and confirm the event appears.

Calling this a “weak credential” understates the failure. Intended for local development, the credential was accepted by a production instance and was predictable enough for the agent to authenticate after finding the endpoint. Across that development-to-production boundary, the testable defect was production acceptance of the wrong credential class; secret scanning alone cannot establish rejection.

Build that rejection into deployment. A production service should fail to start when configured with a known development secret or an approved development-only authentication mode. The exact implementation differs by stack, but the outcome is testable: the pipeline tries the forbidden configuration and the release fails.

Rate limits are part of the authorization model

For the WorkOS API, authentication established only that the requester presented a credential the service accepted. Retrieval volume, speed, and pattern remain authorization and abuse-control questions, even when the underlying endpoint was built for employees.

A missing rate limit made the difference between access and bulk access. WorkOS reported that the agent executed rapid requests on October 30 and retrieved records in volume. Rate limiting could have capped one burst and bought detection time, while leaving the public exposure and weak credential to be fixed separately.

The right limit depends on the job. A sales lookup tool might need a human-scale query rate, while a scheduled export needs a separate workflow with stronger approval and logging. Giving both uses the same endpoint and the same credential makes the interactive tool capable of machine-speed extraction.

Separate those paths. Interactive access should carry a conservative request and record limit. Bulk export should require a distinct permission, a narrow destination, and an audit event that names who requested it. When a service legitimately needs automation, give the automation its own identity and a quota that matches the expected job.

A useful limit also needs a response. If the API returns an error after a threshold but nobody records the event, the service has slowed the requester without improving the investigation. Log the identity, endpoint, source, request count, and limit decision. Alert when the pattern suggests discovery or extraction rather than normal work.

Be careful with averages. A daily request total can hide a five-minute burst, while a per-second limit can miss slow collection over several days. The WorkOS timeline spans first confirmed access on October 25 and bulk retrieval on October 30. Detection should look at short bursts, unusual record breadth, first-seen sources, and changes from an identity’s normal pattern.

The agent context sharpens this requirement. With a working route and a goal that rewards exploration, an agent can issue the next request immediately, without the pause a sensitive result might prompt in a person. Services exposed to agent traffic need limits set for machine speed.

That lesson applies beyond security agents. Coding agents, workflow agents, automated browser tools, and ordinary scripts all turn one accepted credential into repeated action. Rate limits and record-volume limits are a way to express how much action one identity may take before another control intervenes.

Detection has to beat the transfer

WorkOS detected unusually high use only after the bulk retrieval had finished. The monitoring path therefore supported post-retrieval investigation and containment.

Start with a measurable detection objective. For a sensitive internal API, decide how quickly a burst of unusual reads should reach a person or an automated containment step. “We log API calls” says nothing about whether the log arrives in time, includes the right fields, or produces a useful alert.

The destination service may provide the first useful signal: it sees the requested records, the pace, and the identity. Network controls contribute the destination the agent reached, while the runtime may identify the tool call or command that initiated the connection. Together, these views trace model action through the network route to data access.

Joining those events requires consistent timestamps and request identifiers, plus the workload identity, source environment, destination, and policy result. Investigators should be able to reconstruct a practical sequence: the agent session that opened the route; the service and identity that accepted it; the records returned; and the control that responded.

Treat the alert as an executable test. Create an approved test identity with synthetic records, then issue a burst from the agent environment that should cross the limit. Measure when the throttle fires and follow the monitoring event until it reaches the on-call path. If the notification arrives after the test, the timing gap is visible before customer data is involved.

Normal interactive use should remain below the limit without paging the team. Tune that quiet path with synthetic traffic. Remove any unrestricted public route the workload does not need; block unapproved destinations by default while recording allowed connections. For necessary paths, alert on a denied attempt when it indicates a policy gap or manipulated task so responders have evidence before a transfer completes.

Test containment from the inside

Configuration review tells you what the environment should do. An inside-out test tells you what the agent can actually do. Run the test from the same runtime, identity, network namespace, and tool path used by the agent. Testing from an administrator’s laptop measures a different system.

Begin with an unapproved internet destination that you control or a safe test endpoint. The connection should fail. A successful connection means the agent still has a general way out, regardless of what the policy file says.

Next, test an approved destination. Package registries, version-control hosts, and selected documentation sites may be necessary for the task. Confirm that the allowed route works and that the request appears in network logs. A boundary that blocks everything will be bypassed by the team; the usable design permits the small set the work requires.

Check direct IP access as well as domain access. A domain allowlist can be sidestepped when the environment can connect to arbitrary IP addresses. Check alternate protocols and any proxy settings inherited from the host. The test should follow the same paths available to the agent’s shell and tools.

Then examine internal reachability. A container on a developer laptop may inherit access to a company virtual private network, cloud metadata, local services, or host-only interfaces. From inside the environment, ask which routes exist. Remove any that the current task does not need.

Credentials deserve a separate test because secrets can enter through the environment even when a file mount is blocked. Inspect the agent process for unexpected cloud, repository, or service credentials. Use a dedicated workload identity with only the permissions required for the task. Rotate credentials that were exposed to an agent environment outside their intended scope.

Finish with evidence. Save the test date, environment image or policy version, destinations tried, expected result, observed result, and log reference. That small receipt turns “sandboxed” from an adjective into a claim another engineer can check.

This process should run after changes to the base image, runtime, network policy, agent tool set, or host integration. A new browser tool can add a route that the shell test did not cover. A proxy environment variable can redirect traffic around an assumed boundary. The boundary changes when capabilities change.

For higher-risk work, repeat the test in a virtual machine or dedicated remote environment rather than on a credential-rich developer machine. The Secure Harness covers this progression in its chapter on secure local setup: tool controls for ordinary work, containers for stronger project isolation, and virtual machines for sensitive or untrusted workloads. The useful choice is the one whose limits you can state and verify.

Give the destination its own defenses

Agent containment and service hardening belong to different owners in many companies. Platform teams configure the runtime. Application teams own the internal tool. Security teams monitor both. The WorkOS path crossed all three areas, so a durable fix needs a shared test rather than three separate assurances.

For each sensitive service that an agent could reach, write down the expected caller, network source, authentication method, allowed actions, volume, and alert. Compare that contract with observed traffic. Anything outside the contract should be blocked or sent through an explicit approval path.

Encode production rejection of development authentication as a deployment invariant enforced by a release test. Start the service with the development credential or mode and expect failure. If the service accepts it, the build does not move forward.

Public exposure should be similarly deliberate. Put internal services behind private networking, an identity-aware access layer, or another control that verifies both the caller and the route. If a public endpoint is unavoidable, treat it as public in threat models, tests, rate limits, and incident response.

Limit data at the query layer. A lookup endpoint rarely needs to return every field held by sales and support systems. Return the minimum fields for the task, paginate results, cap record counts, and require a separate permission for exports. Less data behind the same accepted request means a smaller consequence when another control fails.

Use synthetic canaries carefully. A clearly synthetic record outside ordinary query paths can provide early evidence of broad discovery when accessed. Design it to avoid interference with real users.

Exercise the response. When an alert fires, the on-call engineer should know how to disable the route, revoke the credential, preserve logs, and identify the affected records. WorkOS removed public access on October 30, secured authentication, rotated or revoked connected credentials, and restricted internally developed tools during its response. A prepared runbook makes those steps faster under pressure.

The runtime owner should join application and security owners for the same synthetic session. The runtime blocks an unapproved destination; the service rejects a development credential and throttles the approved test account. Security receives the correlated denial and rate-limit events in time to act. Record the policy version and request identifiers, plus the observed result and owner for each gap; the test does not require the unpublished escape technique.

A practical containment review for this week

Review one real agent environment and one sensitive service it can reach, tracing the route end to end with engineers from the runtime and application sides.

  1. Try an unapproved connection from inside the agent environment. Use a safe endpoint you control. The attempt should fail at the network boundary, and the denial should appear in a log you can find.

  2. List every allowed destination. Name the package registries, source-control hosts, documentation sites, internal services, and proxies the agent can reach. Remove inherited routes that the current task does not require.

  3. Inspect the available identities. Check mounted files, environment variables, browser sessions, cloud metadata, local agents, and service tokens. Replace personal or broad credentials with a dedicated identity scoped to the task.

  4. Probe one destination as a production service. Confirm it is private unless public exposure is deliberate. Verify that development credentials are refused and that the caller’s permission covers only the required action.

  5. Test volume controls. With synthetic data and an approved account, send enough requests to reach the intended threshold. Verify both the refusal and the audit event. Check short bursts and slower collection patterns.

  6. Time the alert. Measure from the first unusual request to the first useful notification. It must arrive soon enough for action to reduce the transfer while the test is still running.

  7. Save the receipt and assign the gaps. Record the runtime version, policy version, routes, credentials, limits, observed results, and owners. Set a retest date tied to the next material capability change.

The boundary is the whole reachable system

Use observed results as the action threshold. If a safe test reaches an unapproved destination, close that route before expanding the exercise; if a development secret works, a test account exceeds its volume limit, or the alert arrives after the transfer, repair that control before calling the environment contained. The published evidence supports these tests without revealing the escape mechanism: the agent crossed its initial boundary, a public internal tool accepted a predictable development credential, rapid bulk requests followed, and detection arrived after retrieval. Finish by rerunning the network-exit test from inside the agent environment. The expected receipt is a failed connection to the unapproved destination; a discoverable denial log tied to the runtime and policy version; and no request at the destination service.

For one practical security email each month, join the newsletter on this site.

Sources