A package recommendation can look like a routine development decision. When it comes from a compromised AI coding assistant, accepting it can expose far more than the application being built.

Mandiant’s September 2026 AI Risk and Resilience report describes an intrusion in which an attacker hijacked an active coding-assistant session at a SaaS provider. The assistant recommended a poisoned package, setting off a chain of credential theft, repository compromise and further infection.

For security and engineering leaders, the lesson extends beyond dependency management: AI-assisted development requires governance over the authority, execution and access behind every change.

From a trusted recommendation to repository compromise

According to Mandiant, the compromised assistant recommended an external software package. Once the recommendation was accepted, the attacker used a poisoned PyPI package to install an infostealer and harvest GitHub OAuth tokens.

Those credentials enabled the deployment of the self-propagating Shai-Hulud worm across approximately 100 internal repositories, stealing repository secrets and proprietary source code. The attacker subsequently poisoned a package within the organisation’s official namespace, causing another infection when an employee downloaded the compromised version.

The public account does not explain precisely how the active session was hijacked. It also does not establish whether approval fatigue or a particular scanning failure contributed to the incident. Those details should remain open questions.

What the case does demonstrate is how a trusted development interaction can connect to a much broader compromise.

The security boundary extends beyond generated code

Reviewing AI-generated code remains essential. But code review addresses only part of an assistant’s activity.

Depending on its configuration and permissions, a coding assistant may install dependencies, execute commands, read local files, interact with repositories and invoke connected tools. Each capability introduces a separate question about authority.

A suggestion to install a package becomes an execution decision. Execution may expose credentials available in the environment. Those credentials may grant access to repositories and publishing workflows.

The practical risk therefore depends on more than the assistant’s output. It depends on what the surrounding environment allows that output to trigger.

An approval prompt is one checkpoint in this workflow. Its value depends on whether the reviewer can understand the proposed action, its source and its consequences.

What should an organisation be able to reconstruct?

When suspicious activity occurs, teams need to connect the original task to the actions taken and the changes produced.

That means being able to answer:

  • Who initiated the task? Identify the human requester, agent and authority under which the session operated.
  • Where did the recommendation originate? Establish whether it came from the user, the assistant, retrieved content or a connected tool.
  • What actually executed? Record tool calls, commands, dependency versions and execution outcomes.
  • Which resources were accessed? Correlate activity with credential use, repository access and external connections.
  • Which controls applied? Preserve the relevant policy decisions, approval records and exceptions.
  • What changed? Connect execution to file modifications, commits, dependency updates and published artefacts.

An assistant’s conversation history alone cannot establish all of this. Application records need to connect with endpoint, identity, repository and network evidence.

Pair preventive controls with usable evidence

Mandiant recommends validating AI-recommended dependencies against approved allowlists and cryptographic checksums, isolating local credentials, and routing dependency traffic through controlled internal repositories. These measures address specific links in the reported attack chain.

Evidence serves a complementary purpose. It helps teams determine whether controls operated as intended, investigate unexpected behaviour and identify what requires containment.

For example, an approved dependency installation should be traceable to the exact package and version installed, the process that installed it and the changes that followed. A record that merely says “installation approved” leaves essential questions unanswered.

Evidence collection also needs boundaries. Logs should redact secrets, restrict access to sensitive content and follow defined retention policies. Collecting more data is useful only when that data can be trusted, protected and interpreted.

Making agentic SDLC governance practical

At Secuarden, we frame agentic SDLC governance as a practical discipline: define what development agents may do, enforce those boundaries and preserve evidence of their actions.

This extends familiar development controls to workflows where agents participate in decisions and execution. The objective is to make responsibility and authority explicit throughout the development lifecycle.

A useful starting point is one workflow: introducing a dependency. Can your team connect the request, recommendation, approval, installation, credential use and resulting commit? Any missing connection identifies a concrete governance gap.

Govern the code agents produce—and preserve evidence of the privileged development activity that produced it.

Source: Mandiant, AI Risk and Resilience Report 2026.