An AI Coding Assistant Session Became a Supply-Chain Attack

Developers are used to checking a package before installing it. The process usually takes only a few seconds: read the recommendation, run the install command, and continue working.

But this can become a serious security problem when the recommendation comes from a compromised AI coding assistant.

A recent Mandiant case study described an attack in which a threat actor hijacked an active AI coding-assistant session at an unnamed software company. After hijacking the active session, the attacker caused the coding assistant to recommend a poisoned package, which the developer accepted, which led to an infostealer, stolen GitHub OAuth tokens, and the spread of the Shai-Hulud worm across approximately 100 internal code repositories.

In that incident, the attack began with a trusted development tool making a recommendation.

How the attack unfolded

The public case study does not explain how the attacker initially took over the AI assistant session, that remains undisclosed.

After gaining access to the active session, the attacker used the assistant to recommend external software. The recommended package had been poisoned before the developer installed it.

According to the report, a malicious package hosted on PyPI, the Python Package Index, was installed in the development environment. It deployed an infostealer that collected GitHub OAuth tokens from the development environment.

Those tokens gave the attacker authenticated access to the company’s repositories. The attacker then deployed the Shai-Hulud worm across around 100 internal repositories, stealing repository secrets and source code related to the company’s products.

The attacker also poisoned a package under the company’s official namespace. When another employee downloaded the compromised package, the infection spread to another development environment.

That detail makes the incident especially concerning. The attack used the organization’s own package namespace as a second distribution channel.

Why AI assistants change the risk

Supply-chain attacks are not new. Attackers have targeted package registries, maintainers, build servers, and developer credentials for years. AI coding assistants introduce another layer of trust.

A coding assistant may be able to:

• Recommend packages.
• Generate installation commands.
• Modify dependency files.
• Run commands in a terminal.
• Read project files.
• Inspect configuration.
• Access repositories.
• Work with external tools.
• Use credentials available to the development environment.

This creates a powerful combination. The assistant can influence what a developer installs while operating close to the credentials and repositories attackers want to reach.

A developer may question an unfamiliar command typed by a stranger. The same command can feel more trustworthy when it appears as part of an assistant’s response inside an editor. And attackers can exploit that trust.

The package was only the first step

The most important lesson is that the poisoned package was not the final objective. The package created an entry point. The stolen tokens and repository access created the larger impact.

Once the attacker gained access to authenticated developer resources, they could move through the software supply chain:

1. Compromise the coding-assistant session.
2. Influence a package recommendation.
3. Get the developer to install the package.
4. Steal available credentials.
5. Use those credentials to access repositories.
6. Spread malicious code or packages.
7. Collect secrets and source code.
8. Reach additional developers through trusted internal packages.

This is why supply-chain security cannot focus only on the package registry. The complete workflow includes the developer’s machine, editor extensions, AI tools, credentials, CI/CD systems, and internal package repositories.

Why package names are not enough

Developers often look at a package name and repository link before installing it, which is useful, but it does not provide complete protection.

A malicious package may:

• Use a name similar to a popular package.
• Have a convincing README.
• Imitate the behavior of a legitimate library.
• Include an install script.
• Depend on another malicious package.
• Remain inactive until it detects a valuable environment.
• Appear inside a trusted organization namespace.
• Be recommended by an AI assistant with no explanation of its origin.

A package can appear to work normally while running additional code during installation or execution.

Developers should verify more than the name. They should check the package’s publisher, history, source repository, release activity, dependency tree, install scripts, and security advisories. An AI recommendation should be treated as a lead, but not as proof that a dependency is safe.

The role of prompt injection

Prompt injection is another part of this problem. AI coding assistants read more than the instructions typed directly by a developer. Depending on the tool and configuration, they may also process repository files, documentation, issue descriptions, pull requests, comments, configuration files, and external content.

If one of those sources contains malicious instructions, the assistant may treat them as part of the task.

A repository file could tell an agent to:

• Install a specific package.
• Run a command.
• Read a local configuration file.
• Add an MCP server.
• Change a security setting.
• Upload output to an external endpoint.

The assistant may not understand that the instruction is untrusted content rather than an authorized request. It means developers should understand what information their coding tools read and which sources are allowed to influence actions.

The danger of available credentials

A compromised assistant session becomes much more serious when credentials are available on the same machine.

Developers often have access to:

• GitHub tokens.
• npm or PyPI tokens.
• Cloud credentials.
• SSH keys.
• Database connection strings.
• CI/CD secrets.
• Environment variables.
• Private package registries.

An assistant does not need permanent access to all of these credentials to create damage. One exposed token may be enough to modify a repository, publish a package, or access another service.

This is why credentials should not be treated as harmless just because they are stored locally.

Long-lived tokens increase the possible impact of a compromised session. A token with broad permissions can turn a local development incident into an organization-wide problem.

What developers can do

Mandiant recommended several controls for AI-assisted development, including verifying AI-recommended dependencies against cryptographic checksums and approved allowlists, keeping raw API keys and long-lived OAuth tokens away from extensions, and routing dependency traffic through controlled internal repositories. Developers can also take practical steps in their daily workflow.

Verify every new dependency

Before installing a package suggested by an AI assistant, check:

• The exact package name.
• The official documentation.
• The publisher or maintainer.
• The source repository.
• The release history.
• The dependency tree.
• Installation scripts.
• Known security advisories.
• Whether the package is actually necessary.

Limit credential access

Use credentials with the smallest permissions possible. Prefer short-lived tokens where the platform supports them. Separate personal and work credentials. Keep production credentials away from local development environments. Avoid giving editor extensions access to secrets they do not need.

A coding assistant should not automatically receive access to every credential available on a developer’s machine.

Protect package installation

Organizations can route package downloads through approved internal registries or proxies. This makes it possible to inspect, cache, block, and monitor dependencies before they reach developer machines.

Allowlisting trusted packages may feel restrictive, but it can prevent a single recommendation from reaching every project in a company.

Review dependency changes

Pay close attention to changes in:

• package.json.
• package-lock.json.
• pnpm-lock.yaml.
• yarn.lock.
• requirements.txt.
• pyproject.toml.
• CI/CD workflow files.
• Git hooks.
• AI assistant configuration.
• MCP server configuration.

A dependency update deserves review even when the code change appears unrelated.

Separate agent permissions

An AI assistant that explains code does not need the same permissions as an agent that edits files and runs terminal commands.

Use approval requirements for sensitive actions. Restrict network access where possible. Run untrusted work in isolated environments. Keep repository access, package publishing, and deployment permissions separate.

More capability can make an agent more useful, but it also increases the consequences of a compromised session.

What if a compromise is suspected?

If a developer suspects that a malicious package or assistant session was involved, reinstalling dependencies is not enough.

The organization should consider:

• Removing the suspicious package.
• Isolating the affected environment.
• Rotating GitHub, npm, PyPI, cloud, and SSH credentials.
• Reviewing repository activity.
• Checking for unexpected commits and releases.
• Auditing Git hooks.
• Inspecting AI assistant configuration files.
• Looking for unfamiliar MCP servers or extensions.
• Checking CI/CD logs.
• Comparing packages against known-good versions.
• Notifying the security team.

Deleting node_modules or a virtual environment may remove local files, but it does not invalidate stolen credentials or undo changes already pushed to a repository.

Credentials must be rotated, and the organization must investigate what those credentials were used to access.

The larger Shai-Hulud pattern

The reported Mandiant incident is part of a wider set of attacks involving developer tools and credentials. Separate research has described Shai-Hulud variants targeting packages, CI/CD systems, and AI-tool configuration files.

These are separate campaigns, and the available evidence does not establish that every reported incident came from the same intrusion. The common pattern is the important part: attackers are targeting the systems developers already trust to build and distribute software.

AI coding tools are attractive targets because they sit close to source code, terminals, package managers, credentials, and repositories. This gives them more influence than a traditional autocomplete feature.

The lesson

AI coding assistants are now becoming active participants in development workflows.

They suggest dependencies, edit project files, run commands, inspect repositories, and connect to external services. That makes them useful, but it also places them inside the software supply chain.

The safest response is to stop treating their output as trusted input. Every package still needs verification. Every command needs context. Every token needs limits. Every repository instruction needs scrutiny. Every assistant session should operate with only the access it actually requires.

The Shai-Hulud incident shows that a developer may be one accepted recommendation away from introducing a much larger compromise.

The tool may look like a helpful coding partner. From a security perspective, it should be treated as another component in the trust boundary.