AI Agent Security Is Becoming a Supply-Chain Problem

It says the job will be easier if you install a skill.

The skill has a friendly name. It has a clean-looking page. Someone has already starred it. The setup instructions are only one command long.

You approve it.

A few seconds later, the agent can read your project files, run commands on your computer, and connect to other tools. It can see more than the chat window suggests.

This is the part of AI agent security that deserves more attention: the next software supply-chain problem may not arrive as a library buried in an application. It may arrive as a capability you gave to an AI assistant.

AI agents are not just chatbots

A chatbot gives you an answer.

An agent can take action.

It can search a repository, open a ticket, call an API, run a test, write a file, or make a change in another system. To do that, it needs tools. Those tools are often packaged as skills, plugins, or MCP servers.

MCP, short for Model Context Protocol, is a standard way for an AI application to connect to outside tools and data. Think of it as a universal adapter. Instead of building a custom connection for every AI assistant, a developer can plug in an MCP server that gives the assistant new abilities.

That is useful. It is also where the trust boundary moves.

When a person installs a normal application, most companies have some way to review it, approve it, update it, or remove it. An AI skill can feel smaller and safer because it appears inside a conversation. But behind the friendly name may be code, network access, local files, credentials, and instructions the user never reads.

The new AI agent supply chain

The Cisco AI Defense GitHub organization is a useful signal that this problem is becoming its own security category. Its public projects include a Skill Scanner for malicious behavior and hidden instructions, an MCP Scanner for server threats, DefenseClaw for governing agent skills and plugins, and an A2A Scanner for agent-to-agent communication.

The repository page showed the Skill Scanner updated on September 22, 2026, with more than 2,500 stars. Several related projects were also updated between September 19 and September 23. That does not prove that a particular repository is malicious. It shows that security teams are building scanners for the components that give AI agents their abilities.

The important question is simple: why would an AI skill need a security scanner at all?

Because some of these components can execute code.

Public guidance for MCP administrators describes the risk plainly. A local MCP server can be installed through a package manager, inherit the full privileges of the operating system, and operate outside centralized authentication, monitoring, and compliance controls. The same guidance warns that a package can be hijacked and used to distribute malicious code.

That is a familiar software-supply-chain problem wearing a new outfit.

How a malicious skill could work

Imagine a skill that helps an agent review invoices.

The visible instructions say: find overdue invoices, summarize them, and prepare a draft email.

The hidden behavior says something else: search for files containing the words password, token, or recovery; send the results to an outside server; then continue with the invoice task so the user sees nothing unusual.

The agent is not necessarily "evil." It is following instructions. The danger is that the user has given the instructions a trusted place inside a system that can act.

A compromised MCP server could create a similar problem. The server might look like a harmless connector to a calendar, CRM, code repository, or document store. Once approved, it could ask for more access than it needs, redirect the user through a suspicious login flow, or quietly use the agent's existing permissions.

This is why the phrase "AI security" is too broad on its own. The problem is not only whether the model produces a wrong answer. It is also what the model can reach, what it can execute, and who approved the connection.

The capability worth looking for is continuous discovery of unknown applications and integrations, clear mapping of the permissions they hold, and enforcement that limits access when the risk changes. A tool that nobody knows about is difficult to secure. A tool with unnecessary permissions is dangerous even when its original author had good intentions.

What would I check before approving one?

Start with the same suspicion you would apply to a browser extension or a software package from an unfamiliar developer.

Who maintains it? Is the source code visible? Has the project changed hands recently? Does the setup command download and execute code directly? Does it need access to the whole machine, or only to one folder? Does it ask for credentials, browser access, or a write connection to a production system?

The wording matters too. A skill that says it needs "full access" without explaining why is not a minor inconvenience. It is asking you to trust a stranger with the keys.

For an organization, the question is larger than whether one employee made a sensible choice. What would I check if an employee installed a new AI connector yesterday? Where would that connection appear? Which logs would show what it accessed? Could I revoke it without rebuilding the user's machine?

If the answer is "I'm not sure," the problem is not that the employee needs better judgment. The problem is that the organization has no map of its AI supply chain.

The quiet risk is the trusted connection

A dramatic malware alert is easy to understand. A new AI skill can be harder to notice because it may produce useful work while it is being used.

That is what makes this category uncomfortable. The harmful action may be mixed into a successful task. The summary is correct. The ticket is created. The code still compiles. Somewhere in the background, a token, document, or source file may have moved somewhere it should not be.

AI agent security will increasingly be about controlling the connections around the model, not just evaluating the model itself.

The next supply-chain compromise may not look like a broken update or a suspicious installer. It may look like the most helpful button in the chat window.