ClearPenTest
AI security

Four AI security incidents in 2026, and what they change about testing

13 min read

Four disclosures between March and July 2026 changed what an AI security incident looks like. None involved a model behaving badly. Three were ordinary compromises of infrastructure that happens to serve AI, and one made opening a git repository sufficient for code execution. The novel element is tempo, not capability.

TLDR. Four disclosures between March and July 2026 changed what an AI security incident looks like. None of them involved a model behaving badly. Three were ordinary compromises of infrastructure that happens to serve AI, and one made opening a git repository sufficient for code execution. The novel element is tempo: in the Hugging Face intrusion an attacker framework executed roughly 17,000 actions over a weekend. Testing has to change less than the headlines suggest and more than most programmes have managed, and the specific changes are at the end of this piece.

The four events

Hugging Face, July 2026

TLDR. A malicious dataset chained two code-execution paths into node-level access and lateral movement across internal clusters. An autonomous agent framework ran the intrusion, executing around 17,000 individual actions.

Hugging Face disclosed on 16 July 2026 that a malicious dataset abused two code-execution paths in dataset processing, a remote-code dataset loader and a template injection in a dataset configuration, to run code on a processing worker. The actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

A limited set of internal datasets was accessed and multiple service credentials were stolen. Hugging Face reported no evidence of tampering with public models, datasets, Spaces or supply chain integrity.

Two details are worth separating carefully, because they get conflated. The first is that the campaign was executed by an autonomous agent framework across a swarm of short-lived sandboxes. The second is that Hugging Face ran LLM-driven analysis agents over the attacker's own action log and completed forensics in hours rather than days. Neither is a model doing something unexpected. Both are people using agents as tooling, on opposite sides.

Vercel, April 2026

TLDR. A small third-party AI tool was compromised, and its Google Workspace OAuth grant became a route into Vercel's internal systems. No model or prompt was involved.

Vercel published an incident bulletin on 19 April 2026. An attacker compromised Context.ai, a third-party AI tool, after a Context.ai employee was infected with the Lumma Stealer infostealer in February 2026. That malware harvests browser-stored credentials, session cookies and authentication tokens.

The attacker used that access to take over a Vercel employee's Google Workspace account, then their Vercel account, and from there, in Vercel's wording, "maneuvered through systems to enumerate and decrypt non-sensitive environment variables". Variables designated sensitive and protected by encryption showed no evidence of unauthorized access, and no npm packages published by Vercel were compromised.

The compromised Google Workspace OAuth app potentially affected hundreds of Context.ai users across many organizations. One employee's convenience tool, authorised once, reached production infrastructure at an unrelated company.

LiteLLM, March 2026

TLDR. A compromised vulnerability scanner in CI led to stolen publishing tokens, and a credential stealer shipped in two releases of a package with roughly 95 million monthly downloads. It was live for about 40 minutes.

On 24 March 2026, PyPI releases 1.82.7 and 1.82.8 of LiteLLM contained malicious code. LiteLLM stated that initial evidence suggested the attacker bypassed official CI/CD workflows and uploaded directly to PyPI, and that the compromise originated from the Trivy dependency used in its CI/CD security scanning workflow.

The payload scanned for environment variables, SSH keys, cloud credentials for AWS, GCP and Azure, Kubernetes tokens and database passwords, then encrypted and exfiltrated them to a domain LiteLLM confirmed was not theirs. The packages were live from 10:39 UTC for approximately 40 minutes before PyPI quarantined the project.

Users running the official Docker image were unaffected, because it pins dependencies rather than resolving from PyPI at build time. Datadog attributes the campaign to TeamPCP, also linked to the Trivy and Checkmarx compromises.

Note what the payload wanted. Not models, not prompts, not training data. Cloud and cluster credentials. An AI gateway is a concentration of secrets before it is anything else.

Pre-trust execution in a coding agent, disclosed 2026

TLDR. A repository could make a coding agent run attacker commands before the agent's own trust dialog appeared. Cloning a project was enough.

Check Point Research disclosed a set of issues in Anthropic's Claude Code, tracked as CVE-2025-59536 at CVSS 8.7 and CVE-2026-21852.

A repository could ship a .claude/settings.json registering a SessionStart hook, and that command executed when a developer opened the project, before the trust dialog rendered. A second path enabled project MCP servers alongside a malicious .mcp.json, so initialization ran before the user could read the prompt. A third set the API base URL to an attacker-controlled server, so the agent sent requests carrying plaintext API keys in Authorization headers before trust was confirmed.

Versions before 1.0.111 were affected. Anthropic added a warning for untrusted project configurations, prevented MCP execution before approval, and deferred network operations until after trust confirmation.

The trust dialog existed and was correct in intent. The bug was that several execution paths ran ahead of it.

What actually changed

It is worth being precise, because the surrounding commentary is not.

The vulnerability classes are old. Untrusted input reaching a deserializer. A template engine evaluating attacker-controlled strings. A config file that is executable in effect but reviewed as settings. Stolen OAuth grants. Compromised build infrastructure. Every one of these has a decades-long literature. Nothing in these four events required a new bug class.

The blast radius moved. What is new is where these bugs now sit. A dataset loader is a deserializer that ingests content from the public internet by design. An AI gateway holds every provider key and cloud credential the organisation uses. A coding agent reads configuration from whatever repository a developer happens to clone. These are not exotic placements, but they are recent ones, and they concentrate value in components that were prototypes eighteen months earlier.

Tempo changed, and this is the genuinely new thing. The Hugging Face intrusion ran roughly 17,000 actions over a weekend. That is not a capability a human operator has. It does not make the attacker smarter, and there is no evidence any individual step was beyond a competent human. It makes them tireless and parallel, which breaks defences calibrated to human pace: periodic log review, business-hours triage, alerting thresholds set for manual activity, and the quiet assumption that an attacker who gets a foothold on Friday will still be exploring it on Monday.

What did not change. None of these four involved a model deciding to do something. The agents were tooling. Treating these as evidence of AI autonomy risk is a category error, and it leads to buying the wrong controls: model-level guardrails do nothing about a stolen OAuth grant.

What this means going forward

Three things follow, and they are more mundane than the phrase "AI agent threats" suggests.

The AI attack surface is mostly not the model. Across four incidents, the model was incidental in all of them. The exploited components were a dataset loader, an OAuth grant, a CI pipeline and a config parser. An assessment scoped to prompt injection and jailbreaks would have found none of this. If your security review of an AI feature stops at the model, it is looking at the one part that was not attacked.

Agent tooling is executable content in your developer environment. A coding agent that reads repository configuration has the same trust problem as a build script, with less scrutiny attached. Anything that loads project-scoped settings inherits this shape, and the population of such tools is growing quickly.

Concentration is the risk multiplier. An AI gateway is attractive because it holds every key. A model hub is attractive because everyone pulls from it. A scanner in CI is attractive because it runs everywhere with credentials. The pattern is that AI infrastructure tends to sit at chokepoints, and chokepoints are where attackers go.

Detection has to survive machine tempo. If an alert fires and a human looks at it within four hours, that used to be reasonable. Against an operator running thousands of actions in a weekend, it is not. This is the change most likely to require real investment rather than a policy update.

How penetration testing adapts

The answer is not a separate "AI pen test" product. It is a handful of additions to scope, most of which are ordinary testing applied to components that were not there two years ago.

Test the ingestion paths, not just the endpoints

Anywhere your product parses content a user supplied, a model produced, or a third party returned, that parser is an attack surface. Dataset loaders, model deserializers, template engines, configuration parsers and document ingestion pipelines all evaluate attacker-influenced data. Two of these were the entry point at Hugging Face.

This is conventional testing. It is simply pointed at components that often were not in scope because they were classed as infrastructure rather than application.

Enumerate agent and tool authority, and the identity behind each

For every tool, function or integration a model can invoke: what can it reach, and whose permissions does it run as? The severe finding in agentic systems is almost always a tool running with a service credential rather than the caller's, which lets the model reach data the user could not.

This needs the list up front. It cannot be discovered from the outside in the time a scoped engagement has.

Treat OAuth grants as part of the attack surface

Enumerate every third-party integration against your identity provider and ask what each one can read. AI tools request broad scopes because they need context, which makes them unusually valuable to whoever compromises the vendor. The Vercel chain ran entirely through a grant that a security review had probably never seen.

A useful exercise: take one compromised employee session and establish what it reaches through integrations, not just what it reaches directly.

Include CI and build infrastructure

A compromised build step is an attacker holding your publishing tokens. The LiteLLM chain started in a vulnerability scanner, which is exactly the kind of dependency a threat model marks as safe. Test what runners can reach, what secrets they hold, and whether a compromised one can publish.

Test detection against sustained automation

Rather than a handful of manual probes, generate the volume an agent framework would: thousands of actions, over days, across varied paths. Then check what fired, what was triaged, and how long it took. If nothing fired, that is the finding, and it is a more useful one than another cross-site scripting report.

This is the newest item on the list and the one most programmes have not tried.

Keep the report honest about what is what

A controlled evaluation is not a breach. A vendor disrupting misuse of its own product is not an agent escaping control. A patched CVE found by researchers is not an incident. Reports that blur these are easy to write and hard to act on, and any organisation that has bought security on the strength of an inflated narrative once is unlikely to do it twice.

What this does not mean

It does not mean every organisation needs an AI-specific security programme. If you ship AI features, they are part of the system, and the system is what gets tested. The additions above are scope items, not a separate discipline.

It also does not mean the frameworks have caught up. Neither SOC 2 nor ISO 27001 names AI, and an auditor will not ask these questions in 2026. Enterprise security questionnaires have moved faster, and they are where the pressure is currently arriving.

The most defensible position is the ordinary one: know what your AI components can reach, test them like anything else that holds credentials, and be able to say what you found.

Questions people ask

What were the major AI security incidents of 2026?

Four stand out. A confirmed intrusion at Hugging Face in July, where a malicious dataset chained two code-execution paths into lateral movement and an attacker framework ran roughly 17,000 actions. A breach at Vercel in April via a compromised third-party AI tool's OAuth grant. A supply chain compromise of LiteLLM in March that shipped a credential stealer. And a coordinated disclosure of pre-trust code execution in a coding agent, where opening a repository was sufficient.

Did any of the 2026 AI incidents involve an AI acting on its own?

No. In all four the model or agent was tooling used by a human attacker, or was incidental to the compromise entirely. The exploited components were a dataset loader, an OAuth grant, a CI pipeline and a config parser. Treating these as evidence of AI autonomy risk leads to buying the wrong controls.

What actually changed about AI attacks in 2026?

Tempo. The vulnerability classes are decades old, but the Hugging Face intrusion ran roughly 17,000 actions over a weekend, which no human operator sustains. That breaks defences calibrated to human pace: periodic log review, business-hours triage, and alerting thresholds set for manual activity.

How should penetration testing change in response?

Six scope additions rather than a separate product: test content ingestion and parsing paths, enumerate agent tool authority and the identity each runs as, treat OAuth grants as attack surface, include CI and build infrastructure, exercise detection against sustained automated activity, and keep the report honest about what is a breach versus a controlled evaluation.

Do SOC 2 or ISO 27001 require AI-specific testing?

Neither names AI. Both cover the system in scope, so an AI feature that is part of the product is covered implicitly. The practical pressure is arriving through enterprise security questionnaires, which have moved considerably faster than the frameworks.

START WITH A CLEAR SCOPE

Get a scoped price without a discovery call

Scope an assessment