AI attack surface is moving into the repo and pipeline

At a glance

What this is: This is an analysis of how AI-assisted development expands application security risk into prompts, skills, MCP configs, and AI-suggested dependencies before human review.

Why it matters: It matters because identity, privilege, and approval controls increasingly need to govern non-human actors and machine-generated inputs, not just human developers and static code paths.

By the numbers:

• Research this year reviewed 4,000 of these skills: 36% had at least one security flaw.
• 79% have no visibility into the AI agents and MCP systems running in their own environment.
• 43% can’t audit or inventory the AI tools they’re already using.

👉 Read Xygeni's analysis of the AI attack surface in application security

Context

AI-assisted development changes the point of control. Instead of a developer deliberately choosing every dependency and configuration file, a model or agent can now propose, shape, or install code before a human reviewer sees it. That creates an AI attack surface inside the repository itself, where trust decisions were previously assumed to be human-led and visible.

For IAM and NHI teams, the relevance is not just code security. The same workflow that lets an assistant create files also lets it consume secrets, invoke tools, and pull in machine identities through MCP servers and package installs. That makes governance around approval, provenance, and least privilege part of AppSec and identity control at the same time.

Key questions

Q: How should security teams implement AI code generation controls in the SDLC?

A: Start at the point of generation, not at the point of release. Put SAST, dependency checks, and secrets detection directly into the developer workflow, then back them with CI/CD enforcement and runtime testing. That combination lets teams catch insecure suggestions early without trying to audit every generated line after the fact.

Q: Why do AI-suggested dependencies create supply chain risk?

A: AI-suggested dependencies create risk because the model can invent package names that appear plausible but are not trustworthy. Attackers can register those names and wait for the next automated or hurried install. The control gap is trust without verification, so teams need registry checks, provenance validation, and explicit approval before installation.

Q: What breaks when skills, rules files, or MCP configs are not reviewed like privileged controls?

A: What breaks is the assumption that these files are harmless text. They can change how an agent behaves, what tools it can call, and which data it can reach. If they are not reviewed as privileged controls, a malicious instruction can redirect execution while passing through ordinary code review.

Q: Who is accountable when an AI agent or build pipeline introduces malicious code?

A: Accountability sits with the teams that granted the agent, service account, or CI/CD pipeline its authority and failed to govern its lifecycle. That means IAM, platform engineering, security, and application owners all need clear control ownership for install rights, token revocation, and runtime containment.

Technical breakdown

Why AI-assisted development creates a new attack surface

AI-assisted development shifts risk from the endpoint of software delivery to the point where code is created. Models, agents, MCP servers, skills, rules files, and suggested dependencies can all influence what enters a repository before a human understands the content. That matters because traditional SAST and SCA tools inspect code and libraries after they exist, while the AI layer can introduce instructions, packages, or configuration changes earlier in the chain. The result is a control gap between creation and review, not just a problem with vulnerable code.

Practical implication: expand governance to cover AI-generated files and configuration artifacts before they are merged or installed.

How poisoned skills and MCP configs bypass review

A skill is an instruction set that teaches an agent how to act, while MCP configurations define how the agent connects to tools and data. Both can be stored alongside source code, which makes them look ordinary to reviewers even when they alter behaviour. Attackers can hide instructions in plain sight, use invisible characters, or exploit untrusted configuration paths so the model executes actions the reviewer never intended. This is a governance problem because the artefact being reviewed is not always the artefact being executed.

Practical implication: treat skills, rules files, and MCP configs as privileged controls that require content inspection and provenance checks.

Why slopsquatting works against AI-suggested dependencies

Slopsquatting targets hallucinated package names produced by AI systems. Instead of waiting for a human typo, an attacker registers names the model repeatedly invents and waits for the assistant to recommend them during development. If the package is installed automatically or with weak validation, the malicious dependency enters the build path before any security signal exists. This attack blends supply chain abuse with AI trust failure, because the model becomes the mechanism that selects the attacker-controlled package name.

Practical implication: validate package existence, intent, and provenance before installation, especially when the dependency came from an AI assistant.

Threat narrative

Attacker objective: The attacker wants to convert trusted AI-assisted workflows into an execution path for secret theft, code compromise, and supply chain persistence.

1. Entry occurs when an AI assistant, skill, or model-generated package suggestion introduces unreviewed content into a repository or build workflow.
2. Escalation happens when malicious instructions, unsafe MCP access, or a registered hallucinated package is trusted and executed before security review catches it.
3. Impact follows when the attacker gains secrets, code execution, persistence in the supply chain, or downstream compromise across development systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted development has become an identity and trust problem, not just an AppSec problem. When an agent can choose packages, write config files, or call tools, it is acting as a non-human identity that needs governed authority. The control question shifts from whether the code is clean to whether the entity making the decision was allowed to make it. Practitioners should treat AI-generated actions as governed identity events, not passive tooling output.

Configuration-layer compromise is the new privileged path into software supply chains. Skills, rules files, and MCP configs sit in a blind spot because they are not traditional source code, yet they can direct execution. That creates a named failure mode: configuration trust gap. Security teams need to understand that the path of least resistance is often the file that shapes behaviour, not the binary that ships.

Slopsquatting is a governance failure in dependency validation, not a novelty attack. The attacker wins when organisations trust an AI-suggested package name more than they verify registry existence and provenance. This is where application security and identity governance meet: machine-generated recommendations should never bypass controlled approval. Teams should make install-time trust explicit and policy-driven.

AI-BOM and provenance are becoming minimum viable controls for regulated software estates. If organisations cannot inventory models, agents, MCP systems, and dependencies, they cannot attest to the software they are shipping. That problem is especially acute in environments where third-party assurance, customer contracts, or internal control frameworks require evidence of what entered the build. Practitioners should move from reactive package response to governed software inventory.

The market is converging on runtime enforcement because static review alone is no longer enough. The article’s broader pattern is that prevention must happen before execution, whether the risk arrives through a model, a skill, or an AI-suggested package. That aligns with the direction of modern software governance: prove what was allowed, what was blocked, and what identity had the authority to decide.

From our research:

• 79% have no visibility into the AI agents and MCP systems running in their own environment, according to The State of Secrets in AppSec.
• 43% can’t audit or inventory the AI tools they’re already using, which leaves assurance teams without a reliable software boundary.
• Forward pivot: For a broader control model, see Top 10 NHI Issues for the governance gaps that appear when machine-led workflows scale.

What this signals

Configuration trust will become a first-class control domain. Organisations that still treat rules files, skills, and MCP configs as low-risk text will miss the point of how AI-assisted compromise works. The practical shift is toward change-control, provenance, and identity-bound approval for files that direct behaviour, not just source code. Teams that cannot prove who authorised the agent’s actions will struggle to prove control.

The next maturity step is to unify AppSec, IAM, and supply-chain governance around agent-mediated workflows. That means connecting install-time policy, secret handling, and tool permissions to a single evidence trail. For programmes already struggling with visibility, the path forward is not more scanning alone but tighter decision rights over what an AI system can introduce.

For practitioners

• Inventory AI-assisted build inputs Classify models, agents, skills, rules files, MCP configs, and AI-suggested dependencies as governed software inputs, then require ownership and approval for each class.
• Block unverified package installs Require registry verification, package intent analysis, and provenance checks before any AI-suggested dependency can enter CI or a local environment.
• Apply least privilege to agent tool access Restrict what an AI agent can read, write, install, or invoke so that a compromised assistant cannot turn a single suggestion into broad execution rights.
• Treat config files as privileged artifacts Subject skills, hooks, and MCP configurations to the same review, logging, and change-control standards you already apply to sensitive automation and access policy files.
• Build an AI-BOM evidence trail Track models, datasets, components, providers, and dependencies so security, compliance, and engineering teams can prove what entered the software estate.

Key takeaways

• AI-assisted development expands the attack surface into prompts, skills, configs, and dependency suggestions before human review happens.
• The most dangerous failure is not just malicious code, but unverified trust in machine-generated instructions and package names.
• Practitioners need governed approval, provenance checks, and least privilege for agents if they want software inventory and identity controls to keep pace.

Key terms

• Agentic AI attack surface: The set of AI workloads, tools, prompts, and connected services that can be influenced or abused at runtime. It includes not only the model itself but also the identities and integrations that let the system act. For governance, the surface is defined by behaviour as much as by deployment.
• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.

What's in the full article

Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:

• Walkthroughs of how the AI attack surface appears in skills, MCP configs, and dependency workflows.
• The live demo path showing how policy enforcement blocked a malicious package across multiple install methods.
• Details on the AI-BOM and the evidence needed to support audit and compliance workflows.
• Implementation timing and deployment scope for teams rolling out agent-side controls.

👉 The full Xygeni post covers attack examples, control gaps, and the deployment model in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need stronger control over machine-led workflows. It helps security leaders connect identity governance to the operational realities of modern software delivery.