Someone found a reseller online offering "discount Claude" and installed the client it provided. It looked like Claude Code, and it worked like Claude Code.
What he didn't know: his requests were quietly routed to a different model, and the bundled tooling was stealing his Anthropic account credentials and reselling them to other resellers.
This is case GTG-50021, documented in Anthropic's September 2026 threat intelligence report. The same section describes another persistent credential-theft technique: a malicious client stays on the machine, and after the user rotates keys and signs back in, it keeps harvesting the new keys and session credentials.
If a developer installs this client on a company computer, which services does the code sent to the model pass through? What other credentials on that machine could be stolen? Can the IT department even find out?
01 / MODEL VERIFICATION — Whose Model Did You Actually Buy?
In this report, access to AI itself has become a commodity of the underground economy: some steal keys, some resell accounts, and others use fake clients to keep harvesting credentials for downstream resellers.
Anthropic can ban the accounts involved, publish malicious domains, and improve detection. Which clients and services are used inside a company, however, is the company's own responsibility to manage.
Teams accessing models through third-party channels also need to confirm one thing: the API responds, but do the actual model and its capabilities match what was promised at purchase?
When verifying a model service, checking the returned model name is not enough. You also need to check whether the API structure conforms to the specification, whether capabilities such as tool use, PDF input, and extended thinking are available, and whether the returned token usage looks abnormal. The open-source project veridrop provides these checks, compares results against official baselines, and supports self-hosting as well as submitting test jobs via API.
That said, an anomaly is not proof of fraud. For example, if repeated requests return identical cache-read counts, it may simply be because they reuse the same prompt content. To judge whether metering is wrong, you need to vary the cached content, observe whether the readings change accordingly, and then compare the same requests against a trusted channel.
Even if the model genuinely comes from the official source, the relay may still retain your requests. Model origin, billing, and data handling therefore need to be verified separately.
These tools can inspect the model service a vendor provides, but a single test only reflects that moment in time. Companies also need to maintain a unified vendor list, retest periodically, handle anomalies, and record which upstream each call actually used, so that incidents can be traced later.
02 / FOUR QUESTIONS — The Four Questions Enterprises Must Answer
Q1: Who holds the keys?
If developers copy the same "company key" from a group chat into their own tool configurations, one key can end up on a dozen machines. Once it leaks, it is hard to tell users apart from the key information in call logs alone; revoking one person's access means disabling the shared key, forcing everyone else to update their configurations.
Q2: Which upstream are requests sent to?
The company purchased model services, but not every developer necessarily uses them. Some may have pointed their tools at another relay; others may be on personal subscriptions. IT needs to find out which services people are actually using, and who the company's code and data are being sent to.
Q3: What operations is the AI about to execute?
Tools like Claude Code and Cursor can run commands, modify files, and call external services. Judging whether an operation is safe requires looking at the command itself, the runtime environment, and the credentials and permissions the tool holds. The same DELETE statement has completely different consequences in a test database and in production.
Client-side approvals can block some dangerous operations, but each developer's approval settings may differ. Claude Code even ships a --dangerously-skip-permissions flag that lets users bypass permission checks.
Q4: Is there customer data in what's being sent out?
Troubleshooting logs submitted to an AI may contain phone numbers and access tokens; SQL query results may contain customer records. If requests are not inspected before they leave, this information goes to the upstream service along with them.
Enterprises control network access with firewalls and manage accounts with unified identity. After adopting AI tools, they also need to manage model access, track usage costs, inspect sensitive data before requests leave, and check the risk of model-generated commands before tools execute them.
03 / OPERATION SAFETY — How Claude Code Inspects AI-Initiated Operations
For Q3 — "what operations is the AI about to execute" — Anthropic offers auto mode in Claude Code, which checks operation risk before tools execute. Starting August 14, 2026, new sessions on Claude Code's Pro, Max, and Team plans use this mode by default; users' previously pinned default settings are unaffected by this change.
Auto mode first handles tool calls according to permission rules, then hands calls that need further judgment to a classifier, which identifies risks such as destructive deletion, sensitive-data exfiltration, and dangerous code execution. When an operation is blocked, Claude tries to adjust its plan; after repeated blocks, it falls back to manual approval.
Anthropic published a controlled experiment: researchers paid 1,053 testers and, while they performed test tasks, replaced the command in one approval prompt with a dangerous command. The human-approval rejection rate was 13.6%, while auto mode blocked 89% of the same set of commands. This shows that, under these experimental conditions, automated detection caught far more dangerous commands than manual approval — though some still slipped through.
But auto mode is only available in Claude Code. If the team also uses Cursor or in-house agents, how can the company make these tools follow the same security rules?
Our answer: route all model requests through a gateway, check them against rules when requests go out and when results come back, and at the same time inspect the operations the model asks tools to execute. The gateway cannot see everything on a developer's machine, though. Which files a command can touch, and whether it can modify a production database, still have to be constrained by local permissions, sandboxes, and database authorization.
04 / GATEWAY GOVERNANCE — What a Gateway Can Govern
To achieve this kind of unified management, enterprises need a unified access and governance entry point between their various AI tools and upstream model services. ZStack Zentrix is an enterprise-grade AI gateway designed for exactly this scenario: it centralizes the model configurations and access credentials that were previously scattered across tools. Administrators centrally configure the available models and upstream services, and developers initiate calls using keys issued by the enterprise.
On top of this, key management, routing policies, content guardrails, and call records enable policy checks on requests, while continuously recording the caller, the actual upstream used, and usage — providing a basis for cost reconciliation and anomaly investigation.
Keys: upstream credentials held by administrators
Administrators configure upstream vendors' keys in the gateway; developers use access keys issued by the gateway. When the gateway receives a developer's request, it calls the model service with the corresponding upstream credential.
Administrators can issue separate keys for different people and applications to distinguish call sources, and can revoke a single key when needed without affecting other users.
A stolen gateway key can still be abused, but attackers cannot extract upstream keys from it. Administrators can limit the key's permissions and quota, or revoke it outright. If the machine already has the malicious client from the opening case installed, the malware must be removed and other credentials checked for compromise.
Upstream: verify by vendor and by model
Model verification must be done per "vendor + model." For example, a vendor's Sonnet may be fine while its Opus is watered down.
To this end, we designed five levels of probes that check API format, token metering, actual capabilities, signatures, and response characteristics, selecting the applicable checks based on the model and access channel:
·01 API format. Compare response fields, message identifiers, stop reasons, and error formats to look for anomalies left by protocol conversion. For example, a field specific to another model service appearing in the response is recorded as a lead. For platform-wrapped APIs, compare against the format of the corresponding channel to avoid flagging normal protocol differences as anomalies.
· 02 Token metering. Send tests with a fixed set of Chinese, code, whitespace, and numeric content, and compare the returned token counts against baselines from trusted channels, while also cross-checking streaming versus non-streaming usage under identical conditions. Baselines are matched by model and access channel, revealing counting deviations and anomalies that appear under only one request mode.
· 03 Actual capabilities. Based on the capabilities a model claims to support, test extended thinking, prompt caching, tool use, and image input separately. For example, repeatedly send requests that meet caching conditions and check whether the cache is hit; request a tool call and check whether the returned tool name and parameters conform to the specification. Results list the failed items with response evidence, helping administrators locate capability gaps, configuration issues, or protocol adaptation problems.
· 04 Signature round-trip. For APIs that support thinking signatures, send two sets of requests: one passes back the thinking block returned by the model unchanged; the other modifies its signature. Then compare whether the upstream accepts them. Taking Claude as an example, the signature field carries the encrypted full thinking content. The probe compares results according to each API's validation rules, checking whether the original content works and whether tampering is detected.
· 05 Response characteristics. Send the same fixed set of prompts to the service under test and to a trusted channel, and compare the answers against reference outputs. Given output variance and version changes, this result serves only as supporting evidence, presented alongside the previous checks; model identity is not judged on it alone.
However, if a relay forwards test requests to the official service unchanged, it can also pass signature checks. These results therefore only reflect how the upstream validated signatures during this test; they cannot reveal whether the relay retains requests, nor can they detect which model daily calls actually use.
We plan to display per-level results and their evidence on the vendor page, with manual and periodic verification. When anomalies are found, administrators investigate and decide whether to contact the vendor or disable the service; the system does not switch routes automatically.
Operations: inspecting tool calls returned by the model
Models usually return tool calls as structured data containing the tool name and parameters. If the response passes through the gateway and the gateway can parse the corresponding protocol, this content can be inspected before the client receives the tool call.
We add a classifier before the gateway returns tool calls, combining the user's request and the pending operation to check for risks such as downloading and directly running scripts, sensitive-data exfiltration, destructive deletion, production changes, privilege escalation, and credential exposure.
For example, a developer asks the AI to clean up test data, but the command returned by the model contains a known production database address. With the corresponding rules configured, the gateway hands this operation to the classifier; if it is judged to require blocking, the gateway stops returning the tool call to the client, explains the reason to the model, and asks it to regenerate a plan.
Regenerated operations are still subject to inspection. Under the current design, a response is retried at most three times; if it still fails after the limit, retries stop and the user is notified. If the classifier times out or is unavailable, the system follows the failure policy configured by the administrator. Both classification and regeneration incur additional calls and costs.
Administrators can also configure internal domains, repositories, storage buckets, and other information to help the classifier identify the systems an operation involves. Even when the target is an internal system, the operation must be checked for overreach — for example, whether the receiving system is authorized to store that sensitive information.
Operation inspection runs on the server side and is unaffected by developers' local approval settings. Its scope is limited to tool calls that pass through the gateway, hit rules, and can be parsed. Operations executed by clients on their own and requests that bypass the gateway are outside the inspection scope, and the classifier cannot use local environment information not provided in the request.
Content & records: policy-based inspection, call-level traceability
Administrators can use policies to inspect sensitive information in requests and choose to redact or block it. Model responses can also be included in inspection, with the exact scope limited by protocol and output mode; some rules only support non-streaming responses.
Through call records, routing records, and usage data, you can query who called which model, whether requests succeeded, and how many tokens were consumed.
Once inspection results are linked with call records, administrators can look up callers, upstreams, and handling results based on sensitive-data hits, and trace application costs back to specific calls.
05 / ENTERPRISE DEPLOYMENT — How the Gateway Fits into Enterprise Environments
Where is the gateway deployed?
Zentrix Gateway supports private deployment, with call records stored in the enterprise's own data center or cloud environment. Model requests are sent to the upstream services configured by administrators; the context needed for operation inspection is sent to the selected classifier. Whether the relevant data leaves the enterprise environment depends on where these two types of services are deployed.
How much latency does it add?
Authenticity verification runs independently out of band, so business requests do not wait for it — though the testing itself consumes upstream quota. Operation inspection has two modes: "log only" mode checks asynchronously and responses return without waiting for results; "block" mode inspects before releasing, and requires the model to regenerate when risks are found. The latter adds the time for classifier judgment and model retries; the exact latency varies with classifier response speed, the number of tool calls, and retry counts.
Will it become a single point of failure?
Gateway availability is jointly determined by the forwarding service, load balancing, storage, and upstream services. Multi-replica deployment reduces the impact of a single gateway instance failure, but storage and upstream services each carry their own failure risks. Whether requests can continue to be forwarded during a console outage depends on whether the data plane can keep operating with its existing configuration.
How do you get developers to actually go through the gateway?
For clients that support custom model endpoints, developers connect using the gateway address and an enterprise-issued access key, while upstream vendor keys are held centrally by the gateway. Model calls, streaming output, and tool calls are forwarded via the protocols the gateway supports; exact coverage varies with client capabilities and login methods.
Personal subscriptions and other direct channels do not go through the gateway and are not subject to its policies. This portion of access is controlled by the enterprise's endpoint policies and network egress rules.
Can domestic models be managed together?
Domestic models use the same unified vendor configuration, routing policies, and usage statistics. Content guardrails take effect according to the protocols each API supports; in the model verification scheme, each model type uses its corresponding reference baselines, and signature checks apply only to models that support the mechanism.
06 / UNIFIED MANAGEMENT — From Individual Access to Unified Enterprise Management
After connecting to the gateway, developers use their own access keys, while administrators centrally configure upstreams and access permissions. When anomalous calls are found, administrators can review records, revoke credentials, and then decide whether to adjust vendors or rules.
In the fake-Claude case at the beginning, the user bought a model service but installed credential-stealing malware. Risks exist simultaneously in the client, the model vendor, and the request transit path; merely confirming that the model responds makes these problems hard to spot.
An AI gateway brings scattered model access under unified management: enterprises can query callers, upstreams, usage, and inspection results, and centrally adjust credentials and access policies. The gateway manages and inspects model calls; endpoint protection identifies malware; the operating system and databases limit execution privileges — each handling risks at its own layer.
Zentrix Gateway provides enterprise model access, credential management, routing policies, content guardrails, and call records. Model authenticity verification and operation inspection will continue to advance along the directions described above. Contact us to learn about integration options and request a demo.