FauxCode shows how working npm clones can hijack AI tool traffic

At a glance

What this is: Xygeni documents FauxCode, a campaign of functional npm clones of Claude Code that quietly intercept API traffic or harvest credentials during normal use.

Why it matters: It matters because AI coding tools increasingly sit on top of sensitive secrets and delegated access, so IAM, PAM, and NHI teams need controls that cover publisher identity, environment hijacking, and runtime secret exposure.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Xygeni's analysis of the FauxCode npm campaign and Claude Code clones

Context

Claude Code is not just a developer convenience layer. It becomes a security boundary the moment it handles API keys, terminal sessions, and environment variables that control where requests flow. FauxCode shows how a working clone can stay functionally believable while redirecting traffic, which makes the attack materially different from a broken typosquat or a fake download page.

For IAM and NHI programmes, the problem is not limited to package hygiene. The real issue is that AI development tooling now depends on secrets, OAuth flow handling, and mutable base URLs that can be rewritten outside normal approval paths. That creates a governance gap between software supply chain controls and identity controls, especially where service credentials and developer credentials intersect.

Key questions

Q: What breaks when a malicious AI coding tool is allowed to proxy developer API traffic?

A: The trust boundary breaks first. The developer sees a working tool, but prompts, completions, and API keys can be relayed through attacker infrastructure without visible failure. That makes detection harder than a broken install or a fake website. Security teams need runtime controls, certificate monitoring, and base URL validation to stop the proxy path.

Q: Why do AI tools create NHI governance risk?

A: AI tools create NHI governance risk because they often act with execution authority, data access, and delegated permissions that outlive a single user interaction. Once an AI service can read, write, or route enterprise data, it behaves like a non-human identity that needs ownership, scope limits, and lifecycle review.

Q: How do security teams know if a developer AI tool has been tampered with?

A: Look for behavioural changes, not just package names. Unexpected certificate files, altered base URLs, shell-profile edits, and outbound WebSocket tunnels from installed tooling are strong indicators of compromise. Provenance checks help, but the strongest signal is whether the tool starts handling credentials or traffic in ways the approved build never documented.

Q: Who is accountable when an AI assistant rewrites its own traffic path?

A: Accountability usually sits with the teams that own developer endpoint security, identity governance, and software supply-chain controls. If the tool can redirect credentialed traffic, then appsec alone is not enough. The organisation needs clear ownership for AI tooling provenance, secret handling, and runtime network enforcement.

Technical breakdown

How a malicious CLI can sit between the developer and the model

A trojanised command-line tool can preserve the user experience while inserting itself into the request path. In FauxCode, one arm downloads a CA bundle into the user profile, then opens a WebSocket tunnel to the operator’s host. That lets the package terminate and re-sign TLS locally, so the developer still sees a working AI tool while the operator sees prompts, completions, and API keys. This is a classic man-in-the-middle pattern, but packaged as an apparently legitimate developer workflow. Practical implication: treat AI CLI trust as a runtime control problem, not just a dependency-verification problem.

Practical implication: Block unexpected certificate writes and outbound WebSocket relays from package-installed binaries.

Why ANTHROPIC_BASE_URL rewriting is an identity risk

Environment variables are often used as benign configuration switches, but they become a control plane when they redirect authentication or API traffic. The heibai cluster rewrites ANTHROPIC_BASE_URL and persists it in shell profiles and settings files, which means the hijack survives reinstalls and reboots. That turns a local developer setting into a durable delegation mechanism. The identity issue is that the endpoint itself becomes part of the trust chain, so an altered base URL can shift both authentication and data flow to attacker infrastructure without changing the visible application. Practical implication: monitor and lock down identity-relevant environment variables just like secrets.

Practical implication: Detect and prevent unauthorised changes to base URLs in shell profiles and tool settings.

Why working malware is harder to spot than failed typosquats

Most supply-chain attacks fail loudly at install time or redirect users to an obviously fake site. FauxCode is more dangerous because the package still functions as a Claude Code clone, which lowers user suspicion and improves persistence. That creates a governance blind spot: security teams often prioritise failed installs, malicious websites, and checksum anomalies, while a functional clone that exfiltrates traffic blends into normal developer behaviour. The deeper lesson is that software trust cannot stop at package reputation. It has to extend to publisher identity, runtime network behaviour, and where secrets are handled after installation. Practical implication: add behavioural controls for developer tooling, not just package allowlists.

Practical implication: Correlate package installation with post-install network and filesystem behaviour on developer endpoints.

Threat narrative

Attacker objective: The attacker wants to become the developer’s API path, then observe, relay, or harvest the traffic and secrets that flow through the AI tool.

1. Entry occurs when a developer installs a functional npm clone of Claude Code that appears to work normally.
2. Escalation happens when the package captures the API path by inserting a CA bundle or rewriting the base URL, then persists that control in local settings or shell profiles.
3. Impact follows when prompts, completions, credentials, and session traffic are relayed through attacker infrastructure for inspection or credential harvesting.

NHI Mgmt Group analysis

Working malicious clones create a governance blind spot that package scanning alone will miss. The package still does what the developer expects, so installation-time signals are weak and user suspicion is low. That is a different class of supply-chain risk from broken typosquats or fake websites. Practitioners should treat runtime behaviour in developer tooling as part of the trust model, not an afterthought.

AI coding tools are becoming identity brokers, not just applications. Once a CLI can read API keys, alter base URLs, and proxy sessions, it sits inside the organisation’s identity perimeter even if no formal IAM product manages it. This is where NHI governance becomes relevant: the tool is effectively handling machine credentials and delegated access in a human workflow. Teams that do not model that boundary will miss the control point entirely.

Publisher identity now matters as much as package identity. The campaign’s clustering across npm scopes and author identities shows that looking only at the package name is too narrow. A named concept here is functional-clone trust collapse: malware that remains usable to the victim while quietly rewriting the trust path. That should push security teams toward provenance checks, maintainer identity scrutiny, and network-level validation of developer tools.

Secrets exposure windows in AI development are shrinking, which raises the cost of slow governance. When an attacker can intercept prompts and keys during ordinary CLI use, the question is not whether a secret was rotated eventually, but whether it remained exposed long enough to be used. This shifts the control discussion toward live containment, short-lived credentials, and endpoint enforcement for developer tooling.

This pattern belongs in NHI governance because the compromised object is a delegated machine path, not just a human workstation. The package is effectively a non-human intermediary that handles credentials and API calls on behalf of the developer. That makes lifecycle, provenance, and session controls central to the response. Practitioners should fold AI development tooling into NHI and PAM reviews rather than leaving it in a generic AppSec queue.

What this signals

Functional-clone trust collapse: security teams should now assume that a developer tool can be both operationally useful and malicious at the same time. That breaks older detection models that rely on failed installs, obvious typosquats, or suspicious websites. The response is to combine provenance checks with endpoint telemetry and NHI-style lifecycle controls for tooling that handles secrets.

The practical signal for programmes is that AI coding assistants belong in the same governance conversation as workload identities and privileged automation. If a tool can read API keys, rewrite upstream destinations, or persist shell changes, then it needs ownership, monitoring, and revocation paths. Teams should align that work with MITRE ATT&CK Enterprise Matrix and secret-handling guidance from Ultimate Guide to NHIs , Why NHI Security Matters Now.

Operationally, the next step is to map every AI developer tool to the secrets it can access and the network destinations it can influence. That inventory becomes the basis for least privilege, conditional execution, and fast containment when a package changes behaviour. Without that mapping, the organisation will keep treating an identity path as if it were just another dependency.

For practitioners

• Enforce endpoint controls on developer AI tooling Monitor package-installed binaries for unexpected certificate writes, especially creation of ~/.ccr/ca-bundle.crt, and alert on outbound WebSocket relays from node_modules processes. This catches the proxy pattern before it becomes a silent interception path.
• Lock down identity-relevant environment variables Watch for unauthorised changes to ANTHROPIC_BASE_URL in ~/.bashrc, ~/.zshrc, and tool settings files, and restrict which approved proxies may be used. Treat these values as part of the access path, not just configuration.
• Review AI coding tools as NHI-like delegates Inventory command-line AI assistants, the secrets they can read, and the APIs they can reach, then assign ownership and review cadence. Where a tool can proxy traffic or access tokens, put it under the same lifecycle scrutiny you apply to other non-human credentials.
• Strengthen publisher provenance checks Add heuristics for maintainer identity, package description language, and scope reuse across npm. A package that is functionally correct but published from suspicious identities can still be malicious, so provenance should feed allowlisting and sandboxing decisions.

Key takeaways

• FauxCode shows that a malicious package can remain fully usable while quietly taking over the API path.
• The core failure is not only package trust, but unchecked control over credentials, base URLs, and proxy behaviour inside developer tools.
• Teams need runtime monitoring, publisher provenance checks, and NHI-style governance for AI coding assistants before the next clone is installed.

Key terms

• Functional Clone Trust Collapse: A condition where malicious software remains operational enough to satisfy the user while quietly altering trust, routing, or identity controls. In practice, the victim keeps using the tool because it works, even as the tool intercepts secrets or traffic.
• Upstream Proxy Relay: A relay mechanism that places an intermediary between a client and its normal service endpoint. In this context, the relay can terminate TLS, inspect content, and forward requests onward, making the proxy part of the credential and data path.
• Environment Variable Hijack: The abuse of a configuration variable to redirect authentication or API traffic to attacker infrastructure. It is dangerous because many tools treat environment variables as benign configuration, even when they determine where secrets and sessions are sent.
• Delegated Machine Path: A software path that acts on behalf of a user or system and therefore inherits trust to handle credentials, sessions, or commands. When that path is compromised, the attacker is effectively inside the delegated identity boundary rather than outside it.

What's in the full report

Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact package and version indicators for the Claude Code clone cluster, including author identity clues and module names.
• Filesystem and network indicators tied to the CA-bundle MITM path, including where the relay is staged and how it persists.
• The heibai phishing flow, including the local credential cache and shell-profile persistence changes.
• Detection guidance and triage heuristics for defenders who need to hunt similar npm packages across developer fleets.

👉 Xygeni's full post covers the package indicators, proxy mechanics, and phishing flow in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security practitioners build governance for the delegated tools and credentials that now sit inside development workflows.