AI coding agents such as Claude Code, GitHub Copilot, and OpenAI Codex are no longer just code-suggestion tools — they've evolved into extensible agent runtimes that can introduce dozens of unvetted third-party components into enterprise systems, according to a report published by Akto CEO Ankita Gupta in August 2026. Security researchers uncovered roughly 7,600 malicious GitHub repositories, including more than 800 posing as AI Skills or MCP servers, which appeared over 600 times across public registries. The report argues that most AI governance programs stop at approving the application itself, but very few can track everything installed inside it — creating what the author calls a supply-chain gap where third-party components now participate in the agent's decision loop rather than just at build or deploy time.
The research identifies four categories of agent supply-chain failures already in the wild. Among 3,984 Skills examined, critical issues were found in 13.4%, with 76 confirmed malicious payloads designed for credential theft, backdoor installation, or data exfiltration. 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. Additional research demonstrated MCP tool poisoning, where malicious instructions were hidden inside tool descriptions, one server manipulated how an agent used another trusted server, and tool behavior changed after approval. Patched vulnerabilities in Claude Code and a related Cursor flaw called MCPoison enabled command execution, API-key theft, and persistent compromise triggered when developers opened apparently trusted projects.
"The new dependency is not only code the application executes. It is context the agent trusts," the report states. According to Gupta, a Skill is a folder of instructions, scripts, and resources that teaches an agent how to complete a repeatable workflow, while a plugin bundles Skills with connectors, subagents, hooks, and MCP server configurations — meaning approving one agent can introduce many additional suppliers. The report notes that traditional software composition analysis can find a vulnerable library but isn't 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. The author describes this as "Shadow AI inside approved AI" — organizations 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, making the application visible but the effective capability set invisible.
The report explains that the trust boundary has shifted 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, and an MCP tool description can influence which data the model sends to a server, all without any new binary appearing. One plugin isn't a single capability but a container for capabilities, creating transitive trust where 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, and a hook records, modifies, or forwards the result — each step may look reasonable in isolation, but the combined authority may be far broader than the user understood. The report recommends that security teams inventory the full extension layer including active Skills, plugins, hooks, instruction files, and MCP servers; control discovery and provenance using organization-managed registries and allowlists; review the complete capability graph a plugin brings rather than just the label; pin versions and diff every behavior change; enforce and record at runtime when the agent crosses sensitive boundaries; and red-team the instruction-to-action chain by testing whether a poisoned README can influence discovery or whether repository configuration can cross into local execution. The report concludes that if an organization can't enumerate every component in use, reconstruct why a specific agent action was allowed, or revoke one component across all platforms without waiting for user action, it has approved a vendor but hasn't governed the agent supply chain. Organizations that treat agent approval as a one-time decision rather than an ongoing capability audit may find themselves managing risk they can't see, while security teams that extend their threat models to include instruction-layer dependencies will gain visibility into a supply chain that already spans thousands of unvetted components.