As reported by Dark Reading, an obscure relay service is distributing access to OpenAI Codex and Claude Code across mainland China and other regions where those products aren't officially sold — and critically, with sandbox isolation features disabled. This isn't a vulnerability in the traditional sense. It's something arguably more dangerous: a business model built on removing the security controls that make AI-assisted code execution safe to use at all.

AI Security Alert: As reported by Dark Reading, an obscure relay service is distributing access to OpenAI Codex and Claude Code across mainland China and other regions where those products aren't officially sold — and critically, with sandbox isolation features disabled.

The Sandbox Is the Security Model

Modern AI coding tools rely on a simple but essential premise: the AI can suggest, generate, and even execute code, but it does so inside a contained sandbox that limits filesystem access, network calls, and interaction with the host environment. That sandbox isn't a nice-to-have feature. It's the foundational control that lets developers hand significant autonomy to an AI agent without risking their systems, their secrets, or their network.

When a relay service strips that sandbox away, every assumption that enterprises have made about the acceptable risk of AI coding assistants collapses simultaneously. The AI agent can now reach the filesystem, exfiltrate data over the network, install packages, and pivot. It's the difference between handing someone a tool in a workshop and handing them the keys to the building.

Who Is Actually at Risk

The obvious victims are developers in the serviced regions who are running AI-generated code with no containment. But the blast radius extends further than that. Consider these scenarios:

The Sandbox Is the Security Model
Remote developers and contractors — A developer in a serviced region who works for a Western company may use a relayed, unsandboxed tool to process proprietary codebases, secrets, and infrastructure details. That data flows through an untrusted intermediary with no contractual or legal accountability.
Open-source contributors — Code committed through unsandboxed AI tools can introduce subtle, AI-generated vulnerabilities or backdoors into public repositories. The supply chain implications are significant.
Any organization with a permissive BYO-AI policy — If your developers can use personal accounts or third-party gateways to access AI tools, you may already have exposure you haven't catalogued.

Why This Keeps Happening

Geographic access restrictions create demand. Where there's demand and a pricing gap, intermediaries fill the void. This isn't unique to AI — we've seen it with software licensing, cloud services, and even hardware. But AI coding tools create a uniquely severe version of this problem because the data being processed is the organization's most sensitive asset: source code, architecture diagrams, credentials, and internal documentation.

The relay operator sits in the middle of that data flow. Even if they're not actively malicious, they're an uncontrolled third party with visibility into everything that passes through. And if they are malicious, the sandbox removal is just the opening move.

The core issue isn't that someone is reselling AI access. It's that the security of AI-assisted development currently depends entirely on controls that the end user — or a middleman — can silently disable.

Shield53 Recommendations

Immediate Actions

  • Inventory AI tool usage — Survey your development teams on which AI coding tools they use, through which providers or gateways, and whether sandbox controls are verified as active. Treat this as a shadow IT discovery exercise.
  • Block unsanctioned AI relay domains — Add known relay and proxy domains to your egress filters and DNS blocklists. Review Dark Reading's reporting for specific indicators.
  • Enforce DLP on source code — Ensure that data loss prevention controls cover repositories, IDEs, and clipboard transfers so proprietary code isn't exfiltrated through third-party AI endpoints.

Strategic Actions

  • Establish an approved AI tools policy — Define which AI coding assistants are sanctioned, under what configuration, and require security review before adoption. Document acceptable use for remote and contract workers explicitly.
  • Verify sandbox posture, don't assume it — For any AI coding tool you deploy, validate that sandboxing is enforced at the infrastructure level, not just enabled by default. Defaults can be overridden.
  • Include AI tooling in third-party risk management — Treat any AI service that processes your code as a vendor. Require data processing terms, residency commitments, and the right to audit.
  • Brief leadership on shadow AI risk — This story is an accessible entry point for a board-level conversation about the gap between AI governance policy and what developers are actually doing.

The broader lesson here is that AI security cannot rely on controls that live only in the provider's default configuration. If the containment boundary can be removed by a reseller, it was never really a security boundary — it was a setting. Defenders need to treat AI tool exposure the way we've learned to treat SaaS shadow IT: assume it's happening, find it, and build policy around the reality rather than the ideal.