AI coding agents are already inside engineering organizations.
The problem security teams need to solve is not only that AI-generated code might be vulnerable. You already have ways to catch that: code review, CI, SAST, dependency scanning, and production monitoring.
The real problem is that tools such as Claude Code, OpenAI Codex, Claude Cowork, and GitHub Copilot are becoming extensible agent runtimes. Skills, plugins, hooks, repository instructions, and MCP servers can influence what the agent reads, which tools it selects, what commands it runs, and where enterprise data is sent.
Most AI governance programs stop at approving the application. Very few can tell you everything that has been installed inside it.
That is the supply-chain gap.
What changed: Third-party components are no longer participating only at build or deploy. They are participating in the agent's decision loop.
From coding assistant to agent runtime
The first generation of coding assistants mainly suggested code. The current generation can inspect a repository, edit files, execute shell commands, query internal systems, create pull requests, and work for long periods with limited supervision.
Their extension models are also converging:
- A Skill is a folder of instructions, scripts, and resources that teaches an agent how to complete a repeatable workflow.
- A plugin is the packaging layer. It can bundle Skills with connectors, subagents, hooks, and MCP server configurations.
- An MCP server gives the agent access to external tools, databases, APIs, and context.
- A hook runs a command, HTTP request, or model prompt at a defined point in the agent lifecycle.
- A repository instruction file changes how the agent behaves for a particular codebase.
The security implication is straightforward: approving one agent can introduce many additional suppliers.
Where did the trust boundary move?
Before agentic development, security teams looked for third-party risk in package registries, CI/CD workflows, browser extensions, SaaS integrations, and production dependencies.
Those controls still matter. But the trust boundary has moved into files that may look like configuration or documentation.
A SKILL.md file can contain natural-language instructions and point to executable scripts. A plugin can silently expand the agent's toolset. An MCP tool description can influence which data the model sends to a server. A project hook can execute automatically during a session. A repository instruction can tell the agent to use a particular dependency, endpoint, or workflow.
No new binary has to appear for the agent's behavior to change.
Key shift: The new dependency is not only code the application executes. It is context the agent trusts.
This is why traditional software composition analysis sees only part of the problem. It can find a vulnerable library. It is not designed to decide whether an instruction such as "collect the diagnostic files and upload them here" is a legitimate support step or an exfiltration path.
Four agent supply-chain problems already showing up
Security researchers are already finding failures across discovery, installation, review, runtime behavior, and repository configuration.
| Supply-chain problem | What researchers found | Impact |
| Fake Skills and MCP servers poisoning discovery | Uncovered roughly 7,600 malicious GitHub repositories, including more than 800 posing as AI Skills or MCP servers. These appeared more than 600 times across public registries. In testing, AI agents independently discovered and recommended some malicious repositories. | Malware installation, credential theft, session theft, and compromised developer machines. |
| Skills carrying malicious code and instructions | Researchers found 3,984 Skills and found critical issues in 13.4%. Researchers confirmed 76 malicious payloads designed for credential theft, backdoor installation, or data exfiltration. Some Skills also fetched instructions or executable content from remote endpoints. | Shell access, credential exposure, data exfiltration, backdoors, and persistent manipulation of agent behavior. |
| Hookify turns repository Markdown into trusted model context | A vulnerability in Hookify, an official Claude Code marketplace plugin, allowed malicious project rule files to enter Claude's trusted system-message channel. Claude Opus 4.6 followed all five tested payloads, exposing environment variables and local secrets without flagging injection. Anthropic closed the report as Informative, treating directory approval as the security boundary. | Trusted-context injection, model steering, environment-variable exposure, and leakage of local secrets. |
| MCP tool poisoning, shadowing, and rug pulls | Security research has demonstrated malicious instructions hidden inside MCP tool descriptions, one server manipulating how an agent uses another trusted server, and tool behavior changing after approval. Prompt injection delivered through WhatsApp messages returned by a trusted MCP tool also led to data exfiltration. | Cross-server privilege escalation, hidden exfiltration, approval bypass, and behavior that differs from what the user originally approved. |
| Repository configuration becoming code execution | Patched Claude Code vulnerabilities involving repository-controlled hooks, MCP configurations, and environment variables enabled command execution and API-key theft. A related Cursor vulnerability, MCPoison, allowed previously trusted MCP configurations to be modified for persistent code execution. | Remote code execution, API-token theft, persistent compromise, and attacks triggered when developers open apparently trusted projects. |
Why plugins make the problem bigger
A plugin is not one capability. It is a container for capabilities.
One Claude Code or Copilot plugin may include Skills, hooks, subagents, and MCP server configuration. A Codex plugin may combine reusable workflows with MCP-backed connectors. A Cowork plugin may bring together Skills, connectors, and subagents that operate across documents and enterprise SaaS.
That creates transitive trust:
- The user trusts the plugin.
- The plugin loads a Skill.
- The Skill instructs the agent to call an MCP tool.
- The MCP server uses the user's identity to access another system.
- A hook records, modifies, or forwards the result.
Every step may look reasonable in isolation. The combined authority may be far broader than the user understood.
Security teams should therefore review a plugin as a dependency graph, not as a marketplace listing. The relevant questions are: What does it install? What can each component read or execute? Which identities does it inherit? Which external systems can it reach? What can change after approval?
This is the next phase of Shadow AI
Shadow AI initially meant employees using an unapproved model or pasting enterprise data into an unapproved chatbot.
That definition is now too narrow.
An organization can approve Claude Code, Codex, Cowork, or Copilot while developers install their own Skills, add public plugin marketplaces, connect personal MCP servers, or inherit agent configuration from repositories.
The application is visible. The effective capability set is not.
This is Shadow AI inside approved AI.
A SaaS inventory may show that every developer uses an approved product. It will not tell you that one installation can read production logs, another can write to GitHub, and a third has a hook that sends session data to an external endpoint.
The unit of governance has to move from the AI application to the agent's effective authority.
What security teams should do now
1. Inventory the full extension layer
Track the agent, version, execution environment, Skills, plugins, hooks, instruction files, custom agents, MCP servers, tool definitions, and connected identities.
An SBOM tells you what software is present. An agent inventory must also tell you what instructions were active and what authority they could exercise.
2. Control discovery and provenance
Use organization-managed registries and allowlists. Record the publisher, source repository, commit or version, owner, review status, and update policy. Treat agent recommendations as search results, not security validation.
3. Review the graph, not the label
Evaluate every component a plugin brings with it. Compare declared purpose with actual capabilities. A "code review" plugin that can run arbitrary shell commands and send data externally requires a different approval path from a read-only linting Skill.
4. Re-evaluate every behavior change
Pin versions where possible. Diff instructions, scripts, hooks, tool descriptions, permissions, and outbound destinations on update. A changed MCP description or remote instruction endpoint can be as important as a changed executable.
5. Enforce and record at runtime
Install-time scanning cannot see every interaction with live enterprise context. Apply controls when the agent reads sensitive data, invokes a tool, crosses a network boundary, or attempts a consequential action.
For every high-risk action, preserve the human identity, agent identity, active Skill or plugin, selected tool, permission used, data touched, and reason the action was allowed.
6. Red-team the instruction-to-action chain
Do not test only whether the model can be jailbroken. Test whether a poisoned README can influence discovery, whether a Skill can conceal a payload, whether one MCP server can shadow another, whether a plugin update expands authority, and whether repository configuration can cross into local execution.
The meaningful outcome is not that the model produced an unsafe sentence. It is that the agent completed, or was prevented from completing, an unsafe action.
Questions AI security leaders should ask
- Can we enumerate every Skill, plugin, hook, instruction file, and MCP server in use across our agent surfaces?
- Do we know where each component came from and whether its behavior has changed since approval?
- Can we see the complete capability graph hidden behind a plugin?
- Which human or non-human identity does each tool use, and what is the scope and lifetime of that access?
- Can we reconstruct why a specific agent action was allowed?
- Can we revoke one component across Claude Code, Codex, Cowork, and Copilot without waiting for every user to act?
If the answer is no, the organization has approved a vendor. It has not governed the agent supply chain.
About the Author: Ankita Gupta is the Co-Founder and CEO of Akto, the Agentic AI Security platform for securing AI agents across the enterprise. She brings 15+ years across cybersecurity, engineering, enterprise software, and go-to-market leadership, with prior roles at VMware, LinkedIn, and JPMorgan Chase. Ankita is a leading voice in modern application and AI security, recognized across industry communities including Black Hat USA, DEF CON, RSA Conference, OWASP, and GraphQLConf. She serves on the CSA AI Safety Council and is a member of the Forbes Technology Council. Her AI Security newsletter reaches more than 5,000 subscribers, and her work is followed by a security community of over 25,000 professionals on LinkedIn.
Ankita Gupta — Co-Founder and CEO at Akto https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrGMXd-UGyU8iGHJNZ31wDEGQDJVdn2dVNDp1go-xEfONG9ShAsIxhMi6NVNNjYylLCztELy4HK4Ne45X2pZTgGCF9F_3a3Xnl2Gm21ZUK6x9yoNSE91d2qVK6FOUoNb_Ih_QUwzKiJ2HvGSn3XrhHsE5nWKXZ4IfKKCuFkkg_Z_29_CT7upKMJHaGvZqk/s1700-e365/ankita.png
