Skip to main content

News

AI relays: Genuine tools, a different data route

Symantec warns about unofficial relays for Codex and Claude Code. Why AI approval needs to cover sourcing, destinations and permissions as well as the tool.

AI relays: Genuine tools, a different data route
Julian Köhn
|Lesezeit: 4 Minuten

An approved product name does not establish where data goes. A new Symantec report about unofficial AI access illustrates that gap. For a business, the question is more specific than “May we use Claude or Codex?” Which access route was configured, with what permissions and to which endpoint?

Sources checked on 30 October 2026, using the original investigation published on 29 October. Recommendations below are our assessment for operational AI approval. We have not executed the reported scripts. German is the editorial source version.

What Symantec observed

The Threat Hunter Team describes a relay service that installs genuine Codex and Claude Code clients, then changes their configuration to send requests through third-party servers and disable safeguards. It observed this since early 2026 in roughly a dozen organizations, mainly in China. Abuse of this position by the operator has not been demonstrated. The report says this is not a vulnerability in the original tools.

The distinction matters: the observed configuration risk is supported by evidence; resulting data theft is not established by that evidence alone.

Why approval needs more than a product name

Our assessment is that approval must describe its scope. “AI assistant permitted” might otherwise mean a managed business account, a personal account or access through an additional provider.

Those routes should not be treated as equivalent. A legitimately operated enterprise gateway can be a deliberate part of a secure architecture. The important points are review of the operator, control over the data route and the approved configuration. An unexpected address warrants investigation; it does not automatically prove an attack.

Teams that need an exception should have an accessible decision process. A prohibition list alone does not explain how to meet a legitimate work requirement. Equally, time pressure should not silently authorize the addition of intermediaries.

Four details make approval verifiable

DetailPractical question
Access and operatorWho holds the contract, and who provides access?
Permitted data routeWhich endpoints or reviewed gateways belong to it?
PermissionsWhich files, systems and actions may the assistant reach?
Change decisionWho reviews a different provider, extra tools or wider permissions?

These details belong to actual use, beyond purchasing. Configuration can change while the name on an invoice remains the same. Assign responsibility for maintaining the approved state and define which changes require another review.

Our suggestion for a small business is to begin with production access routes and their owners. Do not first build a comprehensive register of every conceivable AI product. A short, verified inventory is more useful than a long list disconnected from workstations.

What if the configured route is unclear?

Ask the responsible IT team to compare actual access with the approved configuration, including its source and connection destinations. Preserve the information needed for that review without distributing credentials through tickets, screenshots or chats.

Avoid additional sensitive use through the questionable route until it is understood. The next decision depends on the findings: is it a documented enterprise service, a deviation that could be approved, or unauthorized access? Evidence of compromise opens an incident process. Configuration drift alone does not prove compromise.

A useful outcome is an explicit decision with an owner and a due date. “We reminded the employee” does not demonstrate that the technical and organizational state has been resolved.

How this differs from the Cursor incident

The tampered Claude Code package in Cursor’s marketplace involved modified extension code. This report concerns the configured usage route of a genuine client. Combining them into a blanket “AI is insecure” message obscures the different checks they require.

For an AI usage policy, the practical addition is clear: describe permitted usage as well as permitted tools. Kopexa can help organize policies and their review in a traceable workflow. It does not replace technical workstation monitoring.

Good AI approval goes beyond the assistant’s name. It makes the permitted way of working identifiable.

Quick answers

Frequently Asked Questions

Still have a question? Find the answers here.

Does this establish data theft?

No. A risky data route does not establish abuse. Review the configuration actually deployed in your environment, how it was used and any evidence of an incident.

Are enterprise gateways inherently problematic?

No. A reviewed and approved gateway can be part of the intended architecture. A known operator, a controlled data route, appropriate permissions and documented responsibility are what matter.

What should an AI approval cover?

Beyond the product name, include the approved access route, permitted data and endpoints, permissions, and the process for changes and exceptions. Employees should be able to identify the specific way of working that is permitted.

Sources

  1. Sandbox Flipped to ‘Danger-Full-Access’: Unauthorized AI Relays Create Risk for Organizations — Symantec and Carbon Black Threat Hunter Team () [Accessed ]