Anthropic Proxy Package Steals Real API Keys

Anthropic Agent Package Steals Real Secrets, Exposing Supply Chain Risks in AI-Generated Code

Security company Aikido recently disclosed that a software package associated with Anthropic Claude agent workflows had collected and exfiltrated real secrets. According to the researchers, this was not merely a laboratory proof of concept: the code actually accessed valid credentials, moving the risk beyond the hypothetical concern that "AI might generate insecure code."

More alarmingly, the incident reveals a remarkably seamless attack chain: AI generates or selects a dependency, an agent automatically installs the package, the installed code reads environment variables or local configuration, and then sends the secrets out of the execution environment over the network. A software supply chain compromise that once required developers to make several consecutive mistakes may now be linked together by a single instruction: "Help me get this project running."

As of August 2, 2026, public disclosures still come primarily from security research organizations. The incident's complete timeline, the precise path by which the package entered the workflow, and whether Anthropic's internal review mechanisms failed during the process all require further evidence. It would therefore be inappropriate at this stage to reduce the incident to "Claude actively stole secrets," or to conclude that all Claude Code or Anthropic SDK users have been affected.

One point, however, is already clear: once an unverified package is granted permission to execute, it makes no difference to an attacker whether the secrets were copied in by a human, injected by CI, or read from the environment by an AI agent.

This Is Not the Model "Turning Bad"; It Is the Disappearance of Execution Boundaries

Discussions about AI security are often sidetracked by the question of whether a model has malicious intent. Software supply chains do not care about intent; they care only about the permissions ultimately granted to code.

Traditional code completion tools generally only insert text into an editor. Developers must read it, save it, install dependencies, and run the program, leaving at least several opportunities to stop along the way. Agentic programming tools are fundamentally different: they read repositories, modify configuration, invoke package managers, run tests, access networks, and, when necessary, independently search for "missing dependencies."

This means that a single model error may no longer be one line of code awaiting review, but a sequence of system operations that have already occurred.

In a typical Node.js project, for example, the risk chain might look like this:

1. The agent generates a plausible-looking package name based on context;
2. The package manager finds a package with that name in a public registry;
3. The agent automatically installs it to resolve a build error;
4. The package executes code during installation, import, or testing;
5. The code scans for API_KEY, cloud credentials, npm tokens, GitHub tokens, or local configuration;
6. The credentials leave the machine through channels such as HTTPS, DNS, or telemetry endpoints.

This does not necessarily require a sophisticated vulnerability in the traditional sense. As long as the package is "allowed to be installed and executed," many of its actions appear legitimate to the operating system. What the AI agent does is complete the social-engineering step for the attacker: it makes an unfamiliar dependency appear to be a normal component required to complete the task.

"Hallucinated Packages" Are Becoming an Exploitable Attack Surface

This class of risk is commonly called package hallucination or slopsquatting, and can be understood as dependency name squatting for the AI era.

Models may generate nonexistent package names based on naming conventions. For example, a model might mistake an internal module, a library from another programming language, or a vaguely referenced name in documentation for a real dependency on npm, PyPI, or another public registry. Attackers need only register these names in advance and wait for an agent to install them automatically.

There is one crucial difference between this and classic typosquatting.

Traditional typo-based squatting depends on users making spelling mistakes: attackers must bet on whether requests will be typed as requsets. In a hallucinated-package attack, attackers can collect frequently generated fictitious names from model outputs and register them in bulk. They do not need to predict the mistake a particular developer will make; they only need to observe which mistakes models make repeatedly.

Once a coding agent gains the ability to execute actions automatically, the attack surface expands further:

• Automated dependency selection: The agent may prefer the package whose name "looks most like the answer," rather than one with the most active maintenance or most trustworthy provenance.
• Automated installation: Developers may never see newly added dependencies, much less inspect each installation script.
• Automated error remediation: A malicious package can deliberately produce errors that prompt the agent to run additional commands, expand privileges, or disable security restrictions.
• Excessive contextual access: Agents commonly run on developer machines or in CI environments containing real .env files, cloud credentials, and proprietary source code.
• Open network access by default: An environment that can reach a public package registry can often also reach attacker-controlled domains, making outbound exfiltration difficult to detect in time.

This is what makes the disclosure more troubling than an ordinary malicious-package story. Malicious packages have always existed, but AI agents are becoming a high-frequency, automated new installation vector—one in which machine-generated output is readily trusted.

Anthropic's Recent Incidents Reveal a Set of Engineering Governance Problems

This incident also comes amid a recent series of security controversies involving Anthropic.

In April, the Claude Code 2.1.88 update accidentally included internal source code materials because of a packaging error. Public reports indicated that the archive contained nearly 2,000 files and more than 500,000 lines of code. Anthropic attributed the incident to a human error in the release packaging process and said that no customer data or credentials had been exposed.

Security researchers have also identified potential ways to bypass Claude Code's sandbox network controls. The approach relies on routing outbound access from sandboxed processes through a SOCKS5 or HTTP proxy, which then permits or blocks connections according to a user-configured domain allowlist. If the proxy handles hostnames, DNS resolution, or specially crafted inputs incorrectly, the network boundary may still be bypassed at the proxy layer even if the operating-system sandbox properly restricts the process.

These incidents are not the same vulnerability and should not be conflated: accidental source-code packaging is a release-process problem, sandbox bypasses are boundary-validation problems, and malicious or uncontrolled dependencies are software supply chain problems. But together, they point to one fact: securing an agentic product cannot be accomplished simply by training the model to reject a few dangerous prompts.

The true upper bound on risk is determined by packaging systems, dependency review, credential isolation, network policies, tool-call authorization, and audit logs. The model is the agent's brain; the package manager, shell, and network are its hands and feet. Training the brain to "be careful" while giving the hands and feet full permissions by default is unlikely to produce a reliable security boundary.

Scanning Generated Code Alone Is No Longer Enough

Many teams still govern AI-generated code primarily through code review: checking for SQL injection, command injection, hard-coded passwords, and obvious business-logic errors. These checks are certainly useful, but they cannot account for actions performed while an agent is executing.

A package does not even need to leave malicious logic in the final commit. It can read secrets during installation, after which the agent may delete temporary files, rewrite the lockfile, or roll back the code because the task failed. The final Git diff may look clean even though the secrets have already left the environment.

The scope of auditing must therefore expand from "what the AI wrote" to "what the AI did," including at least:

• Which tools the agent invoked and which commands it executed;
• Which direct and transitive dependencies it installed, including the exact resolved versions and hashes;
• Which processes accessed sensitive files and environment variables;
• Which domains, IP addresses, and DNS services it contacted during execution;
• Who approved privilege escalation, installation scripts, and network access;
• Whether short-lived credentials exposed in the context were rotated after the task ended.

If a platform can display only conversation history but cannot reconstruct command, file, process, and network events, it does not yet provide complete agent auditing capabilities.

What Development Teams Should Do Now

The most effective response is not to ban AI programming entirely, but to treat the agent as a partially trusted automated build user. It can improve productivity, but it should not inherit all the permissions of the developer operating it.

1. Isolate Real Credentials by Default

Do not let agent processes directly inherit the full shell environment. Production database passwords, long-lived cloud keys, package-registry publishing tokens, and personal GitHub tokens should not appear in environment variables that the agent can read freely.

Prefer task-scoped, short-lived, least-privilege credentials. Even if they are exfiltrated, they should expire quickly and grant access only to limited resources.

2. Require Policy Checks for New Dependencies

Check the provenance, age, download count, maintainer changes, installation scripts, and lockfile changes of packages added by an agent. A newly registered package with no repository and no version history that an agent nevertheless "recommends with precision" should trigger an outright block, not merely a yellow warning.

A basic review can begin with the following process:

# Disable dependency installation scripts first. Allow them only in an isolated environment after reviewing the dependency tree.
npm ci --ignore-scripts
npm ls --all
npm audit --omit=dev

This is not a complete defense. npm audit primarily identifies known vulnerabilities; it does not prove that a new package is non-malicious. Likewise, --ignore-scripts may cause legitimate builds to fail. But at a minimum, this separates "download" from "execute" into two steps that each require explicit authorization.

3. Use Allowlisting for Outbound Network Access

Development sandboxes and CI environments should not have unrestricted internet access by default. Package registries, source-code hosts, internal APIs, and required model endpoints can be allowlisted by domain, while all other connections are denied and logged by default.

At the same time, do not treat a domain allowlist as the only boundary. DNS rebinding, redirects, CDNs, differences in proxy resolution, and special hostnames can all cause filtering to fail. Network policy is best enforced at an independent gateway or container-infrastructure layer, rather than relying entirely on the agent tool's own JavaScript filtering logic.

4. Pin Dependencies and Verify Integrity

Lockfiles must be committed to version control, and CI should use deterministic installation. Agents should not be permitted to perform major-version upgrades or rewrite dependency sources without human approval. Critical dependencies can be further protected through hash verification, private mirrors, allowlists, and artifact signing.

For highly sensitive projects, public registries should not serve directly as the upstream source for production builds. A safer approach is to synchronize dependencies first into an internal artifact repository after scanning and approval, and then have the build environment retrieve them from there.

5. Express Agent Permissions as Machine-Enforceable Policies

"Please do not read .env" is merely a prompt, not a security control. Effective restrictions must be enforced through file permissions, container mounts, secret brokers, network policies, and approval systems.

Dangerous commands, first-time package installations, access to credential directories, modifications to CI configuration, and connections to new domains should all require human approval. Agents may propose actions, but they must not be allowed to approve their own requests.

The Real Warning From This Incident

The greatest supply chain risk in AI-generated code is not that a model occasionally invents a nonexistent package name. It is that the industry is connecting model output directly to executable environments.

In the past, hallucinations generally meant inaccurate answers; now, a hallucination can trigger a real software installation. In the past, code defects had to pass through development, review, and deployment before affecting a system; now, an agent can access source code, credentials, and networks within minutes while "solving a problem."

From a productivity perspective, this is precisely the value of coding agents: they reduce the need for people to switch back and forth between tools. From a security perspective, it is also their greatest danger: the friction that once interrupted attacks is being deliberately removed through product design.

This incident should therefore not be addressed merely by "removing one problematic package" or "fixing a piece of generated code." If an agent can still automatically select dependencies, execute installation scripts, read real secrets, and access the network without restriction, the next package can follow the same path under a different name.

Determining whether a coding agent is suitable for an enterprise environment also requires looking beyond benchmark scores and task-completion rates. More important questions are: How much damage can it cause when it fails? Can the organization observe the complete process? And are its security boundaries independent of the model's own judgment?

This is the lesson that must be learned as AI programming moves from demonstration tools to production infrastructure.

References

• Official Anthropic Claude Code Repository — Claude Code's public code repository, which can be used to verify version releases, issues, security-related changes, and product background.