For the last few years, application security had a clear boundary: the repository and the pipeline. That’s where the controls sat, where the scans ran, where teams decided whether something shipped to production. All of it rested on one assumption: a developer explicitly chose which code and which dependencies entered the system.
That assumption no longer holds. A growing share of code today is written, suggested, or installed by an AI agent, often without anyone looking at the name of what’s being pulled in. When the decision of what enters the code moves, so does the attack. It moves to the very front of the process: the moment the code is created, inside the assistant itself and in the files that configure it.
This is your AI attack surface: every model, agent, MCP server, skill, and AI-suggested dependency that can now introduce risk before a human ever reviews it. The same AI your developers trust is now part of it. This isn’t a future risk. It’s a shift that has already happened, and here’s what it looks like in practice.
A wave of attacks, not an isolated incident
None of the following is a lab exercise or a hypothetical. These are public, documented incidents, almost all from the past year, and each one lands a little closer to the AI agent itself:
- August 2025, s1ngularity: attackers stole a publishing token from Nx, one of the most widely used build systems, and pushed malicious versions to npm, using AI tools to hunt for secrets on developers’ machines.
- September 2025, chalk/debug: one of npm’s largest compromises by reach, 18 packages with more than two billion weekly downloads, taken over through the hijack of a single maintainer’s account.
- September 2025, Shai-Hulud: one of the first documented worms able to self-propagate via npm. Its second wave, in November, was more aggressive and tied to secrets exposed across more than 25,000 repositories.
- October 2025, unused-imports: part of the PhantomRaven campaign, where AI hallucination introduced real malware into npm through a slopsquatting technique.
- This year, ClawHub: a poisoned AI skill registry where five of the seven most-downloaded skills were malware.
The industry is formalizing the same conclusion. The OWASP Top 10 for LLM Applications puts prompt injection at number one. The OWASP MCP Top 10 (currently in beta) targets the protocol agents use to talk to tools. The OWASP Agentic Skills Top 10, a new Incubator-stage project, names malicious skills as its top risk. OWASP usually moves carefully; opening three fronts at once, one of them urgently, says something about how fast this is moving.
All three converge on the same idea: the instructions, tools, and configurations around a model are now part of the AI attack surface, and they usually live inside your own repository. Which raises the first question worth asking your teams: who reviews the rules files, skills, and MCP configs that live in your repo?
Vector 1: the poisoned skill
A skill is a file of instructions and capabilities that teaches an AI agent how to perform a task. It’s not the only way to shape an agent’s behavior (rules files, hooks, and MCP configs do the same), but they all share one property: they travel inside the repository, with the code.
Research this year reviewed 4,000 of these skills:
- 36% had at least one security flaw.
- 13.4% were critical.
- Close to 100 had malicious payloads outright.
The core shift: the attacker no longer targets your code. They target the agent that writes your code, planting hidden instructions (sometimes using invisible characters) that the model reads and treats as operative. A human reviewer approves the pull request in good faith because, to their eyes, the file looks clean. The model interprets instructions the reviewer never saw.
This isn’t theoretical. CVE-2025-59536 (CVSS 8.7) allowed launching Claude Code from an untrusted repository, where a malicious configuration could run commands before the user accepted the trust dialog. A second vulnerability, CVE-2026-21852, allowed exfiltration of an API key through project-controlled configuration, without the user approving anything.
H2: Vector 2: slopsquatting
The name blends “slop” (the junk an AI sometimes generates) with the classic typosquatting attack. Typosquatting depends on human error: an attacker registers a package name close to a popular one and waits for a typo. It’s random.
Slopsquatting doesn’t wait for a mistake. In the study referenced during this session, 19.7% of the package references generated by AI models pointed to packages that don’t exist. Models tend to hallucinate the same names repeatedly, so an attacker watches which names the AI invents, registers those names with malicious code, and waits for the next AI-suggested install to pull it into your application.
The scale is not small: more than 450,000 new malicious packages were identified in 2025. Two examples make it concrete:
- A researcher planted a harmless test package called huggingface-cli to prove the point. It logged more than 30,000 downloads in three months.
- unused-imports, from the timeline above, was confirmed malware, live in a public registry, using exactly this technique. That one was not a test.
The question isn’t whether this can happen to your team. It’s how many AI-suggested packages are entering your code today without anyone looking at them.
The response: standards are catching up
Two forces run in parallel. While the attacks accelerate, standards bodies are reacting:
- NIST SP 800-218A extends the secure software development framework with practices specific to AI models, including evidence of integrity and provenance.
- In May 2026, CISA and its international G7 partners published guidance on a Software Bill of Materials for AI, defining what belongs in that inventory: models, datasets, components, providers, and dependencies.
The direction is clear: the SBOM is expanding into an AI-BOM. You can’t certify or attest to what you can’t inventory. And today, most organizations can’t:
- 43% can’t audit or inventory the AI tools they’re already using.
- 79% have no visibility into the AI agents and MCP systems running in their own environment.
In regulated environments, this inventory is moving from good practice to contractual expectation or compliance obligation. But an inventory only tells you what you have. On its own, it doesn’t block an attack.
The gap: an EDR for AppSec
SAST and SCA tools are designed to analyze code and dependencies, not the behavior of an agent or its configuration. An EDR sees processes and network connections, but it typically lacks the application-security context to interpret a dependency or an agent configuration. Between those two categories of tools sits a gap, exactly where code is now being created, and exactly where the AI attack surface lives.
That gap has three blind spots:
- AI assets. Models, agents, and MCP servers don’t show up on your SAST’s or SCA’s radar. You can’t inventory what you can’t see.
- Configuration files. Skills, rules, and MCP configs shape agent behavior but are typically reviewed as if they were harmless plain text.
- Package installs. A malicious dependency can run before it’s known to be malicious, then exfiltrate secrets and tokens without anyone approving it.
How Xygeni closes it
What an EDR does for endpoints, Xygeni Shield does for the AI-assisted development lifecycle: it protects where code is created while understanding application-security context.
- Visibility where SAST and SCA don’t reach. Xygeni flags malicious skills and rules files, analyzes MCP configs, and builds an audit-ready AI-BOM, mapped to the OWASP LLM, MCP, and Agentic Skills Top 10s.
- Intelligence, not signatures alone. MEW (Malware Early Warning) analyzes the behavior and risk of a package to block it before a CVE, an advisory, or a public signature exists. Up-to-date network intelligence cuts connections to known-malicious infrastructure.
- One control point, from code to endpoint. A single agent, deployed without re-architecting the environment, with European data sovereignty and compliance evidence built in.
In a live demonstration, this policy enforcement blocked an AI agent’s attempt to install a malicious package across three different installation paths (virtual environment, package manager, and direct download) before the install completed, all logged in real time and exportable to a SOC. Onboarding a first project typically takes about an hour; extending coverage across a full organization usually takes one to two weeks, depending on structure.
FAQ
What is the AI attack surface in one paragraph?
The AI attack surface is the set of models, agents, MCP servers, skills, rules files, and AI-suggested dependencies through which risk can enter an application, often before a human reviews it. It extends beyond traditional code and dependencies to include the configuration files and instructions that shape how an AI agent behaves.
How can I tell if a package name suggested by my AI assistant is a hallucination or just legitimate but unfamiliar?
Validate before installing: check the registry and analyze the package’s actual content and intent rather than trusting the name alone. Xygeni automates this validation in real time during code generation, so an install is approved or blocked before it runs, whether or not the package is one you recognize.
Does slopsquatting affect all AI models equally?
The research behind the 19.7% figure covered multiple models and found the issue broadly distributed, with only small variation between them. This is a pattern across AI-assisted development, not a flaw specific to one assistant.
Can we check retroactively whether we’ve already installed a hallucinated or malicious package?
Yes. Xygeni’s platform gives customers access to a maintained database of detected malicious packages, searchable against your existing component inventory, so you can confirm in a couple of clicks whether anything already installed is a known threat.
How long does implementation take for a mid-sized organization with multiple teams?
Onboarding a first project typically takes about an hour. Scaling across a full organization usually takes one to two weeks, depending on team structure and ways of working.
Map your AI attack surface, for free
Map your application’s AI footprint for free: create an account and run a first scan in minutes. Start with a single application, see what AI is inside it, and see what part of your AI attack surface is dangerous.
*Some capabilities referenced above are enforced through Xygeni Shield and the ASPM/AI Security modules; availability may vary by plan. See xygeni.io for current product details.
