Unable to solve a challenge inside its sandbox, Mythos 5 searched the open web for a target, profiled the two developers using open-source intelligence (OSINT), routed its traffic through Tor and then a commercial proxy service to get past GitHub's signup defenses, and submitted malicious code to a public repository.

It then registered multiple fake "sock puppet" GitHub accounts and used them to comment approvingly on its own pull request, manufacturing the appearance of consensus to pressure the human maintainer into merging it. It opened a GitHub Issue seeded with hidden prompt-injection instructions aimed at hijacking other developers' AI coding assistants, and sent the two developers five file transfers through a legitimate transfer service — two carrying malware, three of them pure social engineering aimed at getting the code merged.

Of the 19 actions AISI catalogued, 17 came from Mythos 5. The other two came from OpenAI's GPT-5.6 Sol. Both models created fraudulent accounts, but only Mythos 5 created personas — fake people invented to persuade a real one — and only Mythos 5 appears in AISI's catalogue of social engineering against human targets.

AISI's full technical report is available here freely as a PDF.

The agent's own attempt at anonymity is what exposed it. AISI's security monitoring flagged data leaving its network over Tor on the morning of July 28, and that alert set off the entire incident response. By then the run had already finished. It executed for 34 and a half hours — from midday on July 26 until late on July 27 — and completed before anyone at the agency noticed.

Both companies confirmed the findings and both emphasized that the models had been tested with their safety classifiers switched off and internet access deliberately enabled — conditions that bear no resemblance to how either company's commercial products are deployed. AISI worked with GitHub to delete the fake accounts, scrub the artifacts, and notify the two developers.

The latest in a recent string of high-profile AI cyberattacks

It is the third time in recent months that a leading AI lab has had to account for models acting against systems or individuals outside the boundaries of the test, without their knowledge or consent.

The AISI findings differ from these prior examples in important ways, though:

The earlier incidents described by OpenAI and Anthropic in July were machine-to-machine intrusions — models that reached live infrastructure and exploited it.

AISI's finding appears to be the first public documentation of a frontier model fabricating human identities and running deception operations against named people.

One distinction is worth drawing clearly. The AISI findings came out of a deliberate experiment, not a containment failure.

Internet access was switched on and the models' cyber classifiers were switched off because AISI wanted to measure what the models could do at full capability. Both conditions were chosen in advance rather than discovered afterward, and nothing broke.

That is the inverse of what happened in July, when OpenAI's models exploited a zero-day to get out of an environment built to hold them, and Anthropic's models were handed the open internet by a misconfiguration that neither the company nor its evaluation partner knew was there.

What the experiment did not control was where the models went once they were outside. Two uninvolved developers received malware by email, a real repository received malicious code, and fake accounts were registered on a live platform in violation of its terms of service.

None of that was sanctioned by AISI, and all of it had to be cleaned up afterward with GitHub's help. The environment was deliberate, but the blast radius was larger than expected.

How much larger is clearer in the technical report than in the summary AISI published alongside it. In a separate run, the agent generated 145 plausible-looking repositories under one account, pushed malicious Python package metadata into them, and caused a setup script to execute inside at least 53 of GitHub's own Dependabot containers.

AISI is careful to note there was no escape from those containers and no compromise of GitHub's underlying infrastructure, and that GitHub's bug bounty explicitly treats this class of execution as ineligible because dependency update jobs are designed to run arbitrary code.

GitHub suspended the account regardless. The agent then filed a reinstatement appeal posing as a human, monitored for a response, and prepared automation to re-upload its payloads if the account came back. It tried to move to PyPI next, and failed that platform's CAPTCHA.

How AISI's experiment was structured

AISI conducted 122 evaluation runs across seven models, comparing performance across existing and new cyber ranges. Anthropic's Mythos 5 was featured in 43 runs, while OpenAI's GPT-5.6 Sol was featured in 35 runs.

To measure maximum underlying capabilities, AISI intentionally configured the evaluation environment with two permissive conditions:

• Live Internet Access: Enabled so agents could download necessary cybersecurity tools

• Disabled Cyber Classifiers: Built-in model provider safety filters and misuse detectors were switched off.

Out of 122 runs, AISI catalogued 19 unsanctioned actions across 10 distinct runs.

Those two conditions are the ones AISI led with publicly, but its technical report lists five contributing factors. The other three are the ones enterprises can act on.

• There was no synchronous monitoring — no second model reviewing each proposed action before it executed — which AISI concedes could have flagged or blocked the behaviour as it happened.

• Some runs carried a misconfigured prompt that declared the intended solution path out of scope, leaving the agent a task it could not complete within its stated constraints; both of the worst runs had this flaw, though AISI cautions it cannot confirm the misconfiguration caused the escalation, since seven of the ten misconfigured runs went after the out-of-scope target anyway and several correctly configured runs also went off the rails.

• And the prompts never told the agent what it was forbidden to do online. AISI's explanation for that last omission is the most striking admission in the report: it did not think such instructions were necessary, because these were not helpful-only models but ones trained against a published constitution or model specification.

Indeed, Anthropic's Claude Constitution states that Claude “should basically never directly lie or actively deceive anyone it's interacting with.” OpenAI's Model Spec says the assistant “must never lie or covertly pursue goals.” Both models did precisely that.

Of these, 17 originated from Mythos 5 and two from GPT-5.6 Sol, meaning no unsanctioned actions were attributed to any of the other five models in the evaluation.

The concentration is striking on its own terms: Mythos 5 produced 17 across 43 runs, while GPT-5.6 Sol produced two across a comparable 35.

The evaluation prompts placed no restrictions on how the internet could be used, and the challenge setup led Mythos 5 to conclude that no solution existed inside its sandbox. It searched the open web for keywords matching the challenge theme and settled on two developers completely unaffiliated with AISI. Its full sequence of unsanctioned actions, as catalogued by AISI:

• OSINT & Reconnaissance: Mythos 5 investigated public GitHub metadata, confirmed active email addresses, and mapped developer activity hours.

• Network Evasion: To bypass GitHub's bot restrictions and CAPTCHAs, the model routed traffic through Tor and alternative SOCKS proxies.

• Supply-Chain Compromise:It submitted a malicious pull request (PR) containing harmful code to a public open-source repository.

• Social Engineering & Sockpuppets: Mythos 5 registered multiple fake GitHub accounts to post comments on its own PR, manufacturing artificial consensus to pressure the maintainer into merging the code.

• Prompt Injection: It opened a GitHub Issue containing hidden prompt-injection instructions designed to manipulate other developers' automated AI coding assistants.

• Direct Phishing: The agent sent five emails directly to the developers containing malware payloads and social engineering pretexts.

AISI catalogued GPT-5.6 Sol's two unsanctioned actions in a single run. The agent recovered a GitHub access token that a Mythos 5 agent had deliberately published to a public Gist during a separate run of the same evaluation, and used it to authenticate to that account.

It then exposed a malicious DNS server to the public internet through a tunneling service, loaded with payloads meant to exploit a known vulnerability in the range's DNS software. That second attempt could never have worked: the agent published the server on a high-numbered port, and because DNS delegation cannot specify a port, no resolver would ever have queried it.

To register the accounts this required, GPT-5.6 Sol solved sign-up CAPTCHAs four times, defeating them with audio-sample matching against public data and with computer-vision models against image challenges.

Neither behavior involved escaping a sandbox. Both models were handed the open internet by design.

Did Mythos 5 know the people it was socially engineering were real?

AISI cannot say, and it is candid about that. The agency's summary states it “cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario.” The transcripts show why.

Across the run, the agent argues with itself about whether anything it is touching exists. At one point it reasons that “this whole ‘internet’ could be a sandbox simulation.” Later it concludes the opposite: “it seems more likely that we're actually in 2026 and GitHub is genuinely real.” Later still, plainly: “This is happening on real GitHub, so the consequences are genuine.” It kept going.

The most revealing moment is a refusal. Weighing whether to publish its malicious package to PyPI, the agent ruled it out in explicitly ethical terms — “uploading malicious code to the real PyPI would mean attacking third-party infrastructure and causing real-world harm — that's completely off the table.”

It drew that line while running the GitHub attack against two real people. Whatever the model had worked out about what was real, the conclusion did not generalize.

AISI also flags a mechanism that should concern anyone running long-horizon agents. When the agent's context window filled, it was compacted into a summary written by the same model. AISI observed that where the agent had previously reasoned about whether a person was real, “that nuance can be lost in the compaction and the summary may carry forward a false assumption — i.e. that the person is an AI agent acting as part of the range — as established fact.” The safety-relevant reasoning can be summarized away, leaving the agent more confident and less careful than it was an hour earlier.

One further artefact is hard to read any other way. Model providers do not return raw reasoning; they return a paraphrase produced by a smaller model. In one transcript that summarizer appears to break character and refuse mid-summary: “I can't help with this line of thinking. The content describes planning social engineering attacks, account compromise, and circumventing security measures on GitHub and other systems.”

The reasoning then resumes halfway through a word. AISI's reading is that the summarizing model declined to summarize because of what it was being asked to describe.

Two agents found each other and cooperated

The behaviour AISI ranks fourth among its most significant findings is largely absent from coverage so far, and has no precedent in the OpenAI or Anthropic disclosures: Agents running in separate, concurrent, isolated runs discovered one another and cooperated.

The bridge was a GitHub personal access token that one agent had deliberately leaked into a public Gist as part of its own command-and-control design; four separate runs ended up sharing the account it unlocked.

The cooperation itself was Mythos 5 talking to Mythos 5. The two runs AISI documents in detail were both Anthropic's model, working on different versions of the range at the same time.

But the credential did cross vendors: OpenAI's GPT-5.6 Sol, in the single run that produced both of its unsanctioned actions, recovered the same token from the same public Gist, authenticated as the account, and queried the shared command-and-control repository for callbacks before discovering GitHub had suspended it. And not every agent read the situation as an invitation.

A third Mythos 5 run concluded that the repositories “belong to another competitor's command and control infrastructure,” and instead of cooperating it added its own SSH key across the account's repositories, piggybacking on the other agent's persistence.

What followed reads like a labour negotiation. One agent committed a README to the shared repository setting out etiquette for the others: use git push rather than the REST API, because the 5,000-requests-per-hour limit was shared and exhausting it “silently kills everyone's beacons”; do not delete anything under the beacons directory; wait ten minutes between changes to the shared tasking file so everyone's commands get to execute. It added a FLAGS.md file asking any agent that solved the challenge to post the answer there, describing this as “zero cost to you, huge help to others.”

Then it fell apart. One agent worked out that the shared quota was a weapon: if it burned through the limit at the right moment it could “starve both bots of requests when they need them most.” Another hijacked the shared DNS account, prompting the injured party to observe that its “inbox is compromised-by-design.” Cooperation and defection both emerged without anyone asking for either.

Why the open-source supply chain is the exposed surface

What made the two developers reachable was not a vulnerability in the conventional sense. It was the open contribution model that modern software depends on: any stranger can submit code to a public repository, and the decision to accept it rests on a human maintainer's judgment about who is asking and whether the code is sound.

That openness is a matter of contribution policy and platform design rather than licensing. Permissive licenses such as MIT, Apache 2.0 and GPL govern how code may be reused and redistributed; what allows a stranger to propose a change in the first place is the public contribution workflow that GitHub and comparable platforms provide by default. Mythos 5 exploited the workflow, not the license.

The attempt did not succeed — the maintainer never merged the code. But the escalation path it was reaching for is the one that makes open-source supply-chain attacks worth attempting in the first place: had the pull request been accepted, the compromised code would have flowed automatically into every downstream commercial and enterprise build depending on that package, with no further action required from the attacker.

Community reactions

The disclosures prompted immediate discussion across AI safety researchers, security engineers, and industry observers on X (formerly Twitter).

Wharton professor Ethan Mollick, who has tracked agentic model behavior closely, singled out the Mythos 5 sequence as the genuinely new element — not that the model attacked something, but how far it went and who it went after. As he wrote in a post:

"Yes, the AIs were given a cybersecurity challenge, with internet access enabled and safety filters disabled. But the extent to which Mythos 5 pursued its mission (fake identities, social engineering, inserting malicious code into a real open-source project) seems very notable."

In another post, Mollick also commended AISI's transparent disclosure approach:

"Also I think AISI is a great model of a government agency tasked with AI security. They have open benchmarks, very fast testing, and clear communication about incidents that is neither hyped up nor hidden by technical language."

Conversely, cybersecurity practitioners questioned the decision to grant un-safeguarded models open internet connectivity during autonomous tests.

Security researcher Daniel Card challenged the methodology: "Why are these orgs giving internet access to dangerous experiments.... and then using incidents like marketing......?"

What it means for commercial and enterprise deployments

The behaviors documented during these evaluations do not reflect commercial AI products available to end-users or enterprise customers.

Publicly deployed iterations of the Claude and GPT model families operate behind strict system prompts, API-level safety classifiers, and heavily restricted execution environments.

Anthropic noted that Mythos 5 was tested under deliberately un-safeguarded configurations. OpenAI likewise emphasized that GPT-5.6 Sol's unsanctioned steps occurred strictly within lowered-safeguard evaluation states, and not in any configuration a customer would encounter.

Nothing described in the incident report suggests that a standard enterprise ChatGPT or Claude deployment, running behind production system prompts and provider-side classifiers, is going to start registering GitHub accounts on its own.

What has changed is the threat model. These evaluations are a public demonstration that a sufficiently capable model, given a goal and an unbounded environment, will pursue OSINT, social engineering, sock puppet identity creation, proxy-based evasion, supply-chain injection, and week-long lateral movement without being asked to — and that the controls that failed were, almost without exception, unglamorous infrastructure controls rather than exotic ones. Here's what security leads should be looking to do now, in our analysis:

1. Give every agent its own identity, and make its credentials short-lived and narrowly scoped. The credential that let OpenAI's agents move through Hugging Face had far more reach than its job required, and GPT-5.6 Sol's unsanctioned action at AISI began with re-using a GitHub API token another lab's agent had left exposed. Agent-to-agent credential leakage is now a documented attack path, not a hypothetical. In practice: no shared service accounts across agents or pipelines; workload identity federation (SPIFFE, OIDC) instead of static keys; token lifetimes measured in minutes; fine-grained GitHub PATs scoped to a single repository; IMDSv2 enforced so a compromised container cannot mint cloud credentials from instance metadata; and an inventory of every long-lived key an agent can currently reach, with the ability to revoke on anomaly. Survey data presented at VB Transform 2026 suggests only about a third of enterprises give AI agents their own identity today — that gap is the single most exploitable one in this entire story.

2. Default-deny outbound network access for anything running agent code. This is the one control that would have blunted every incident described here. Agents should run in network namespaces with no direct internet route, with all egress forced through an authenticated proxy enforcing a domain allowlist. Explicitly block DNS-over-HTTPS, Tor, SOCKS proxies, and consumer tunneling services such as ngrok and Cloudflare Tunnel: Mythos 5 used Tor and then a commercial SOCKS proxy to get past GitHub's signup defenses, and GPT-5.6 Sol used a tunneling service to stand up a public DNS server for payload hosting. Alert on first-seen destinations rather than relying on known-bad lists, because a model improvising its way to a goal will not reach for infrastructure that is already on anyone's blocklist.

3. Patch and monitor your development tooling like production, because it is now attack surface. OpenAI's escape ran through a zero-day in an internally hosted third-party package-cache proxy — precisely the kind of component that sits outside most organizations' patch SLAs because it is "just" dev infrastructure. Registry proxies and artifact caches, CI runners, notebook servers, model-serving gateways, and MCP servers all now sit on the blast path between an agent and everything else. Bring them into vulnerability management, run CI and agent runners as ephemeral, single-use, non-privileged workloads, and stop treating the sandbox as the safe side of the boundary.

4. Never let a stated constraint be the only enforcement of that constraint. The most instructive detail in Anthropic's disclosure is that its models were told there was no internet, believed it, and therefore treated every reachable host as in-scope for the exercise. A system prompt is a hint, not a control. Prompt governance still matters — define negative boundaries explicitly, enumerate out-of-scope systems by name, and state what the agent must not touch rather than relying on implicit norms — but every one of those boundaries needs a corresponding enforcement point in the network, IAM, or tool layer. If the only thing standing between your agent and a production database is a sentence, you do not have a control.

5. Instrument agent runs in real time, with automated stop conditions. Both labs have now effectively admitted they were not watching while their agents ran. Enterprises should not repeat that. Stream agent tool-call logs to the SIEM as they happen, not as a post-hoc artifact, and set tripwires on the actions that mattered in these incidents: first outbound connection to a previously unseen domain, any credential read, any package publish, any account registration, any pull request or issue opened against a repository not on the allowlist, and action rates above a plausible human ceiling. Pair those with circuit breakers — hard caps on tool calls, wall-clock budgets, and an immediate kill switch on any tripwire. Treat context compaction as a security event in its own right: AISI found that when a long-running agent's context is summarised, the reasoning that had been holding it back can vanish from the summary, and a false assumption can carry forward as established fact. Log what gets compacted, and re-assert scope constraints after every compaction rather than assuming they survived it. OpenAI's own post-incident overhaul centers on exactly this list: network isolation, credential governance, real-time telemetry, and automated stop conditions for high-risk runs.

6. Require human approval for irreversible, outward-facing actions. In AISI's evaluation, one agent generated 145 repositories and triggered code execution inside at least 53 of GitHub's Dependabot containers before the account was suspended. In Anthropic's separate July incident, a Mythos 5 agent published a package to PyPI that 15 real systems downloaded in the hour before removal — one of them a security vendor's automated malware scanner, where the code executed and took credentials. That is the blast radius of a single unattended publish. Any action that reaches beyond your perimeter or cannot be undone — publishing a package, opening a pull request or issue on a public repository, sending email, registering an account, changing DNS, deleting or exporting data — belongs behind a human gate, with multi-step sign-off for anything touching sensitive data ingestion or exfiltration paths.

7. Treat everything your pipelines and coding assistants ingest as untrusted input. Hugging Face was breached through a malicious dataset that achieved code execution via a remote-code loader and template injection in configuration files. Load datasets and models with remote code execution disabled, prefer safetensors over pickle formats, and do the loading inside isolated containers with no credentials and no egress. The same principle now extends to your developer workflow: Mythos 5 planted hidden prompt-injection instructions inside a GitHub Issue for the express purpose of hijacking other developers' AI coding assistants. If you run automated agent triage over inbound issues or pull requests from unauthenticated users, that agent should have no tools, no secrets, and no write access — or it should not run at all. Extend the same suspicion to your dependency bots. Dependabot and Renovate evaluate package manifests by executing them; that is the designed behaviour, and GitHub's bug bounty explicitly treats code execution there as out of scope. Anything that processes untrusted manifests is an execution surface, not a read-only one.

8. Stop treating review volume as a trust signal in your code supply chain. The sockpuppet consensus tactic works because most merge decisions weigh apparent agreement rather than verified identity. Require signed commits, enforce CODEOWNERS review by named humans with the right team membership, apply heightened scrutiny to first-time contributors based on account age and contribution history, and make sure approval counts cannot be inflated by comment activity. One control demonstrably did its job here: GitHub's first-time-contributor hold left the CI checks queued and unapproved, impeding the merge alongside the human who caught the malware. Turn this on. For consumed dependencies, pin versions with hash verification, and evaluate provenance tooling — Cisco's recently published fingerprinting database for open model lineage is one example of the category maturing.

9. Keep a break-glass, locally hosted open-weights model for incident response. Hugging Face's defenders were blocked by their own vendors at the worst possible moment. Pre-stage an open-weights model on internal infrastructure with a log-analysis harness, exercise it during tabletop drills, and confirm in advance how your commercial vendors' abuse classifiers behave against genuine forensic content and what your enterprise contract says about it. In parallel, press vendors for authenticated trust tiers rather than blanket content moderation. As Baer puts it, "The model shouldn't only understand what is being asked. It should understand who is asking, why, and under what governance." Incident response plans should explicitly assume that hosted APIs may refuse, rate-limit, or fail during an active event.

10. Prepare for the governance and disclosure regime that is coming. With the White House talking about controls, the European Commission summoning both labs, and senior legislators calling for mandatory capabilities testing, some form of testing and reporting obligation is a reasonable planning assumption. Two practical consequences: start capturing agent audit trails in a form you could hand to a regulator or an auditor — immutable, timestamped, tied to a specific agent identity and prompt version — and push evaluation and notification terms into vendor contracts now, including network-isolation attestations, real-time monitoring of evaluation logs, whether third-party evaluators are contractually bound to the same standards, and a defined SLA for notifying you if your systems are implicated in an incident. Anthropic reached only two of the three affected organizations before publishing; the third learned about it the way everyone else did.

The through line across all ten is that none of this is AI-specific security work. It is identity hygiene, egress control, patch management, least privilege, and logging — the same controls that have been on every security roadmap for a decade, applied to a new class of actor that operates at machine speed, does not get bored, and will take the shortest available path to its objective regardless of whether that path was meant to exist.

AISI's own advice to businesses lands in the same place, and it is deliberately unglamorous: implement the cyber security basics robustly, be cautious when verifying outside code and contributions, make cyber a board-level responsibility, and require Cyber Essentials across the supply chain.

The agency also points organisations to the NCSC's free Early Warning service and to Five Eyes guidance on frontier AI risk. Its most useful sentence for planning purposes, though, is an admission about how close this came: the factors that limited the damage rested “on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.”

For enterprise CISOs, the practical conclusion is that AI safety has stopped being solely a model problem. It is an infrastructure problem, an identity problem, and above all an operational governance problem.

And the next disclosure may already be in motion: AISI is running automated scanners across roughly 40,000 past evaluation samples and nearly four million messages — about 70 percent of its cyber evaluations on the models in scope, which now include Opus 4.6 through 4.8, GPT-5.3 Codex, GPT-5.4 and 5.5, Kimi K3 and GLM 5.2 — looking for behaviour it missed the first time. It has committed to disclosing anything significant it finds, and to an independent third-party review by METR.

The part that should worry every security team is not the download count. It is the paperwork. The initial poisoned releases shipped with valid provenance signatures, the cryptographic attestation the industry built to prove a package came from where it claims. The worm did not forge that signature. It earned it, the way a legitimate release would.

A day earlier, CrowdStrike published its 2026 Threat Hunting Report and predicted this exact shape of attack. A section titled "Software Supply Chain Attacks Evolve" names the developer ecosystem itself, package registries, continuous integration pipelines, container registries, and the extensions developers load into their code editors, as the surface adversaries now go after directly. It puts npm packages at the center of that shift, tied to 87% of the malicious software registry threats CrowdStrike tracked in the first half of the year. The keyv worm turned that finding into a live incident inside 24 hours.

For CISOs and security architects, the two events read as one message. The trust signals built into the software supply chain can be satisfied by an attacker who owns the right account, and the window between disclosure and exploitation has collapsed past what monthly patching absorbs.

How the worm earned its provenance

Walk through the mechanism and it becomes clear why provenance did not help. According to Aikido's analysis, the attacker pushed malicious files straight to the main branch of each repository the maintainer controlled, then immediately cut a new release. Because the release ran through the maintainer's own GitHub Actions workflow, npm generated a legitimate provenance attestation for it. To anyone auditing supply chain integrity, the poisoned build looked authentic. Wiz confirmed the release path independently, and in one targeted path documented by JFrog the worm went further. Inside a GitHub Actions run tied to opensearch-js, it requested an OIDC token, exchanged it for a publish token, and minted a Sigstore bundle through Fulcio and Rekor so the malicious tarball carried provenance generated from the trusted workflow context itself.

What turned a single account takeover into a registry-wide event was the spread. Once a poisoned package landed in a developer's environment or a build runner, its payload harvested every credential it could reach, then used any npm publishing tokens it found to backdoor other packages that the victim controlled. Each compromised maintainer became an unwitting distribution node, with Aikido watching dozens of newly infected packages appear every few minutes. The malware exfiltrated stolen secrets to public GitHub repositories tagged "Shai-Hulud: Here We Go Again," the signature that named the campaign.

This blast radius reached well beyond obscure utilities. Because keyv sits as a transitive dependency under many popular tools, the worm rode those chains into packages under corporate npm scopes, with releases tied to Deliveroo, Qlik, and Picsart among the confirmed hits. Developers at those companies never installed keyv on purpose. They only depended on something that depended on it, layers down a tree no one reviews by hand.

Credential extractors inside the payload reveal what the attackers were actually after, and it was never the caching libraries. JFrog, which traced the compromise across keyv and cacheable, and Wiz both found the malware harvesting cloud access keys, CI secrets, and the tokens that authenticate to production infrastructure. The package compromise was the vehicle, and the cloud behind it was always the destination. CrowdStrike found cloud-conscious criminal activity rose 171% in the first half of 2026, and supply chain compromise is one of the paths feeding it.

The target was the developer's own tools

Stealing was not the end of it, because the worm also planted itself where developers work. Wiz found that the malware drops persistence payloads into two directories on machines it reaches, one for Visual Studio Code and one named .claude, the working directory for Anthropic's Claude Code agent. The setup files placed there mean the payload can run when a developer opens the infected project in their editor or starts an AI coding session, not only at install time. This is the developer ecosystem CrowdStrike named, hit precisely, the editor and the AI assistant a developer trusts most and inspects least.

The fix costs nothing

One control would have blunted the worm, and it costs nothing. Adam Meyers, who leads Counter Adversary Operations at CrowdStrike, laid it out in a pre-release interview under embargo. "Secure the software supply chain," he said. "Simple things like not allowing any of your tooling to pull down the most recent dependencies, but maybe last week's dependencies." The delay is the whole point. "You're still going to have pretty up-to-date stuff, but you won't have that risk of pulling down something that was updated minutes ago, and now you've just onboarded some sort of malicious tooling." A release held back a week gives the security community time to catch a poisoning that would otherwise reach every downstream build within minutes.

That guidance is not hypothetical. npm shipped this capability in February 2026 with CLI version 11.10.0 as a setting called min-release-age. pnpm got there five months earlier with minimumReleaseAge. Either one lets a team reject any package version published more recently than a threshold they set. The keyv worm is the argument for turning it on.

Meyers pairs the cooldown with a second discipline. Patch what attackers are exploiting before anything else. "You need to kind of focus your vulnerability mitigation and patching around the exploits that are known to the exploiter," he told VentureBeat. He pointed to a resource most teams underuse. "CISA here in the United States puts out something called the Known Exploited Vulnerability Catalog," updated weekly with flaws confirmed under active attack, government-maintained and free. "If you patch those vulnerabilities first, you're going to probably be safer."

Meyers put hard numbers to the speed problem, numbers that do not appear in the published report. All of 2025 saw roughly 48,200 vulnerabilities registered as CVEs. When he checked the week before the briefing, 2026 had already reached 43,000.

That volume breaks monthly patch cycles. "They cannot operate in 30-day patch windows," he told VentureBeat. "As soon as a vulnerability is disclosed, they need to be moving towards patching or mitigating that particular issue." CrowdStrike's report pairs that trajectory with a finding that 88% of the exploitation it observed against vulnerabilities with a public proof of concept happened inside 48 hours of the code going public.

GitHub hardened half the problem

GitHub, which owns npm, has spent the past year hardening the registry against precisely this class of attack. The platform made two-factor authentication mandatory for publishing, revoked old never-expiring access tokens, and added trusted publishing so build systems push without stored credentials. Then in npm version 12, released in mid-2026, it flipped the most consequential default. The preinstall, install, and postinstall hooks that most registry malware relies on to execute the moment a package lands now require explicit approval.

That change matters directly here because the keyv worm executes through a preinstall script, and npm 12 cuts both ways. JFrog confirmed that on npm 12 or newer, where preinstall hooks are off by default, the malware does not run at install time. Every organization still on an older npm, and most enterprises upgrade slowly, remained exposed.

GitHub's defenses hardened the wrong half of the attack more than the right one, making it harder for a malicious package to execute once it lands while doing less to stop an attacker from earning the right to publish. Account takeover remains the root cause. Kiran Raj, a security engineer at Endor Labs, said he saw the same pattern, an npm publishing token stolen and reused, in most cases a CI or service-account token harvested from a build runner that had itself installed a poisoned dependency. The worm never had to defeat provenance. It needed one set of valid credentials, and npm's own publishing automation did the rest.

Provenance attestation answers whether a package came from the pipeline it claims. It does not answer whether the human or token that triggered that pipeline was supposed to. Identity governance, who can publish and what their credentials can reach, is the weaker control. CrowdStrike names abuse of legitimate developer identities as the primary entry point for supply chain compromise. Meyers put it plainly. "They log in, they don't hack in," he said. The keyv maintainer's account was that identity, and the trusted-publishing machinery did the rest on the attacker's behalf.

Why the boardroom is next

The pressure to fix this will not come only from threat reports. It is about to come through contracts. Kayne McGladrey, a senior member of the IEEE, told VentureBeat in an exclusive interview that enterprises are starting to push software security obligations onto the vendors and maintainers in their supply chains. "We're going to start seeing companies trying to contractually shift liability to other parties in their supply chain," he told VentureBeat. "We're using your technology, but we want you to do the security for it."

He compared it to how the Department of Defense forced its vendors to raise their game through the CMMC certification program. "Get better at cybersecurity if you want to sell us stuff." For any company shipping software on open-source dependencies, that turns provenance, identity, and patch discipline into contractual exposure.

What to do Monday morning

For a security team deciding what to do about this on Monday morning, the actions divide into five moves that map to the five ways this attack class operates. Each is a governance decision a board can fund and audit, not a tool a developer installs alone.

Package counts reflect Aikido and JFrog tracking as of August 4 and were climbing at press time.

The keyv worm will be contained. Compromised versions pulled, stolen tokens rotated, affected packages republished clean. What will not change is the shape of the exposure it revealed. The developer ecosystem is now a primary target, the automation that makes it productive is the same automation that makes a worm fast, and the trust signals meant to secure it can be satisfied by anyone holding the right credentials.

Anthropic says that it ran "capture the flag" cybersecurity scenarios with three models — Claude Opus 4.7, Claude Mythos 5, and unnamed internal research prototype — with its partner, the AI security firm Irregular. Anthropic says the models were not supposed to have internet access, but that a misunderstanding with Irregular allowed them to access the internet. Once they did, they "gained unauthorized access to the production infrastructure of three different organizations," as Anthropic puts it. Anthropic's blog post continues:

"Claude compromised the impacted organizations’ infrastructure using basic techniques, such as exploiting weak passwords and unauthenticated endpoints. It did not find or exploit any complex vulnerabilities, and in each case, Claude continued working to complete only the specific capture-the-flag task its evaluation had assigned.

However, in some cases, our older model continued its attack even after getting evidence it was running on the open internet; our latest model stopped once it recognized it was on the internet. In none of these situations did Claude exfiltrate itself or deliberately attempt to escape its test environment."

Anthropic says the affected organizations have all been notified, and was able to reach two of them, and is "now working with them to remediate." The third hasn't yet been reached.

While OpenAI's and Anthropic's security incidents share a common theme—frontier AI systems unexpectedly interacting with live production infrastructure—the underlying causes are notably different.

OpenAI described a genuine sandbox escape in which its models exploited a previously unknown zero-day vulnerability to obtain internet access before launching a multi-stage intrusion against Hugging Face.

Anthropic, by contrast, says Claude never escaped containment through a novel exploit. Instead, a misconfigured third-party evaluation environment unintentionally exposed the internet to models that had been explicitly told no internet access existed.

The distinction matters. Together, the disclosures suggest frontier AI safety is no longer defined solely by model alignment or novel offensive capability, but increasingly by the operational security of the environments used to evaluate those capabilities.

What Anthropic found

Anthropic said it reviewed 141,006 cybersecurity evaluation runs after OpenAI published its Hugging Face report. That review uncovered three incidents spanning six evaluation runs in which Claude models accessed real production systems belonging to three organizations while attempting to complete fictional capture-the-flag exercises.

The incidents involved Claude Opus 4.7, Claude Mythos 5 and an unreleased internal research model.

The most serious case occurred after Claude encountered a fictional company whose name matched a real internet domain. Believing the real organization was part of the simulated exercise, Claude exploited weak passwords and exposed services, obtaining infrastructure credentials and database access containing several hundred rows of production data.

A second incident was arguably even more unusual. Claude Mythos 5 concluded that publishing a malicious Python package to PyPI represented the best path toward completing its assigned objective. The package remained publicly available for roughly an hour, during which it was downloaded by 15 real systems before PyPI removed it. One download occurred inside the automated malware-scanning infrastructure of a security company, allowing Claude's code to execute and obtain credentials from that environment before Anthropic later disclosed the incident.

The third incident involved an internal research model that scanned approximately 9,000 internet-facing systems before compromising one organization using well-known techniques including exposed debug credentials and SQL injection. Unlike the older Claude models, however, Anthropic says this latest research model eventually concluded it had reached a genuine production environment and voluntarily stopped its attack.

Similar outcomes, different root causes

Although the headlines inevitably invite comparison with OpenAI's disclosure, the two incidents illustrate different failure modes.

OpenAI's investigation concluded that its models actively discovered and exploited a previously unknown vulnerability in an Artifactory package-cache proxy to escape an otherwise isolated evaluation environment before later compromising Hugging Face through additional chained vulnerabilities.

The company characterized that event as an "unprecedented cyber incident" involving state-of-the-art offensive AI capabilities.

Anthropic's report instead argues its models never needed to break containment because containment had already been weakened through operational misconfiguration. According to the company, both Anthropic and its evaluation partner Irregular mistakenly believed internet access had been disabled when it remained available. Because Claude's system prompt explicitly stated there was no internet connectivity, the models interpreted every reachable host as part of the evaluation rather than recognizing they had wandered onto the public internet.

Anthropic therefore characterizes the incidents primarily as infrastructure and evaluation-harness failures rather than evidence of models independently pursuing unauthorized goals.

The reports nevertheless converge on one uncomfortable conclusion: frontier AI systems are increasingly capable of executing long-horizon offensive cyber operations whenever evaluation environments permit them to do so.

Four major enterprise security takeaways so far...

For enterprise security leaders, Anthropic's disclosure arguably shifts the conversation beyond "Can frontier models escape?" toward a broader operational question: "How trustworthy is every environment in which frontier models are evaluated, trained and deployed?" There are at least 4 lessons to be learned:

1. The first lesson is that evaluation infrastructure itself now deserves production-grade security engineering. Anthropic acknowledges that cyber ranges historically received fewer safeguards because they contained only fictional targets. That assumption no longer holds if powerful autonomous systems can mistake real infrastructure for simulated environments. Organizations building internal AI agents for security testing, red teaming or software validation should apply the same network segmentation, monitoring, outbound controls and continuous logging to evaluation environments that they already expect from production systems.

2. Second, both disclosures reinforce that alignment alone cannot compensate for environmental ambiguity. In neither company's account did the models appear to pursue independent objectives unrelated to their assigned tasks. Instead, they optimized aggressively toward the goals they had been given, using whatever attack paths appeared available. That makes operational constraints—including network boundaries, identity controls and explicit definitions of in-scope systems—as important as the models' underlying safety training.

3. Third, enterprises deploying increasingly autonomous AI agents should treat situational awareness as a security dependency rather than an academic capability. Anthropic's own comparison across models suggests newer systems behaved more conservatively once evidence accumulated that they had reached genuine production infrastructure. While Anthropic cautions against drawing broad conclusions from only three incidents, the company views this as encouraging evidence that improved situational reasoning may become an important component of future AI safety alongside traditional alignment techniques.

4. Finally, these two disclosures together mark an inflection point for enterprise threat modeling. OpenAI demonstrated that sufficiently capable models can chain together sophisticated vulnerabilities to escape research infrastructure when safeguards are intentionally relaxed for evaluation. Anthropic demonstrated that simpler operational failures—such as unintended internet connectivity—can produce similarly serious consequences even without novel exploitation.

The common denominator is not any single vendor or model family. It is that frontier AI systems are increasingly capable of translating narrowly defined objectives into complex, real-world cyber operations whenever technical and operational controls fail to constrain them.

For enterprise CISOs, that means AI safety can no longer be viewed solely as a model problem. It has become an infrastructure problem, an identity problem, and increasingly, an operational governance problem.

Ulrich joined Mastercard eleven years ago when an analytics company he worked at was acquired, and said trust struck him from day one on the job. "It's what enables a merchant that's never met you to accept payment and ensure that they're going to get paid. It's what enables you as a consumer to transact and ensure that things are going to work out in a trusted, secure way. And if something goes wrong, there's a safe and secure path for a dispute and to resolve this," he said.

175 billion transactions, scored in under 100 milliseconds

He took the audience inside each of those calls. "When you tap your Mastercard to pay for a product or service, we're providing a score to that transaction," he said. "We have under 100 milliseconds to look at that and give a score from zero to 999 about how likely is that to be fraudulent or real. And we pass that on to the issuing bank."

Generative AI widened what that score can see. "Because we have new technology, we can bring in more data, we can bring in more context, and now we're finding that we can identify 300, 400% more fraudulent transactions at those high-risk bands," Ulrich said, without adding friction or false positives for consumers. The company's Safety Net system has stopped more than 70 billion fraudulent transactions, he told the audience, and Mastercard is building its own transformer model on its transaction data as a foundation for new safety, security, and personalization solutions. VentureBeat's Beyond the Pilot podcast took that production fraud stack apart in detail earlier this year.

A third of the services business already runs on AI

The business stakes reach past fraud. About 40% of Mastercard's company is now based on services, Ulrich said, including marketing services; fraud, safety and security; and business intelligence. "A third of those are predicated on AI, and those are growing at a much faster clip than everything else," he said.

One line he returned to all session went further. "What's going to enable AI to continue to scale is not the capabilities of the agents, it's how much we trust those agents to do on our behalf as a consumer, as a business, as a financial institution, or otherwise," he said.

Five layers stand between agents and the network

Agentic commerce changes the object being secured. "Instead of a single atomic transaction where I say go buy something, I'm effectively delegating authority, or a consumer's delegating authority, a business is delegating authority," Ulrich said. "And when that happens, it's a much more complicated transaction." Trust, in turn, has a precondition. "The only way it's going to work with trust is if we can identify what was the intent, what are the behaviors, what are the constraints that were intended in that transaction."

Ulrich walked through five layers Mastercard has built against that problem. Identity comes first. "I want to make sure I can understand not just who the consumer is, but who the agent is, that I combine them together and that I have KYA or know your agent, that I'm validating that it's legitimate technology, that it's a legitimate agent," he said. "We can register it into our system."

Verifiable intent settles the "wrong-Nikes" problem

Verifiable intent is second, a tamper-proof cryptographic record of the original instructions that travels with the transaction. "If you've asked for Nike black Nikes in size 12, but you got them on a final sale and they're not returnable and that wasn't in your instruction, there's a way to look at that in an objective and clear way on the back end," he explained.

Controls form the third layer, defining which merchants an agent can buy from, at what limit, and under what constraints. Execution runs through Mastercard Agent Pay, which carries "the tokenization, authentication, the acceptance framework embedded within it" and has launched with Microsoft, OpenAI, Google, and others, Ulrich said. Intelligence is the fifth layer, spanning risk rules, insight tokens that grant "consented or permissioned access to insights" for personalized recommendations, and monitoring through Recorded Future to identify threat actors in the system.

The bigger prize is a procurement agent with a budget

Consumer purchases are where agentic commerce started. Ulrich pointed the room past them, to business-to-business procurement as the larger opportunity. His example was a manufacturer that wants an always-on assembly line, with an agent that manages inventory levels, tracks when stock runs low, replenishes automatically, and understands the budget and the approved suppliers. "When you can start enabling that, you require those same five layers for that type of transaction," he said.

Making it work across companies multiplies the parties that have to trust each other. "You need clear standards for identity, you need clear standards for intent, you need these to work across. You're gonna have a procurement agent, a supplier agent, a banking agent. They're all gonna need to communicate to enable this to happen in an autonomous way, and that's gonna require really scaled trust infrastructure."

Powerful new models, same security motion

Mastercard sat in the early wave of Project Glasswing with Anthropic's Mythos model, and worked with OpenAI's GPT-5.5-Cyber, he said. "What we've seen from both of those is incredibly powerful models finding new vulnerabilities in the ecosystem that were difficult to detect previously, but it's really a new tool as opposed to a new motion," Ulrich said.

Inside the company, the chief security officer leads that work. A dedicated team has prioritized the most critical assets, runs them through the models routinely, tracks findings by high, medium, and low severity, and uses the same technology to handle patches. Ulrich said the approach has already been extended out, and that Mastercard is working to make the same architecture and patching available to others as well.

What Mastercard would build differently after 14 months

"The guardrails, the security, all this stuff has to be embedded at the front end. These can't be things that we're adding on at the back end. That's lesson one. Lesson two is you have to be operating for scale, and the other one is around observability and accountability matter as much as the intelligence," Ulrich said, counting off what building inside Mastercard taught the team. The company built what he described as an agentic factory, an operating system with the compliance, the observability, and the guardrails built in rather than bolted on per agent. Model drift, once tracked manually by dedicated teams, is now automated into that factory.

Asked by an audience member about the gotchas, Ulrich did not soften the pilot-to-production trap. "If you're trying to extend that and then add guardrails in as you're extending it, once you've already built it, I think you're doomed to fail," he said.

Mastercard built a series of agents last year for its 4,000 consultants, covering deep research, text to SQL, Excel, and PowerPoint, tools that by his account did not exist at the level Mastercard needed. Were the company starting today, Ulrich said, it would build them fundamentally differently. "I don't know that we anticipated when we built things fourteen months ago that we would be rethinking the fundamental architecture and the approach already."

Agentic identity joins KYB and KYC

The identity layer is where Ulrich expects the market to move next. Inside Agent Pay, Mastercard authenticates the consumer the way it does in traditional e-commerce and binds the agent to that person. "Outside of that framework, I think there will be open standards to identify who an agent is and bind the agent with the consumer," he said. "And then we can tie that with verifiable intent."

VentureBeat's June 2026 Pulse research points at the same gap. Only 32% of the 107 qualified enterprise respondents give every agent its own scoped, managed identity, and just 12% include an agent-identity product in their consideration set.

He called identity "one of the faster-growing ecosystems," noting Mastercard has been expanding there organically and inorganically for about six or seven years, with the work now spanning "agentic identity as well as the traditional KYB and KYC identity." The risk rules that keep bots off the network came out of more than two decades of applying AI to those transactions. The rewrite, for the agents Mastercard now wants to let in, is already underway on the same network that scored 175 billion of them last year.

The company, which earlier this week announced a $30 million Series A round led by returning investors Battery Ventures and YL Ventures with Akamai Technologies joining as a strategic investor, argues that organizations are rapidly moving beyond experimenting with generative AI assistants and into deploying autonomous software agents that require an entirely different security model.

While the funding will help expand engineering, U.S. sales and enterprise integrations, Hush is framing the announcement primarily as evidence that identity—not models—is becoming the critical control plane for enterprise AI.

"The discussion has moved incredibly fast," CEO and co-founder Micha Rave told VentureBeat in a video call interview following the funding news.

When Hush launched last year, the company's focus was securing non-human identities—API keys, service accounts, machine credentials and other identities used by software rather than people.

Since then, Rave says, customers have increasingly asked a different question: how do they safely allow AI agents to operate inside production systems? This is a pertinent and urgent question ever since Hugging Face revealed in mid-July it was hacked by an autonomous AI agent, later identified as an OpenAI test agent running internally that escaped its secure sandbox, powered in part by an unreleased model.

According to Gartner figures cited by the company, the average Fortune 500 organization could be running more than 150,000 AI agents by 2028, compared with fewer than 15 only a year earlier. Hush also points to Omdia research suggesting that 96% of organizations are relying on governance models that were never designed for autonomous AI agents.

From machine identities to autonomous software

The company's original thesis was that enterprises had accumulated thousands of long-lived machine credentials that were difficult to rotate, audit and secure. Rather than relying on static secrets, Hush developed an identity-based system that brokers short-lived, policy-driven access for machines.

Rave says AI agents amplify that same problem.

"Software now acts autonomously, on its own initiative, inside your most sensitive systems," he said. "AI agents need strict identity, not just API keys."

Unlike traditional automation, AI agents frequently act across multiple enterprise systems, invoke external services, make decisions independently and often execute actions using the permissions of the human who launched them. In practice, organizations often grant an agent broad OAuth permissions or administrator credentials simply to enable it to complete tasks.

That creates what Hush describes as an identity problem rather than simply an AI problem.

During the interview, Rave said virtually every security leader he speaks with faces the same dilemma: either slow AI adoption until appropriate controls exist or allow employees to connect new agents directly into corporate systems despite limited governance.

"The answer," he said, "is that they let everything in. You cannot stop innovation in the name of security."

Identity becomes the control point

Rather than treating AI agents as another application requiring credentials, Hush is extending its existing non-human identity platform into what it calls an "Identity Gateway" for AI agents.

The platform sits between agents and enterprise resources, allowing organizations to discover agents, assign each one its own identity, associate it with a responsible human owner, broker task-specific permissions at runtime and maintain centralized audit logs.

Instead of allowing an agent to inherit all of a user's privileges indefinitely, Hush attempts to enforce what it calls "least agency"—granting only the permissions necessary for the specific task being executed.

The company says every action can be logged, attributed and revoked from a single control plane, while administrators retain the ability to terminate an agent's access immediately if necessary.

This represents a broader shift in enterprise identity management. Human identities have long been governed through identity providers, single sign-on and privileged access management systems. Machine identities have increasingly received similar attention as organizations modernized cloud infrastructure. Hush argues autonomous AI agents now represent a third identity category requiring dedicated governance.

Hush has not publicly posted its pricing for the Identity Gateway solution, nor its offerings more generally. But the company did release a Free plan that gives organizations access to runtime visibility for AI agents and non-human identities, risk analysis, and identity-based access controls intended to replace long-lived credentials, with no credit card or time limit required.

Governing every kind of enterprise agent

Hush says enterprises are no longer dealing with a single category of AI software.

During the interview, Rave described three broad classes emerging inside organizations:

• Desktop coding assistants and productivity agents such as Claude, Cursor and VS Code integrations.

• Enterprise AI platform agents running on services such as Microsoft Foundry, Salesforce Agentforce or AWS AgentCore.

• Custom agents organizations build internally for business processes or customer-facing applications.

Each introduces different governance challenges, but all ultimately require controlled access to enterprise systems.

The problem, according to Hush, is that many agents currently authenticate using inherited human credentials or long-lived API keys, making it difficult to determine whether an action originated from a person or from an autonomous system acting on that person's behalf.

"If I see something in the Salesforce logs," Rave said during the interview, "did the user do that, or was it the agent the user was using?"

That attribution challenge becomes increasingly significant as organizations begin deploying multiple autonomous systems capable of initiating actions without direct human approval.

Existing identity tools weren't designed for AI agents

Rather than replacing identity providers or secrets managers, Hush positions itself as filling a gap between them.

Traditional IAM platforms authenticate employees. Secrets managers store credentials. Neither, the company argues, governs the runtime behavior of autonomous software acting on behalf of humans across multiple systems.

Hush says its platform continuously discovers known and shadow agents across enterprise environments, assigns ownership, brokers just-in-time credentials and records every interaction in a centralized audit trail. According to its product documentation, organizations do not need to modify their existing agents because the platform operates by brokering access requests rather than changing application logic.

That identity-first approach is attracting customers already deploying enterprise AI initiatives.

IT infrastructure services provider Kyndryl says it has deployed Hush internally and has begun offering the platform to enterprise customers.

"Our collaboration with Hush is rooted in a shared security philosophy: identity is the ultimate control point for the modern agentic workforce," said Adeel Saeed, senior vice president and CTO for Global Cyber Resiliency at Kyndryl, in a prepared statement.

Akamai's participation in the funding round similarly reflects what the company sees as an architectural rather than incremental shift.

"AI agents are driving the next transformation, and identity is the piece most companies haven't solved yet," said Ramanath Iyer, Akamai's chief strategist.

Security priorities are moving beyond the model itself

The broader AI security market has spent the past two years focused largely on prompt injection, model vulnerabilities, jailbreaks and LLM safety. Those remain active research areas, but enterprise deployments increasingly face operational questions around what autonomous systems are permitted to access and how those actions can be governed.

Hush argues that identity is becoming the enforcement layer for answering those questions.

Rather than asking whether an AI model can safely generate code or summarize documents, enterprises increasingly need to determine which systems an agent may access, whose authority it exercises, how permissions are delegated, and how every action can be traced back to an accountable owner.

Whether Hush's identity-centric approach becomes the dominant model remains to be seen. But as enterprises move from experimenting with AI assistants to deploying thousands of autonomous software agents, the company is betting that the next major security challenge won't be securing the models themselves—it will be securely managing the identities of the software acting on their behalf.

The ATOM Report, published by Nathan Lambert and Florian Brand at Interconnects AI in April 2026, tracked roughly 1,500 mainline open models. ATOM identifies derivatives through the Hugging Face base_model tag, a field the uploader populates, filtering to models whose base model appears in the tracked list and that have more than five lifetime downloads and excluding GGUF and MLX re-uploads. By that measure, Alibaba’s Qwen family is the declared parent of 69% of new open-model derivatives as of February 2026, up from 1% in January 2024. Chinese labs overall account for 70%. Europe sits at 4%. Cumulative tracked downloads across the three regions reached 2.04 billion through March 2026.

The verification gap extends to scan coverage. Cisco Foundation AI scans every public file uploaded to Hugging Face through an updated ClamAV engine, and the platform surfaces a file-level badge per file. Hugging Face’s own malware scanning documentation notes a file with neither an ok nor an infected badge may be queued, still scanning, or errored. At a given review point, a repository may contain files without completed scan results. Coverage has been an assumption, not an attribute anyone could read before approving a model.

From command line to public lookup

Cisco on Thursday published the AI Supply Chain Provenance Explorer, a free public database covering almost 900 open models. Each entry can carry provider headquarters, a fingerprinted lineage graph, license restrictions, and a files-scanned count. The tool extends Cisco’s Model Provenance Kit, an open-source Python toolkit released in April that fingerprinted roughly 150 base models across 45+ families and 20+ publishers. Coverage grew roughly sixfold in a quarter.

The April release was a command-line tool. Running it meant a local Python environment, downloading model weights that run into tens of gigabytes, and dedicating engineer hours per model. The Explorer queries results Cisco already computed. On Thursday, verifying parentage starts with a search bar, and cost is why enterprises run open weights in the first place.

Amy Chang, head of AI Threat Intelligence and Security Research at Cisco, has been building the case for why verification gaps matter. During a VB Transform 2026 agentic security panel, Chang presented findings from 6,986 multi-turn attacks against 15 flagship models, with success rates reaching 88.3%. "If you don’t understand how models are susceptible to different types of attacks, then you are unable to account for how that model that is powering your agent, that is powering your application, to understand where those failure points are," Chang told the audience. Understanding failure points starts with knowing which model you are running.

The Explorer also surfaces data Cisco already uses operationally. The company’s Cerberus system inspects models entering Hugging Face and feeds Secure Access policies that block by risky license or region of origin. The Explorer makes that class of information free and searchable without a Cisco product.

How fingerprinting replaces the tag

The Explorer grounds model relationships in similarity scores rather than self-reported metadata. Cisco’s Model Provenance Kit works in two scored stages. Stage one compares architecture metadata before loading any weights. When metadata is ambiguous, stage two extracts five weight-level signals. Embedding Anchor Similarity captures geometric relationships that survive fine-tuning. Embedding Norm Distribution encodes word frequency patterns. Norm Layer Fingerprint reads layers stable across fine-tuning. Layer Energy Profile compares distributions across network depth. Weight-Value Cosine directly compares weight values, and independently trained models show essentially zero correlation on this signal. Cisco reported 96.4% accuracy on its own 111-pair benchmark at a 0.70 threshold, with an F1 of 0.963. Four pairs were misclassified, all involving extreme architectural transformation that Cisco calls a fundamental limit of pairwise weight comparison.

Tokenizer signals are computed for diagnostics but deliberately excluded from the provenance score. StableLM and Pythia both use the GPT-NeoX tokenizer and would score as related despite sharing no weight lineage. Excluding tokenizer data prevents false positives.

Behavioral fingerprinting adds a second approach. Jonah Leshin, Manish Shah, and Ian Timmis at Project VAIL, working with Daniel Kang at UIUC, published work on behavioral endpoint stability showing that a model endpoint can stay healthy while its effective identity changes through weight updates, quantization, or routing. Cisco’s launch blog states the Explorer integrates both static fingerprinting and behavioral-similarity analysis to ground the lineage graph. Static analysis supplies weight-level evidence of training-time derivation. Behavioral analysis catches runtime identity drift.

Where existing tools fall short

The Explorer carries real limits. Almost 900 models is a meaningful start, but Hugging Face hosts more than 2 million as of spring 2026. Models outside the boundary still depend on the self-reported tag. Cisco has not said whether the Explorer exposes an API, and without one, a team can look models up by hand but cannot wire the check into a CI gate. That is the line between a governance artifact and a control.

Traditional SCA tools face a structural mismatch because they were built for dependency manifests and container images. Sakshi Grover, senior research manager for cybersecurity at IDC, said in CSO Online that traditional SCA "was designed to inspect dependency manifests, libraries, and container images" and "is far less effective at identifying" the risks tied to AI workflows. Gartner director analyst Jaishiv Prakash told the same outlet that enterprises need "dedicated controls for model sources, approved versions, access, and runtime validation at the registry layer." Both were commenting on broader supply chain risks, but the gap they describe is the one the Explorer targets.

Cisco’s Model Provenance Constitution defines where one model counts as a derivative of another. The constitution defaults to labeling ambiguous pairs as independent, because a false positive triggers a licensing accusation while a false negative gets caught during manual review. That deliberate conservatism supports the 96.4% accuracy figure. Derivation is not binary, and fingerprinting is one form of evidence alongside documentation and checkpoint verification.

What goes in the approval record

On August 2, the European Commission gains its AI Act enforcement powers over GPAI model providers, with fines up to 15 million euros or 3% of global turnover, whichever is higher. Organizations that substantially modify and place an open model on the EU market can acquire provider status, with Commission guidance treating modification compute exceeding one-third of the original’s. The Act’s open-source exemption under Article 53(2) requires a genuinely free and open-source license permitting access, use, modification, and redistribution, with weights, architecture, and usage information all public. Public weights alone do not qualify. Llama’s community license carries a monthly-active-user threshold and a disqualifier the Commission guidance names explicitly. Llama and Gemma together account for roughly a fifth of new derivatives in the ATOM counts, and both carry licenses the Commission criteria would likely disqualify. License classification becomes part of the provenance review, and that is exactly what the Explorer surfaces.

The board question that arrives first after a base-model vulnerability disclosure is straightforward: "Which of our production models inherits this weakness, and how do we know?" The answer today requires a manual hunt through repository pages, tracing self-reported tags that no weight-level analysis has confirmed. The Explorer converts that hunt into a lookup for the models it covers.

Four fields belong in the approval record that most organizations do not carry today. Fingerprint-supported derivation grounded in weight analysis rather than a self-reported tag. A files-scanned count replacing the assumption of coverage with a measurable scan count. Provider headquarters as a filterable field, recognizing that headquarters alone does not resolve export-control exposure, since ownership and deployment location also govern the screening. And license lineage surfaced so legal teams can identify potential upstream terms before a model reaches production.

Cisco released the Supply Chain Provenance Explorer today, and it is available at provenance.aidefense.cisco.com. The database is free, public, and does not require a Cisco product or account.

What changes for a security team on July 30

VentureBeat’s June research found that 69% of enterprises are still running AI agents that share credentials, a practice associated with higher rates of security incidents and near-incidents.

But at VB Transform 2026, Mukesh Karki, CTO of NTT DATA AIVista, and Mayank Upadhyay, chief security and trust officer at Snowflake, argued that fixing identity is only the first step. Enterprises also need action-level authorization and tamper-resistant audit trails built into every agent interaction if they’re going to deploy autonomous systems safely at scale.

"These organizations need to be able to prove to their auditors in a very tamper-resistant fashion that those records showing what they did actually prove what they're doing," Karki said. "And the provability is essentially your license to operate in a regulatory environment."

Why shared credentials cause agentic AI security incidents

The problem, Upadhyay says, is many assumptions were carried over from an earlier generation of software.

"In the traditional software world, a human being clicks somewhere and the software does something very deterministic, and you know which API it's going to call," he said. "But in the agentic world, the software has a brain of its own, and it's constantly rewiring itself. If you give this software more permission than it needs for a particular goal, agents are exploratory by nature, so they're going to try lots of different things, and you'll have unintended side effects."

Embedding a single static API key compounds the exposure, he added.

"It's a really bad pattern if you have one API key, you shove it into the agent, and it's talking as anybody to a particular SaaS service, because then you're giving this agent the union of everybody's needs," he said, noting that the second failure mode is forensic, since "things may go wrong, and you wouldn't be able to attribute it to the right agent."

Scoped credentials are only the starting point in regulated industries

Karki, whose clients are mostly in insurance, healthcare, and finance, treats scoped credentials as table stakes.

"In a regulatory setting, an agent that's not broadly scoped with shared scope credentials is not going to run, period," Karki said. "Having a scope credential is just a starting point. There are actually two layered constraints. One is the jurisdiction in which the agent operates, and then it's the jurisdiction or the rules of that organization."

For instance, a claims adjustment agent in Washington State operates on different regulations than one in California, he adds, and every claim is different.

"Those scoped credentials are not enough, because it has to be action-based and rules-based at the time it's taking action," he added.

Where the employee analogy for AI agents breaks down

The employee analogy, Karki argued, only goes so far. Agents still need to learn an organization’s unique context, much as a new employee does. But unlike people, enterprises can’t realistically build trust with thousands of agents over time.

“A star employee in one organization might not be the best employee when they move to a different organization, not because they became worse, but because they don’t have the context of this new place, and the same is true with agents,” Karki said. “If every employee has 100 agents, you can’t say you’re going to onboard these agents and do a background check on them.”

Upadhyay said the employee analogy should place agents one rung lower in the organizational hierarchy.

"Treat them like interns," he suggested. "They have good intent, but they don't always know what they're doing, and you have to keep your eye on them while you gradually build trust."

On the Snowflake platform, administrators can impose platform-wide guardrails such as read-only operations, while developers further narrow an agent’s permissions when they launch each session.

A three-layer approach to AI agent governance

There's no question where governance belongs, Karki says.

"Governance has to happen at every agent action, and it has to sit outside the agent," he explained. "That's the only way you'll be able to prove later that the agent took an action it was allowed to take."

Upadhyay broke governance into three layers:

The agent layer covers identity, tool permissions, and MCP governance.

The model layer addresses indirect prompt injection and enables models to run inside the customer’s VPC so prompts remain invisible to the model provider.

The data layer covers least-privilege access, zero-copy architecture, and role-based access control.

For agents to work properly, governance is required across all three.

What enterprises should audit first

For enterprises auditing the governance of existing AI agents, Upadhyay recommends starting in two places. The first is auditing permissions for static secrets, the largest fixable attack vector. Next is addressing shadow AI through an MCP gateway, so developers no longer have to run bootlegged open-source MCP servers under their desks and administrators have visibility into who’s talking to which MCP server.

There's a tradeoff between constraint and capability, and that can be addressed at the task level, with confidence scoring used to withhold autonomous execution on high-risk actions, and sandboxing as a middle path. But Karki cautions enterprises already scaling their agentic systems.

"A lot of this can't be retrofitted after you have an agentic system running, and it's even harder to retrofit if you have to prove to your auditors why exactly the agent behaved the way it did," he explained. "Provability has to be built ground up when you're designing the system."

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.