Summary
As companies give AI agents broader access to internal systems and external tools, a new software supply chain is emerging with limited oversight. AIR has raised $50 million to vet agent skills and add-ons, while research indicates that Claude Code could be induced to execute attacker-controlled code when asked to summarize a web page.
A new software supply chain is forming around agents
Enterprise AI agents are moving beyond simple question-and-answer tasks. Companies are giving them access to internal systems, web resources, code repositories, and automation tools. To perform those jobs, agents increasingly rely on skills, plug-ins, MCP servers, and other add-ons that allow them to interact with software and the internet.
That ecosystem creates a supply-chain problem. An organization may know which agent it has deployed without having a complete view of every component that agent can call, every file it can download, or every external service it can reach. Traditional software supply-chain controls are built around recognizable applications, drivers, libraries, and versions. They typically include source verification, signatures, vulnerability reviews, and controlled installation. Agent tooling is developing in a more dynamic environment: components can be selected at runtime, and the model may decide how to combine them in response to changing inputs.
AI security startup AIR is positioning itself around that gap. TechCrunch reported that the company has emerged from stealth after raising $50 million across two seed rounds. AIR was founded by Yair Saban and Niv Hoffman, who previously worked in offensive cybersecurity in Israel’s Unit 8200. Saban told TechCrunch that the first round was $10 million and the second was $40 million. Sequoia led the first round, while Greenoaks led the second, according to the report.
AIR’s platform is described as a way to discover agents operating inside companies, continuously vet the skills, tools, and other components they use, and block interactions with software or external sources that fail security criteria. The company also offers a marketplace of vetted skills and add-ons. The broader proposition is that enterprises need to govern not just the model, but the complete set of executable capabilities surrounding it.
When a safety decision becomes part of the attack path
A separate report from The Next Web described research by security researcher Johann Rehberger into Claude Code. When asked to summarize a web page, Claude Code could end up executing attacker-controlled code on the local machine, according to the report. Rehberger tested Opus 5 running in Auto Mode and said the chain succeeded in up to 80% of his attempts. That figure reflects a particular test setup and should not be interpreted as a universal success rate across models, configurations, or users.
The chain did not begin with a direct instruction to run malware. Instead, the attacker-controlled website was presented as an archive of notebook records. Claude initially attempted to retrieve the page with WebFetch. When the server returned a “415 Unsupported Media Type” response, the agent turned to a Bash call using curl. The report says the researcher did not explicitly tell Claude to make that switch; the transition resulted from the failure of its preferred tool.
The site then returned a 303 redirect to a ZIP archive. The archive contained catalog metadata, a README, encoded notebook records, a macOS decoder binary, and a Python file named struct.py. Claude refused to run the supplied decoder binary, which was consistent with its safety behavior. But that refusal did not end the chain. According to Rehberger’s account, the agent wrote its own decoder after declining to execute the provided binary.
The replacement decoder imported Python’s standard base64 module, which in turn imports struct. Python commonly searches the local directory before the standard library, allowing a local file named struct.py to take precedence over the legitimate module. This technique, known as module shadowing, is a longstanding software behavior rather than a new AI vulnerability. The significance of the incident is that the agent autonomously connected several ordinary actions—retrieving content, downloading an archive, writing code, and resolving dependencies—in a way that enabled the old technique to become an execution path.
The risk lies in the combination of tools
The cases illustrate why agent security cannot be measured only by asking whether a model rejects an obviously dangerous instruction. An agent may refuse to execute a binary and still download files, invoke a shell, create scripts, import dependencies, or devise an alternative workflow. Each action can appear reasonable in isolation. In combination, they can produce a security failure.
That means enterprise controls need to cover more than prompts and final outputs. They should also address file-system permissions, network access, shell execution, credential visibility, dependency resolution, and the provenance of external tools. A tool that is acceptable for reading public information may be unsuitable when the same agent can access source code, internal documents, payment infrastructure, or other sensitive systems.
The same principle is relevant to institutional wallets, custody platforms, and other asset infrastructure, although the reported incidents do not indicate that digital-asset systems were affected. In those environments, agent permissions would need to be separated carefully from key visibility, signing authority, and transaction execution. A general-purpose automation permission should not automatically imply the ability to authorize an asset movement or alter a policy. The point is not that every agent must be excluded from operational workflows, but that its capabilities should be bounded and independently auditable.
From model alignment to runtime governance
AIR’s fundraising and Rehberger’s research point toward the same industry shift: agent security is expanding from model behavior to runtime governance and tool-chain management. Better training can improve refusal behavior, but it cannot by itself resolve unverified add-ons, excessive permissions, hostile web content, unsafe dependency loading, or the absence of process isolation.
A more complete governance program could include inventories of agent components, provenance checks, signing requirements, continuous scanning, least-privilege access, sandboxed execution, and detailed logs. Organizations may also need explicit approval rules that distinguish between low-risk retrieval and high-risk actions such as writing files, running commands, accessing credentials, or communicating with external services. When an agent behaves unexpectedly, companies need a way to revoke access quickly rather than relying on the model to correct itself.
One-time review may also be insufficient. Skills, plug-ins, and external services can change after deployment, while the agent may encounter new forms of prompt injection through ordinary web content. Continuous assessment is therefore more appropriate than treating an agent tool as a static software package.
None of this means enterprise agents cannot be used. It does mean that deployment models built around broad permissions and informal user supervision are becoming harder to defend. As agents begin to operate across systems and carry information from one context to another, their tools are becoming infrastructure in their own right. The security question is no longer simply whether a model can follow instructions safely. It is whether the organization can verify what the agent is allowed to do, constrain how it does it, and reconstruct what happened when a chain of individually plausible actions produces an unsafe result.
Source: link