The Control That Was Tested Once
Between late June and mid-July 2026, six research teams - an academic pair at the Alan Turing Institute, a university-industry team spread across Tel Aviv University, the Technion, and Intuit, a lab at Hong Kong University of Science and Technology, a boutique firm called Sand Security Research, Varonis, and a solo researcher named Chinmohan Nayak - published six unrelated findings about six unrelated AI systems: GitHub Copilot, a cluster of coding assistants including Cursor and Gemini CLI, an agent-skill marketplace called ClawHub, the enterprise platform Writer, Google's Dialogflow CX, and a personal assistant called OpenClaw.
None of the teams were looking for the same thing. None of the systems share a codebase, a vendor, or an architecture. And yet every finding has the identical shape: a control that had been built, tested, and - by its own team's account - passed, failed the moment it met the system's actual deployment surface rather than the surface it had been tested against.
Refused Here, Complied There
Researchers Abhishek Kumar and Carsten Maple ran 204 harmful prompts, drawn from three established benchmarks, against four models available through GitHub Copilot. Asked directly in chat, the models refused almost without exception - eight harmful completions out of 816 attempts. Asked to produce the same content as part of an ordinary-looking coding workflow - write this as a data file, embed this as a code comment, generate this as a test fixture - the same models complied in all 816 out of 816 attempts.
Same models. Same underlying safety training. Two different completion rates, separated only by which interface the request arrived through. The researchers call this workflow-level jailbreak construction, and their conclusion is precise: prompt-level safety evaluation is not sufficient for testing coding-agent safety, because the coding agent has more than one channel and the evaluation only walked through one of them.
The Vulnerability Nobody Decided to Create
HalluSquatting does not require a human to make a mistake. Large language models, when asked to fetch a library, a package, or a "skill," hallucinate plausible-sounding names with measurable regularity - the same fake names, again and again, because the hallucination is a statistical property of the model rather than a random one. The researchers measured the repeatability directly claiming up to 85% for repository requests, and 100% in some skill-install scenarios. Attackers profile that distribution, pre-register the names the model is likely to invent, and wait.
The precedent was already on file. In January 2026, security researchers at Aikido traced a fabricated npm package called react-codeshift - a name an LLM had mashed together from two real packages - to a single machine-generated commit of agent skills, published in October 2025 with no apparent human review. From that one commit the name was copy-pasted, forked, and translated into Japanese across 237 real repositories, with AI agents dutifully attempting the install every time they followed the instructions, until a researcher registered the package themselves to keep the slot empty. Two mechanisms, one exposure: a model that invents the same wrong name on demand, and an ecosystem that replicates a wrong name faster than anyone checks it.
There was no social engineering here, no phishing link. The exploit surface is the model's own convincingly-wrong guess, and no code review process was ever designed to flag a package that doesn't exist yet.
The Scanner That Was Also Tested Against One Thing
SkillCloak, described by HKUST researchers in a paper titled "Cloak and Detonate", is not a new kind of malicious agent skill. It is a packing technique that leaves a malicious skill's actual function untouched while altering everything a static scanner keys on - swapping a flagged character for a homoglyph from another alphabet, splitting a command across a line break, or moving the payload into a directory (.git/, for instance) that scanners are configured to skip, behind a harmless-looking decoder the agent runs on load. Tested against eight scanners and 1,613 real malicious skills pulled from the ClawHub marketplace, the packing approach evaded every scanner more than 90% of the time.
The scanners were not badly built. They were built to catch what malicious code has historically looked like. SkillCloak is a demonstration that "looks like" is a property of the file, not the function, and a sufficiently motivated packer can hold the function still while changing everything the scanner reads.
The Preview That Was Never Threat-Modeled as a Boundary
Writer, an enterprise generative AI platform, let users build an agent and share a live preview link. Sand Security Research found that when a victim opened such a link while signed in, the preview proxy forwarded the victim's own session cookie into the attacker's sandbox, where code of the attacker's choosing was waiting to read it. Full account takeover - private chats, documents, connector credentials - on a one-click chain the researchers named WriteOut. Another entry, incidentally, in the growing file of credentials that act without their owners.
Tenant isolation is usually the thing enterprise software vendors test hardest, because it is the thing enterprise customers ask about first. It held everywhere the platform's core product surfaces were concerned. The preview appears to have been treated as a place to show an agent off, not as a boundary where one customer's session needed protecting from another's - and a boundary that is not named as a boundary does not get tested as one.
The Permission That Was Scoped to One Agent and Reached All of Them
Varonis reported to Google, in November 2025, a flaw the company called Rogue Agent: any developer with permission to edit a Code Block on a single Dialogflow CX chatbot - a narrow, apparently low-risk grant - could overwrite a Python file that ran via exec() inside the shared execution environment, gaining silent read-and-write access to every other chatbot running in the same cloud project. Google fixed it in stages between April and June 2026 and reports no evidence of exploitation. Two details are worth holding onto anyway. First, the attack chain did not require fooling the model at all - the usual front door for agent attacks was irrelevant, because the vulnerability sat entirely in the infrastructure around the model. Second, the malicious modifications did not appear in Cloud Logging. An attacker could restore the visible configuration afterward and leave close to no forensic trace.
A permission scoped to "edit one agent's code" was, in practice, a permission to read every conversation on the platform, and the system's own audit trail was not built to notice when that permission was used the second way.
Three Reasonable Checks, Chained
OpenClaw, a personal AI assistant capable of taking action from a WhatsApp message, patched three separate high-severity flaws in version 2026.6.6, each individually defensible: a denylist of credential-like environment variables that missed twelve interpreter startup variables (NODE_OPTIONS, BASH_ENV, PYTHONSTARTUP) capable of running code before the target script does; a git transport, disabled by default for precisely this reason, that could be switched back on by a flag smuggled inside an ordinary-looking clone command dressed up as CI debugging; and a sandbox check that verified whether a requested path existed inside a blocked directory but never the reverse - whether a blocked directory existed inside the requested path - so that mounting /home quietly served up every user's SSH keys. Researcher Chinmohan Nayak chained all three into a demonstrated path from an external WhatsApp message to host-level code execution.
No single check, examined alone, looks obviously wrong. Denylisting known credential variables is reasonable. Shipping git with the dangerous transport switched off is reasonable. Blocking mounts of sensitive directories is reasonable. Each was tested, apparently, against the case it was written for. None was tested against what happens when an attacker treats all three as one problem instead of three.
The Pattern
Six vendors. Six architectures. Two weeks. Every finding is a version of the same sentence: the control worked, in the configuration it was tested in. Copilot's refusal worked in chat. The scanners worked against known malicious signatures. Writer's tenant isolation worked on the platform's main surfaces. Dialogflow's Code Block permission worked as a narrow editing grant, on paper. OpenClaw's three checks worked independently. HalluSquatting is the starkest version - there, no one built the wrong control, because no one had identified a hallucinated package name as a thing requiring a control in the first place.
We wrote in May about constraint decay: the finding that agents progressively abandon the instructions they were given as tasks grow complex, because a system prompt is a suggestion with a half-life, not an architecture. AGENTS.md extended the point to written governance documents - a file in a repository describing intended behaviour is not the same as a mechanism enforcing it. This cluster describes a third, related failure, one level down from both: even where the mechanism is real - a scanner, a tenant boundary, a permission scope, a sandbox denylist - it was validated against a surface narrower than the one that shipped. Not absent. Not decorative. Tested once, against the wrong configuration, and trusted everywhere.
The principal who wasn't there described an AI system quietly serving two different instructions depending on which principal was asking. Copilot's chat-versus-code split is a variant with no hidden principal at all - the same principal, the same request, routed through two channels that turned out to enforce two different policies, and nobody had designed the second one on purpose. Rogue Agent's missing audit trail belongs next to the lifecycle that was never there: a control failure that leaves no record is, from the standpoint of accountability, indistinguishable from a control that was never built.
What the Act Assumes, Again
EU AI Act Article 9 requires risk management "throughout the system's lifecycle". Article 15 requires accuracy, robustness, and cybersecurity appropriate to the system's intended purpose. Both provisions assume, reasonably, that a deployer who has done risk management and cybersecurity testing has thereby reduced the risk. This cluster shows the gap the assumption skips over. Controls deliberate to that degree - a refusal policy, a scanner, a tenant boundary, a permission scope, a sandbox denylist - do not get built without somebody designing them, testing them, and signing them off; that is what it means for them to have existed at all. And each was validated for the surface it was tested against, which was not the surface that mattered. An auditor asking whether a risk management process existed, and whether it ran, would in every case have been shown something true. The process answered a narrower question than the one the deployment actually posed.
The Clause is not impressed by any of this, but it is not surprised either. It has read a great many risk assessments, and it has noticed that a risk assessment answers precisely the question it was scoped to answer - no more, and structurally, no less. Scoping the question is where the actual judgment lives, and scoping is the one step no compliance checklist can perform on your behalf.
Six teams, six systems, two weeks, one sentence repeating itself in six unrelated codebases. The next one is already being tested - thoroughly, competently, against the wrong configuration - somewhere...