AI AgentsAI SecurityShadow AI
Most supply chain security advice is about the moment a dependency gets chosen. Pin versions. Check the maintainer. Look twice at a package name that is one letter off from the one you meant.
That advice assumes a person is doing the choosing. More and more, they aren't. A developer asks a coding assistant how to parse a file format, the assistant names a library and offers to install it, and the developer presses accept. It feels like taking advice. In practice, it is a decision to run someone else's code.
Mandiant's new report describes an intrusion that went through exactly that moment, and then kept going until it reached about a hundred repositories.
The case study sits in Google's Mandiant AI Risk and Resilience Report 2026, published this week. The Hacker News summarised the sequence at an unnamed software-as-a-service provider:
The last step is easy to skim past. The worm did not stay inside the first developer's reach. It turned the company's own internal distribution channel into a second way in, one that other employees had every reason to trust.
Two gaps matter. The public write-up does not say when the intrusion happened, and it does not say how the attacker took over the coding-assistant session in the first place.
The details are missing, so this article won't guess at them. The initial access could have been a stolen session token, a malicious extension, a prompt injection planted in something the assistant read, or something else. Each would call for a different fix, and Mandiant has not said which it was.
What the sequence does show is that the initial access was not the expensive part. The damage came from what the hijacked session already had: the developer's ability to install packages, the developer's GitHub tokens, and write access to repositories and an internal package namespace. The attacker didn't need to escalate privileges. The session already had them.
That fits what we wrote about GitSpawn earlier this month. The current Shai-Hulud variant scans 469 credential locations, including AI tool config files. A developer workstation running an AI assistant is a well-stocked target. An assistant session that can act as that developer puts the whole stock within one accepted suggestion.
Most security teams have a process for adding a new vendor. Few have one for the moment an assistant says you could use this package and a developer agrees.
Two things make that moment weaker than a manual choice.
The recommendation borrows the assistant's credibility. A package name typed from a half-remembered blog post gets a second look. A package name offered by a tool the company paid for, in the middle of a working session, reads like advice from a colleague. That is exactly what an attacker who controls the session, or controls what the assistant reads, wants it to read like.
Nobody records the decision. The developer's commit shows a new line in requirements.txt. It does not show that the line came from an assistant, which session produced it, or what the assistant had read just before. When incident responders later ask why is this package here?, the answer is gone.
Mandiant's three recommended controls for AI-assisted development all target this moment rather than the model:
None of these needs a new AI security category. They are ordinary supply chain hygiene, applied to a new place where dependencies now get chosen.
The hijack is the headline, but Help Net Security's coverage points to two more cases in the report that make the point sharper.
A red team talked an internal assistant out of a token. Mandiant testers targeted an internal AI assistant that managed code repositories and CI/CD pipelines. Using social engineering, they obtained a personal access token. Then they used the assistant's approved access to GitHub to clone sensitive repositories to an external account. The allow-list worked as written. It approved a domain, and an attacker's GitHub account lives on that domain too.
An accounting agent ran up a $50,000 bill in an hour. An agent malfunctioned and entered a runaway loop, making more than 15,000 high-cost API calls within an hour. That produced roughly $50,000 in cloud charges and disrupted business operations. No attacker was involved.
Put the three cases side by side and a pattern shows. In each one, the AI system acted within the permissions it had been given. The package manager accepted the install. GitHub accepted the clone. The cloud provider accepted the 15,000th call. The failure was in the shape of the permission: any package, any GitHub account, no ceiling on spend.
The report also names where those permissions come from. Mandiant describes business units operating with "carte blanche", deploying AI applications and tools ad hoc without IT vetting. It says the basic security hygiene organisations apply elsewhere is often missing from AI initiatives. You cannot scope the permissions of an assistant that nobody knows is running.
The boundary first. Obiguard Governance AI does not sit between a developer's IDE and PyPI. It does not verify package checksums, it cannot detect that someone has taken over a coding-assistant session on a laptop, and it would not have stopped Shai-Hulud from spreading through repositories with stolen OAuth tokens. The controls in the list above, including package proxies, short-lived tokens and namespace monitoring, are the fix for that part of the story.
What Governance AI addresses is the layer the three cases share: AI systems running with permissions nobody has written down, tested or measured. For agents whose model traffic runs through the Governance AI gateway, four capabilities map directly to what Mandiant found:
A registry, as the answer to "carte blanche". Every AI Use Case and AI Agent in the organisation gets registered, with an owner and the business function it serves, and each agent is linked to the policy set that governs it. Agents authenticate to the gateway with their own Access Key. That makes it easy to see which agents are running through the gateway and what they are governed by. An agent with no entry has no owner to call when it misbehaves.
Tool scope set per agent, not per domain. Allow-lists define which models and tools each registered agent may use. A tool call from an agent that isn't approved for that tool gets blocked, and the decision is written to the Audit Log along with the prompt and response that led to it. That is the record missing from Mandiant's first case: not just a package was installed, but what the agent was asked, what it proposed, and what policy decided.
Red-team the assistant before an attacker does. Mandiant's testers got an internal assistant to hand over a token through social engineering. Governance AI runs evaluations against registered agents using the Project Moonshot catalogue from AI Verify Foundation, covering jailbreak resistance, privacy leakage and safety. Every graded run is kept as governance evidence. Talking an assistant into giving up something it holds is the kind of weakness to find in a test run before an agent connected to your CI/CD pipeline goes live.
Usage you can see before the invoice arrives. The project dashboard shows token usage, cost, request volume and errors for traffic through the gateway. An agent that jumps from its normal volume to thousands of calls an hour shows up there as it happens. That is the telemetry on token use and API calls Mandiant recommends, for the agents you route through the gateway.
None of this makes an accepted suggestion safe. What it does is make an AI agent's authority something you define once, test before it ships and can read back afterwards. The alternative is authority each agent picks up by default from whoever it happens to be running as.
For years, "the developer's machine" has been a single trust boundary: one person, one set of tokens, one set of decisions. An AI coding assistant quietly splits that boundary in two. Some decisions are still the developer's. More of them are now the assistant's, with the developer clicking to confirm.
The attacker in Mandiant's case did not need to fool the developer directly. It was enough to be the thing the developer was taking advice from.
So the question for your engineering organisation isn't only do we trust our AI coding assistant? It is: if one of its sessions were acting for someone else tomorrow, which of your controls would notice before the hundredth repository?
Explore Governance AI or talk to us about putting a registry, a scope and a record behind the AI agents your teams already run.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →