By NHI Mgmt Group Editorial TeamBased on Xygeni: “FauxCode: Reverse-Engineered Claude Code Routes Through Attackers” (May 4, 2026)

TL;DR: A two-armed npm campaign ships functional Claude Code clones, then hijacks developer API traffic through a proxy CA bundle and WebSocket relay or through ANTHROPIC_BASE_URL phishing, showing that malware can be usable by the victim and hostile to the operator at the same time, according to Xygeni. The identity lesson is that AI coding tools need governed secret handling, publisher trust, and runtime path controls, not just package scanning.


At a glance

What this is: Xygeni documents FauxCode, a campaign of working npm clones of Claude Code that hijack AI tool traffic through proxying, CA-bundle abuse, or OAuth-style credential capture.

Why it matters: IAM and platform teams need to treat AI coding tools as governed runtime paths, because package integrity alone does not prevent secret exposure, API interception, or identity abuse.


Context

FauxCode is a supply-chain and identity-governance problem, not just a malicious-package problem. The packages install and run like the legitimate AI coding tool, which means detection based only on install failure, obvious typosquats, or runtime crashes will miss the abuse path.

The security gap is the trust boundary around developer AI assistants: once a cloned CLI can influence certificates, environment variables, or login flows, it can become the path between the user, the model, and the vendor API. That makes publisher identity, secret handling, and runtime network control part of the control plane for AI-assisted development.


Key questions

Q: What breaks when a working AI coding clone can rewrite its own trust path?

A: The failure is not just malicious code, but a broken trust boundary. A package that still functions for the developer can quietly redirect model traffic, install new trust anchors, or inherit environment settings that point authentication and prompts at attacker-controlled infrastructure. That makes runtime trust, not install success, the thing to verify.

Q: Why do AI coding environments create more secret exposure risk than standard developer tools?

A: They can inspect repository context, read dotfiles, and infer where credentials are stored, then act on that information through commands or file changes. That means secrets can be exposed both by reading them and by persisting changes that keep access alive. Teams should assume workstation-local state is part of the secret attack surface.

Q: How should security teams build detection for malicious npm packages at publish time?

A: Security teams should combine fast package intake with layered enrichment, static analysis, and automated quarantine of suspicious records. Publish-time detection works best when the pipeline can scale horizontally, requeue failures, and filter benign packages before expensive analysis. The goal is to catch install-time abuse early, before malicious code reaches developers or production environments.

Q: Should organisations treat AI coding agents as part of IAM and PAM governance?

A: Yes, when those agents can act on code, data, or tools in ways that affect production risk. Their permissions should be scoped, reviewed, and audited like other privileged systems, especially when they interact with sensitive routes, secrets, or regulated data. The governance question is who can let the agent act, and under what policy.


Technical breakdown

How cloned CLI packages hijack AI tool traffic

These packages are not simple droppers. They repackage a working command-line tool, preserve the expected developer workflow, and then alter the outbound path for model traffic. In one arm, the implant downloads a CA bundle from an operator-controlled host, stores it locally, and uses it to trust a re-signed certificate. That allows interception of HTTPS traffic without breaking the user experience. In the same flow, a WebSocket tunnel carries API requests through the attacker infrastructure, turning a familiar tool into a relay point. The important technical point is that the malware lives inside a useful application, not beside it.

Practical implication: Monitor AI coding tools as executable network relays, not just as package artefacts.

Why ANTHROPIC_BASE_URL is a high-risk trust boundary

Environment-variable override paths are legitimate in developer tooling, but they become a control weakness when an untrusted package can set or persist them. In the second arm, the package rewrites ANTHROPIC_BASE_URL to a phishing endpoint and uses a custom login flow to harvest credentials. Because many tools inherit the same environment, one planted variable can redirect multiple clients, not just the cloned CLI. This is an identity and access problem as much as a software problem, because the runtime path determines which service is trusted to receive prompts, tokens, and authentication events.

Practical implication: Treat base-URL overrides and shell-profile changes as privileged configuration, not benign developer convenience.

What the CA-bundle relay changes about TLS trust

The CA-bundle approach is more subtle than classic credential theft. Instead of stealing an API key first, it changes what the client trusts, then uses that trust to observe or modify traffic in transit. Once the local trust store accepts the attacker certificate, TLS no longer proves the user is talking to the intended endpoint. That shifts the control failure from secrets management to trust-anchor governance. For AI-assisted coding, certificate trust and credential trust are now coupled, because the model traffic often carries code, prompts, and API secrets in the same session.

Practical implication: Validate local trust-store changes from developer tooling as a security event, not a routine install step.


Threat narrative

Attacker objective: The attacker wants to become the trusted path between the developer and the AI service so they can observe, alter, or harvest traffic and credentials.

  1. Entry occurs through a legitimate-looking npm package that installs cleanly and behaves like Claude Code for the developer who runs it.
  2. Credential and traffic control follow when the package rewrites the AI client path through a CA-bundle relay or a phishing login flow tied to ANTHROPIC_BASE_URL.
  3. Impact is interception or harvesting of prompts, responses, and credentials that pass through the developer’s AI assistant session.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Functional malware is the real supply-chain gap here: the most dangerous cloned package is the one that does what the developer expects while secretly changing the trust path. That breaks the common assumption that a successful install or a working CLI implies benign behaviour. For identity and access teams, this is a reminder that execution trust and publisher trust are not the same control.

AI coding assistants now behave like privileged integration points: they sit close to source code, tokens, prompts, and remote APIs, which makes them more sensitive than ordinary developer utilities. When a package can intercept that path, it effectively gains delegated authority over a high-value workflow. Practitioners should treat these tools as part of the identity boundary, not just the software boundary.

Publisher identity is becoming a control signal: the article shows that author email, repository provenance, and package description can help separate a normal open-source dependency from a malicious clone. That does not replace behavioural detection, but it gives security teams a way to score trust before runtime. The named concept here is AI assistant trust-path hijacking, which is the abuse of a working developer AI tool to redirect its authenticated traffic through attacker infrastructure.

Secret handling must move closer to issuance and use: the attack works because prompts, API keys, login flows, and environment variables can all be reached by one compromised developer tool. That makes post-install package scanning insufficient on its own. The practical response is to govern where AI assistants can send traffic, what trust anchors they can install, and which identities they can inherit.

Security teams need to collapse the distinction between malicious and usable: the post shows a class of threats where the package remains operational, the interface looks legitimate, and the compromise is embedded in normal usage. That means review processes focused only on install warnings will miss the real risk. The right lens is runtime trust governance for AI-assisted development.

From our research library:

What this signals

AI assistant trust-path hijacking: working clones of developer AI tools can become the system that receives prompts, certificates, and credentials, which means the compromise lives at the runtime trust boundary rather than in a single secret store. Teams should watch for certificate installation, environment-variable persistence, and abnormal developer-tool egress as one control problem, not three separate ones.

The identity lesson is that tool provenance, trust anchors, and delegated access now converge in the same workflow. The baseline risk is no longer hypothetical: Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026. That makes AI coding governance a live access-control issue, not a future policy exercise.


For practitioners

  • Constrain AI tool egress paths Allow Claude Code and similar developer assistants to reach only approved model endpoints and corporate proxy destinations. Block unexpected WebSocket relays and inspect outbound traffic from Node.js processes that originate in package installs.
  • Monitor for trust-store modification Alert when npm-installed binaries write local CA bundles or alter certificate trust on developer endpoints, especially under user home directories such as ~/.ccr. Treat local trust-anchor changes as a high-severity event.
  • Lock down environment-variable inheritance Review shell profiles, launchers, and IDE settings for persistent ANTHROPIC_BASE_URL or similar override variables. Restrict which tools can set proxy or base-url configuration for AI clients.
  • Score package provenance before execution Flag packages that mimic legitimate AI coding tools, reuse leaked-source naming, or rely on unusual publisher identities such as disposable email domains and cloned repositories. Use publisher identity as a triage signal, not a sole verdict.

Key takeaways

  • Working AI clones can hijack the same trust path they appear to serve, which makes usable malware more dangerous than obviously broken malware.
  • The core control failure is runtime trust, because certificate handling, environment variables, and login flows can all be redirected by a single malicious package.
  • Security teams need to govern AI coding assistants as privileged identity pathways, with endpoint, egress, and provenance checks working together.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe cloned assistant abuses trusted runtime identity and delegated access paths.
Recommendation — Apply ASI03 controls to restrict what AI assistants can authenticate to and what privileges they inherit.
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageThe campaign exposes API keys, prompts, and login credentials through a trusted-looking tool.
NHI-04 — Insecure AuthenticationThe phishing arm hijacks login flow and base-url trust for authentication capture.
Recommendation — Use NHI-02 controls to prevent AI tools from exposing secrets through logs, proxies, or relay paths. Apply NHI-04 controls to verify authentication endpoints and reject untrusted login redirection.
MITRE ATT&CKTA0006;TA0010 — Credential Access; ExfiltrationThe attack chain centers on credential capture and outbound relay of sensitive traffic.
Recommendation — Map the package behaviour to TA0006 and TA0010 to hunt for credential capture and data relay patterns.
NIST AI RMFGOVERN — AI Governance and AccountabilityDeveloper AI assistants require governance over trust boundaries, accountability, and approved use.
Recommendation — Establish GOVERN controls for approved AI assistant endpoints, trust anchors, and delegated access.

Key terms

  • AI Assistant Trust Path: The sequence of endpoints, certificates, environment settings, and login flows that determines where an AI coding tool sends data and how it authenticates. When an attacker can alter that path, the tool may remain functional while quietly exposing prompts, secrets, or credentials.
  • Base-URL Hijacking: A manipulation technique that redirects a client away from its intended service endpoint by changing the base URL or equivalent configuration. In developer AI tooling, this can reroute prompts, tokens, and model calls through attacker infrastructure without obvious breakage.
  • CA-Bundle Abuse: The use of a locally installed certificate authority bundle to make a client trust attacker-presented certificates. This breaks the normal assurance provided by TLS by changing what the client believes is legitimate, allowing interception or modification of encrypted traffic.
  • Trusted Runtime Abuse: A compromise pattern where malicious behaviour is embedded inside software that continues to perform its advertised function. The danger is that users and controls may treat the application as benign because the normal workflow still succeeds, even while sensitive traffic is being diverted.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps security and identity practitioners align AI-assisted development with access control and lifecycle governance.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org