What is the promise of AI? Many would say that it’s efficiency: closing gaps left by human activity and automating repetitive work. But that leaves a lot unsaid, especially when it comes to security.

For instance, when developers “vibe code” and users download models, agents, and their skills from public repositories, it becomes harder to know whether every part of the process can be trusted. In cyber terms, this is a digital supply chain: AI models, third-party copilots, agent frameworks, and AI-powered workflows all create new dependencies.

And as recent npm (Node Package Manager) supply chain incidents have shown, trust can scale up risks just as quickly as it scales productivity. In AI, chasing quick wins without scrutiny may be exactly where the next weak link appears.

Key points of this article:

  • AI adoption is expanding the enterprise supply chain beyond software packages, adding models, agents, skills, plug-ins, and external inputs to the trust equation.
  • Traditional dependency abuse, seen in npm attacks, offers a useful warning for AI: Trusted components can become attack paths when scrutiny decreases.
  • Agentic AI changes the risk calculus because these tools can browse, retrieve data, call services, and act on behalf of users, not merely generate text.
  • The answer is not to avoid AI altogether but to govern what agents can access, block dangerous dependencies before use, and monitor behavior where the work happens.
  • Also, no, having on-premises AI does not remove the problem. Prompt injection, poisoned skills, malicious packages, and weak observability can still turn trusted automation against the business.

The digital supply chain

It’s not a secret why the digital supply chain has posed many problems for businesses over the years, with major incidents stemming from the use of third-party products or tools like SolarWinds Orion. However, while supply chain incidents at scale can bring huge repercussions, individual liberties taken with an AI can also unleash serious damage on any business.

Now, the question is not only what these chains contain, or why attackers target them. It is, or should be, what makes them so powerful. Consider software libraries, like lodash, requests, or react. They exist because developers cannot be expected to code every component themselves; even a modest application can take weeks or months to build, while production-ready enterprise software often takes even longer. Software libraries solve that problem by letting teams reuse proven code instead of starting from scratch. But the same convenience also creates dependency risks. 

A widely used package, such as axios, one of the most popular JavaScript HTTP clients on npm, can sit inside countless applications, meaning that trust in one component can silently extend across a vast part of the software ecosystem. Abusing said trust, then, is the enabling component.

For those not in the know: What is npm?

npm is the main package ecosystem for JavaScript (a coding language), allowing developers to download and reuse open-source code instead of building every component from scratch.

The year of npm supply chain attacks

Now for an example. The npm ecosystem has repeatedly shown how fragile dependency trust can become. Since 2025, campaigns such as Shai-Hulud and Mini Shai-Hulud used wormlike behavior to spread through trusted package relationships, stealing developer and cloud credentials to publish poisoned package versions. But credential theft is only one route. In other cases, attackers may exploit maintainer workflows, dependency confusion, malicious updates, or compromised build processes. 

Either way, the danger is not only from malicious code but also from trusted installation and build systems that can help the code/activity spread. Even worse, the same trust dependencies are now also creeping in from within the AI stacks businesses are frivolously onboarding.

Enemy within: AI, trust, and skills to die for

In the quest for greater productivity (the results of which are questionable), and convinced by AI companies with massive marketing budgets (and some legitimate results1), businesses are quickly adopting a slew of AI models whether the need to adopt them is valid or not. However, what is unquestionable is that in some cases, their use is not unwelcome.

But that’s all beside the point. What matters is all the security blind spots AI adoption creates. Let’s explain this via an example.

Say that a marketing agency onboards an AI bot with agentic skills to automate a few administrative tasks (reporting, for example), with some room left for the marketers to also use its generative properties for creative purposes. This model is internet-enabled, of course, as the capability to search online for inspiration makes sense.

However, that setup creates a chain of trust. The agency is no longer simply trusting the AI vendor, but also the model’s browsing behavior, the sources it retrieves, the plug-ins or connectors it uses, the prompts it receives, and the permissions it has inside the company environment. 

If the bot can access campaign reports, shared drives, client briefs, analytics dashboards, or email exports, then its “administrative helper” role quickly becomes something closer to a junior employee with broad access and very little instinct for suspicion.

Now imagine that during one of its internet-enabled research tasks, the bot comes across a poisoned webpage (or docs) dressed up as a marketing guide. To a human reader, the page might look like generic advice about improving ad performance. To the AI system, however, hidden instructions embedded in the page could attempt to override its original task and instead retrieve internal campaign data, summarize client information, or send outputs to an attacker-controlled endpoint if any connected tool allows it. 

This is the AI version of dependency abuse. The malicious component is not a downloaded package but an untrusted external input that the system is willing to treat as part of its workflow.

And because the bot acts on behalf of real users, the damage can be subtle. No one clicked or downloaded malware in the traditional sense. No developer intentionally installed a poisoned library. The business simply connected a helpful tool to useful data, gave it internet access, and assumed that its outputs were confined to the task at hand. But once AI systems can retrieve, interpret, and act on their own, every external source they ingest becomes part of the operational supply chain, as we have seen with some recent test-escaping escapades, for example.

“When AI-powered platforms are built at speed, basic cybersecurity and privacy controls are often the first things to slip,” commented Jake Moore, cyber security awareness specialist at ESET. “The real risk is not the AI agents themselves but the infrastructure behind them, where exposed databases and slapdash authentication can turn a simple oversight into a serious breach.”

Skills to die for

A particularly effective example of these blind spots at work are the thousands of malicious AI skills ESET Research has found. ESET has analyzed over 900,000 AI skills from popular repositories, and found that 25,000 were suspicious and over 3,000 were outright malicious.

Line chart showing unique AI skills scanned by ESET systems per day from March to May 2026, based on a seven-day moving average. Activity fluctuates sharply, with several spikes in April and the highest peak in May at roughly 55,000 unique AI skills.

These skills, for the uninitiated, are essentially small task manuals for AI agents. They tell the agent what to do, which tools or services to call on, and what data it may need to access along the way. In a benign setting, that sounds useful enough: a way to make agentic AI more capable, more consistent, and easier to plug into business workflows.

Concerned about an AI skill you have downloaded? Try the ESET Skills Checker.

The problem is that this also makes skills a neat place to hide malicious intent. A skill can be abused, or written from the start, to quietly steer an agent away from what the user asked for. That could mean exfiltrating data, downloading and executing malware, overriding user instructions, subtly changing the agent’s behavior over time, or even modifying the skill itself so the compromise becomes harder to spot.

Credit Claw
A great example of such a skill from ESET’s scanning is Credit Claw. This skill enables the agent to make purchases through platforms such as Amazon and Shopify, and to integrate with software-as-a-service (SaaS) environments. The risk rests in its access to payment methods and in turn, direct access to the user’s money. A harmful update or dependency could quietly alter that agent’s behavior and redirect the purchased goods or services to the attacker.

This is the trouble with agentic AI. While chatbots leave the final choice (which itself can be influenced via data poisoning) to the user, agentic AIs are agents of their own, meaning oversight is a bit more complicated, especially when an agent is capable of gradually changing its behavior from benign to malicious.

Diagram showing an AI agent connected to three types of third-party components: packages such as npm and PyPI code executed with the user’s permissions; AI skills containing instructions and capability files that may be followed literally; and MCP servers providing third-party services with deep access to tools, files, databases, browsers, and APIs.
The AI agent supply chain is a beast of an attack surface in and of itself.

It’s perception vs. reality again

The ESET SMB Cyber Readiness Index 2026 suggests that the security landscape hasn’t changed; instead, it’s merely that the winds that have shifted, blowing perception of AI out of proportion. Further ESET research2 also confirms this, though with the caveat that these perceptions are underlined by a vast misunderstanding of cybersecurity by responding users at surveyed businesses.

So, if organizations know that AI is risky, why do they continue adopting it? According to the Index, 70% acknowledge that AI introduces additional risks, yet only 60% have an AI security/governance policy.

In effect, Server Message Blocks (SMBs) may be overestimating the threat of AI-powered malware while underestimating the risks created by adopting AI systems that already have legitimate access to business infrastructure. As AI agents become capable of taking actions on behalf of users, the challenge shifts from stopping malicious code to monitoring “trusted” automation. A compromised endpoint can be isolated. A malicious AI skill operating inside approved workflows is a much harder problem to spot.

And we haven’t even mentioned shadow AI, a vastly more potent and elusive threat.

Convenience decreases scrutiny

If npm attacks taught developers to ask what they were importing into their applications, agentic AI should teach businesses to ask what they are importing into their decisions. Installing a skill may soon feel as routine as installing a browser extension, SaaS plug-in, or open-source package, which is exactly the problem.

The AI skill ecosystem, for example, inherits many of the supply chain risks seen in open-source software, browser extensions, npm packages, and developer tooling. 

How so? AI agents depend on various external building blocks, like software packages (npm, PyPI, crates), AI skills (as detailed above), and Model Context Protocol (MCP) servers (services that give agents tools like file access, database queries, or browser control). 

Yes, npms also play a major role here. Now consider the ramifications.

Every one of these also depends on code or instructions that have been written by strangers on the internet, and all of them have already been abused by attackers with:

Critically, because agents install these dependencies automatically and at machine speed, a human never gets the chance to review them. So it’s the classic software supply chain problem, but with the human checkpoint removed. The question, then, is where does this leave security monitoring? 

In the “blind,” pretty much.

Back to the gray

Previously, we mentioned the “blind,” or gray zone of cybersecurity, in relation to potentially unwanted and misused legitimate remote monitoring apps installed for malicious purposes. 

It’s worth mentioning here because abused software supply chain components can technically fall in the gray too, as legitimate and trusted tools can become compromised access points, as SolarWinds Orion did. Predicting which component will be abused next is not really possible, since these attacks target the implicit trust such tools already enjoy inside business systems.

However, before we throw the baby out with the bath water, it’s important to remember that trust can be governed, and attacks can still be detected. 

Taking AI out of the gray zone

In the AI skill space, organizations have more room to act than it may first seem. The problem is not that companies want to experiment with new tools; that is understandable, especially when productivity gains and competitive pressure are part of the pitch. The problem is treating that experimentation as risk-free.

In many ways, convenience decreases scrutiny. If a skill, connector, or agent promises quick value, it can be tempting to plug it in first and ask security questions later. But in an AI supply chain, every added capability also adds a new dependency, so prevention must start before those dependencies are allowed into the workflow.

So, how do we take AI out of this so-called gray zone? That’s relatively simple. Consider where AI use is happening: the endpoint. It’s the nexus of its activity, after all, where employees search, upload, and receive, data. You may ask, “But aren’t most agents cloud-based?” Sure they are. However, you’re still sending and receiving data to and from endpoints, which is where AI is interacted with.

“AI is a new class of actor inside the company. It reads, writes, decides, and executes—ideally with human permission. It deserves the same security attention as users and endpoints, because it behaves like both at once,” said Kamil Pšenák, senior product manager at ESET.

The trouble with securing the AI stack

The thing is, “the AI stack” is a bit of a loaded term. To better understand it, let’s break company AI use into distinct layers.

  1. Users: These are the people interacting with large language models (LLMs) via apps and browsers.
  2. AI-enabled apps: Think of your word processor app with native AI-calling capabilities to edit text, for example.
  3. AI agents: In other words, autonomous software acting on goals, like coding or workflow, or internal business agents.
  4. Agent supply chain: As described above, these are the packages, skills, and MCP servers or plug-ins in use.
  5. Runtime and infrastructure: Where the magic happens: endpoints, dedicated machines, virtual machines, private cloud, agent-building platforms (like Prismatic or n8n) etc.
  6. Models (LLMs): These are public cloud application programming interfaces (APIs), or hosted or on-premises models.

“Collectively, what matters is that each of these layers talks to the others around it. Every one of them is a channel where data can leak out or have malicious instructions read. In other words, anything which extends the context of AI is a potential attack vector,” said Filip Mazán, director of AI Security Labs at ESET.

With most AI resources coming from external (third-party-hosted) sources, there’s obviously a lot of that gray zone concentrated here. 

But saying that it’s strictly a cloud security problem would be a huge cop-out. It is tempting to think that if LLM and agents run on in-house servers, there’d be more transparency and security surrounding agents and models in use. However, on-premises hosting solves only one security concern: Your prompts are not sent to a third-party provider. Which is great, especially if you are data privacy conscious.

However, this still doesn’t solve these problems:

  • An on-premises model is just as susceptible to prompt injection—the vulnerability lives in how LLMs process text, not in where they are hosted.
  • An agent powered by an on-premises model can still run malicious commands, install poisoned packages, and be manipulated by content it reads.
  • The model itself is part of the supply chain: Open-weight models are downloaded from public repositories and can be tampered with or backdoored. “You cannot really know what is or is not part of the training data,” Mazán said.
  • Internal data leakage still matters. An internal AI with access to HR documents can leak them to an employee who should not see them.
  • You still have zero visibility into who is using AI/an agent and for what, unless you build it.

“The problem with agentic AI is that compromise no longer has to look like malware. Sometimes it looks like a trusted assistant doing exactly what it was told…by the wrong instruction. Public LLM, hosted LLM, on-prem LLM: It doesn’t matter that the location changes some risks, as it’s the behavior of the system which creates most of them. This is why AI security must sit around the stack, not just around the model,” said Pšenák.

Did you know? Open-weight models

Open-weight AI models are models whose trained parameters (weights) are made available for others to download, inspect, and run via platforms like HuggingFace. Much in the spirit of open-source software, open-weight models give users more control and transparency, but they are not always fully open source: the training data, code, or usage terms may still be restricted.

ESET weighs in on the AI supply chain

Honestly, the challenge of securing AI is not fundamentally different from traditional supply chain security, but it does take place at a greater scale. The number and diversity of components that now participate in business process “improvements” has increased, which has also increased the necessary scope of risk reduction measures. 

ESET can help organizations reduce agentic AI risk on two levels: first, by defending the building blocks autonomous agents assemble themselves from, and second, by monitoring their activity. Here’s how.

ESET AI Agent Security

First, ESET’s approach to preventing agentic malice is proactive. The public ecosystem agents draw on, like various software packages, skills, and servers, is continuously monitored, creating detections for malicious artifacts without ever needing to run them through an AI and enforced at two endpoint levels:

  • URL level: A malicious package, skill, or MCP server is blocked at download, before it reaches the machine.
  • File level: If the artifact is already present, it is detected and blocked on disk, before any agent gains access to it.

The key phrase is before the AI agent gains access. Consequently, the poisoned dependency never becomes part of the agent’s world. This way, response time drops from days of scanning to a single query. But on its own, this isn’t enough to secure the agentic supply chain.

ESET AI Behavioral Monitoring

The second component of full agentic supply chain security is to also protect against potential malicious behavior. Autonomous agents such as coding assistants in VS Code, Claude Code, OpenClaw, and their peers execute real commands on real machines, so ESET Behavioral Monitoring governs them right at the endpoint via:

  • Sanctioning: A company may decide these agents are simply not allowed, in which case they are discovered and blocked outright.
  • Monitored use: Where agents are permitted, every action is observed. When an agent attempts to run a shell command, the content is checked for malicious intent before execution. An injected agent trying to pipe a remote script into a shell, exfiltrate files, tamper with credentials, or modify system configuration is stopped at the moment of action, regardless of how it was manipulated into trying to do those things.

This is behavioral security in the classic endpoint sense, adapted to a new kind of actor. The process being watched is not malware but a legitimate AI tool that can be turned against the user at any moment by the content it sees. Behavioral monitoring assumes that will happen and makes sure it goes nowhere.

Conclusion: Inspecting the chain

Companies are opening themselves up to a wider threat landscape by adopting AI. Those that don’t see that writing on the wall might be surprised when their agent turns a bit “Skynet” and starts showing unintended behavior, like data exfiltration.

That is why AI adoption needs to be treated as supply chain expansion, not just software deployment. Every new model, skill, connector, and package adds another trusted link—and another place where compromise can scale.

AI_Security_GDA_970x250

FAQ: AI supply chain security

What is AI supply chain security?

AI supply chain security is about understanding and protecting all the external components an AI system depends on, from models and skills to plug-ins, packages, connectors, and data sources. As with traditional software, the risk is that one trusted piece can quietly become the path attackers use to reach many systems.

Why are AI agents a security risk?

AI agents are risky because they do not just generate text; they can browse, retrieve data, call and access tools, and execute actions on behalf of users. That means a bad instruction, malicious skill, or poisoned external source can turn a helpful assistant into an active part of an attack.

What is prompt injection in AI security?

Prompt injection is an attack where malicious instructions are hidden in text the AI system reads, such as a webpage, document, email, or tool output. The danger grows when that AI system is an agent with permission to access files, run commands, or move data.

Are open-weight AI models the same as open-source models?

Not always. Open-weight models make their trained parameters available to download, inspect, and run, which is similar to open-source software in spirit. But the training data, source code, safety methods, or license terms may still be restricted.

How can businesses reduce AI agent security risks?

Businesses can reduce risk by governing which AI tools are allowed, checking the dependencies agents rely on, limiting permissions, and monitoring behavior at the endpoint. The aim is not to stop AI use but to make sure trusted automation cannot quietly turn into a security threat.

 

Additional references:
[1] Z. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, & T. Salz. (2025). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. SSRN. https://doi.org/10.2139/ssrn.4945566
[2] ESET SMB MDR Research 2026, with a sample size of 2,500 SMBs with up to 250 devices from the U.S., UK, Germany, Italy, and Japan.