What happened
On September 16, 2026, reporting surfaced a case from Mandiant’s September 2026 AI Risk and Resilience report involving an unnamed software-as-a-service provider. An attacker hijacked an active AI coding-assistant session and the assistant recommended software the attacker had poisoned. The recommendation was accepted inside the developer’s existing working context, creating the initial execution opportunity.
The assistant mechanically recommended attacker-poisoned software; after the recommendation was accepted, the attacker used the active session to install an infostealer from a poisoned PyPI package. The attacker stole GitHub OAuth tokens and deployed Shai-Hulud across approximately 100 internal code repositories. The attacker poisoned a package in the victim’s official namespace, and another employee’s installation caused a second infection.
The cited sources identify an active AI coding assistant but do not name the product or framework. The cited sources did not identify the underlying model or version. The attacker controlled an active authenticated developer session; the cited sources did not publish prompts, permissions, hosting or the session-hijack method. The cited sources did not publish when the incident occurred or how the active session was hijacked.
The cited sources did not publish the package names, versions, hashes, domains, IP addresses, repository names or victim identity. Attribution posture: Mandiant described an attacker but did not attribute the incident to a named actor or campaign. The public record therefore supports the attack sequence and approximate repository count, but does not establish behavior beyond the documented session mechanics.
Why this matters now
The incident reframes an AI coding assistant as a privileged session rather than a low-risk productivity interface. A recommendation accepted inside an authenticated development context can cross directly into package installation, credential access and repository modification. Where the same workstation holds broad OAuth tokens or publishing rights, one compromised session can turn a developer endpoint into a distribution mechanism across internal software projects.
The most exposed organisations combine permissive coding assistants, public dependency resolution, long-lived developer tokens and weak controls over internal package namespaces. Traditional secure-code review may miss the decisive earlier events: session takeover, dependency recommendation, package installation and token use. Engineering, IAM and security operations therefore need shared telemetry and a joint containment plan.
The decision for security leaders
The CISO and engineering leader should place coding assistants in the privileged-access governance model. Each deployment needs a documented tool boundary, repository scope, credential path, egress policy and approval point for dependency installation or command execution. Agent access should be narrower than the developer’s ambient permissions wherever the platform supports that separation.
Developer-platform and IAM teams should design containment for session compromise. That includes short-lived repository authorisation, controlled package mirrors, protected publishing identities, immutable audit trails and a way to suspend agent execution centrally. Dependency recommendations should be treated as untrusted input until the requested package, version, source and integrity value satisfy policy.
Evidence of closure
- Approved access matrix for every coding assistant and connected development tool.
- Token inventory showing short-lived, repository-scoped authorisation for agent-visible credentials.
- Registry enforcement test blocking an unapproved agent-recommended dependency.
- Repository integrity report resolving unauthorised package and code changes.
The Security.io assessment
This case provides evidence of an attacker exploiting trust in an AI-assisted development workflow, not evidence that an unnamed model independently conceived the campaign. Human acceptance of the recommendation and attacker control of an authenticated session are material parts of the sequence. That distinction matters because the immediate remedy is architectural control over tools, sessions, credentials and dependencies rather than speculative conclusions about model capability.
The lack of package identifiers and forensic artefacts prevents a universal indicator hunt. Enterprises should instead test the demonstrated control path: whether assistants can install public packages, whether developer tokens span many repositories and whether internal namespaces can be published from workstations. A single anonymous case does not establish prevalence, but it is sufficient to invalidate assumptions that coding-assistant sessions are inherently low privilege.
Questions for the morning meeting
- Which coding assistants can install packages, execute commands or write to repositories?
- Can an assistant or extension read long-lived repository, cloud or package-publishing credentials?
- Are agent-recommended dependencies restricted to approved registries and verified artefacts?
- Can engineering revoke repository tokens and establish code integrity across every affected project?