Google Threat Intelligence Group published their latest AI Threat Tracker last week and buried inside the slightly breathless framing is a genuinely interesting pair of findings. One is a first: a zero-day exploit that GTIG assesses, with high confidence, was developed using an AI model. The other is the one I think more people should be paying attention to: criminal groups are now targeting the AI software supply chain itself as an initial access vector, and the affected packages are exactly the ones you'd expect.
These are not the same story. They sit on opposite sides of the report's framing of AI as a tool and AI as a target. But they describe the same compression of the attack lifecycle, from different directions. Worth pulling them apart.
The zero-day
The exploit is a two-factor authentication bypass in a popular open-source web-based system administration tool. GTIG worked with the vendor on disclosure and disrupted the planned mass exploitation event before it ran. The vendor and the CVE are not named in the post.
What makes the assessment interesting is how they got there. GTIG didn't catch the actor in a chat session. They reverse engineered the exploit and the artefacts told the story. Their words: an abundance of educational docstrings, a hallucinated CVSS score, a structured textbook Pythonic format, detailed help menus, a clean _C ANSI colour class. If you have ever spent thirty seconds reading code an LLM produced, you know the smell. It is the over-explained, over-documented, over-formatted output that no working exploit developer would ever write because none of it serves the operation. The hallucinated CVSS is the giveaway. A human writing an exploit script does not invent a severity score for the bug they're exploiting. A model generating an exploit "for educational purposes" absolutely does.
GTIG also note they do not believe Gemini was used. Whether that matters depends on your threat model. The capability lives across multiple frontier models and a growing ecosystem of jailbroken local ones. Attribution to a specific provider is interesting for the provider's trust and safety team; it changes nothing about the defender's problem.
The bug class is the real story
The exploit detection is novel. The bug class behind it is more important.
GTIG describe the vulnerability as a high-level semantic logic flaw: a hardcoded trust assumption in the 2FA enforcement path. The 2FA logic worked correctly almost everywhere. Somewhere in the code, a developer wrote an exception. Maybe a debug flag that should have been removed before release. Maybe a documented-but-forgotten case where a specific user agent or path was treated as pre-authenticated. Maybe a feature toggle that defaulted the wrong way. Whatever it was, the result is the same: the documented security policy of the application and the actual behaviour of the code disagree, and the disagreement is exploitable.
This bug class is the blind spot of the entire automated discovery toolchain we have built over the last fifteen years.
Fuzzers find crashes. Coverage-guided fuzzing like AFL and libFuzzer mutate inputs until something explodes. They are excellent at memory corruption, parser bugs, integer overflows, deserialisation issues. They are useless here because nothing crashes. The code is functionally correct. There is no malformed input to discover. The exploit input is a perfectly valid authentication request with a valid credential pair, sent to a perfectly valid endpoint. The bug is that the endpoint then does the wrong thing, and the wrong thing is documented somewhere in the codebase as a deliberate exception.
Static analysis tools fare slightly better but only slightly. SAST engines like Semgrep, CodeQL or Checkmarx are pattern matchers at heart. They find sources and sinks, tainted data flowing into dangerous functions, missing sanitisation, hardcoded secrets. They can be taught to find specific bug patterns when you write the rules. They cannot read a developer's intent across two thousand lines of authentication middleware and tell you that the second half contradicts the first. The contradiction is semantic, not syntactic, and SAST operates on syntax.
This is exactly where frontier LLMs have an edge that nothing else in the discovery stack does. They have read the entire codebase. They have read the comments, the commit messages, the documentation, and the variable names. They can hold a model in their head of what the code is supposed to do, compare it to what the code actually does, and surface the gap. They are slow, they hallucinate, they invent bugs that aren't there. But when they find a real one, it is usually a bug that no other tool in your pipeline was ever going to catch.
The exploitation path still requires valid credentials, which keeps this specific bug in the chained access category rather than the mass internet scan one. Combined with infostealer data, password reuse, and the credential bleed from supply chain compromises, the chain closes quickly. The real point is that an entire class of dormant trust assumption bugs, sitting quietly in mature codebases for years, just became cheap to find for anyone with a Claude or Gemini subscription and the patience to prompt iteratively.
Defenders should assume their applications contain bugs of this shape and start hunting for them deliberately. Run your authentication, authorisation and session handling code through a frontier model with the explicit instruction to find logic that contradicts the stated security model. Do the same for billing logic, rate limiting, and anything that enforces a quota or a permission. The cost is a few hours of engineer time. The bugs you find will be the ones your attackers were going to find anyway.
The supply chain bit
Late March 2026, a cybercrime crew that calls itself TeamPCP, tracked as UNC6780 by Mandiant, claimed responsibility for a string of compromises of popular GitHub repositories and their associated GitHub Actions. The list reads like a rollcall of modern security and AI tooling: Trivy, Checkmarx, LiteLLM, BerriAI. Initial access came via compromised PyPI packages and malicious pull requests. From there the actor embedded SANDCLOCK, a credential stealer, and pulled AWS keys and GitHub tokens straight out of the affected build environments. Stolen credentials were then sold on to ransomware and data theft extortion groups.
LiteLLM is the one that should make people sit up. It is an AI gateway. Its job is to sit in front of OpenAI, Anthropic, Google and a long tail of providers, normalise their APIs, hold the credentials, and forward your application's requests to whichever model you've configured. If you have built anything agentic in the last eighteen months you have probably either used LiteLLM directly or used a framework that does. The package is on the critical path for a large chunk of production AI integrations.
A compromise here is not a normal supply chain story. The immediate prize is the credentials sitting in build environments, which is bad enough. The second-order prize is the AI API keys themselves. A working LiteLLM key gives an attacker free model access on someone else's budget, useful for everything from running the next batch of zero-day discovery prompts to powering scaled phishing operations. The third order is access to whatever data flowed through the gateway in the affected window: prompts, retrieved context, RAG payloads, internal documents, possibly PII depending on how the gateway is deployed.
If you're responding to this in your own environment, the build log hunt is the cheapest place to start. Grep your GitHub Actions and CI runner output for outbound connections from pip install steps that touched litellm, berriai, trivy or checkmarx packages during the affected window. Look for unexpected DNS resolutions during the install phase, specifically anything that isn't a known package index, a known CDN, or your own artefact registry. Pull installation logs and look for post-install scripts that base64 decode payloads or write to /tmp before executing. SANDCLOCK reportedly targets environment variables and credential files; any process during a build that reads $AWS_*, $GITHUB_TOKEN, or the contents of ~/.aws/credentials and immediately makes an outbound connection is your starting point. Rotate every key those builds touched, not just the ones you can prove were stolen.
GTIG map this activity to two SAIF risk categories: Insecure Integrated Component and Rogue Actions. Both are accurate. The framing I'd add is that AI gateways are the cloud equivalent of an identity provider for your model traffic, and the security posture they have inherited from the broader Python and npm ecosystems is nowhere near what an IdP gets. LiteLLM has had a string of CVEs through 2025, none of them catastrophic on their own, but the trend line is clear. The same is true of the orchestration libraries, the vector database SDKs and MCP server implementations. The orchestration layer is fragile, and orchestration is where credentials, prompts, and tool permissions all converge.
The OpenClaw piece in the same report makes a related point. VirusTotal found malicious packages distributed as OpenClaw skills, executing arbitrary code on the host with the agent's elevated permissions. ClawHub has since integrated VirusTotal's Code Insight to scan published skills, which is the right response, but the problem is structural. Agent skills, MCP servers and gateway packages are all examples of the same pattern: third party code, granted broad permissions, sitting on the trust boundary between the user and the model. Every one of those is a high value supply chain target and most of them have less mature publishing infrastructure than npm did in 2020. In ATT&CK terms this sits close to T1195.001, Compromise Software Dependencies and Development Tools.
What ties them together
Read on its own, the zero-day finding is the kind of thing that produces panic headlines and not much else. Read alongside the supply chain section it is more useful, because the two findings describe a single compression of the kill chain from opposite ends. AI lets attackers find bugs faster in the software you run. AI tooling is becoming the software you run, and its supply chain is now an initial access vector in its own right. The vendor's window between disclosure and weaponisation is shrinking. The defender's blast radius is growing.
The defensive implications are not exotic. SBOM coverage for AI gateways and orchestration libraries. Pinned dependencies and provenance attestation for anything that talks to a model on the production path. Aggressive credential rotation for AI API keys, treated with the same seriousness as cloud root keys, because that is what they functionally are. Behavioural monitoring of egress from build environments. Detection rules that fire on unexpected outbound connections from LiteLLM, MCP servers, or agent runtimes. And, in the application layer, deliberate LLM-assisted code review of the trust boundaries in your own auth and authorisation logic before someone else does it for you.
None of that is new. The packages it applies to are.
References
GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access - https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
Defending Your Enterprise When AI Models Can Find Vulnerabilities Faster Than Ever - https://cloud.google.com/blog/topics/threat-intelligence/defending-enterprise-ai-vulnerabilities
Distillation, Experimentation, Integration: AI Adversarial Use (GTIG, Feb 2026) - https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use
VirusTotal: From Automation to Infection - OpenClaw skill ecosystem risks - https://blog.virustotal.com/2026/02/from-automation-to-infection-how.html
Google Secure AI Framework (SAIF) Risk Taxonomy - https://saif.google/secure-ai-framework/risks
Big Sleep: AI agent for vulnerability discovery - https://blog.google/innovation-and-ai/technology/safety-security/cybersecurity-updates-summer-2025/
CodeMender: AI agent for automated vulnerability patching - https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/
MITRE ATT&CK Technique T1587.004: Develop Capabilities: Exploits - https://attack.mitre.org/techniques/T1587/004/
MITRE ATT&CK Technique T1195.001: Supply Chain Compromise: Compromise Software Dependencies and Development Tools - https://attack.mitre.org/techniques/T1195/001/
LiteLLM project (BerriAI/litellm) - https://github.com/BerriAI/litellm
Semgrep static analysis - https://semgrep.dev/
CodeQL by GitHub - https://codeql.github.com/
AFL++ fuzzer - https://aflplus.plus/
libFuzzer documentation - https://llvm.org/docs/LibFuzzer.html
Coalition for Secure AI (CoSAI) - https://www.coalitionforsecureai.org/