AI attack surface is moving into the repo and pipeline

At a glance

What this is: AI-assisted development is moving risk into repository files, agent instructions, MCP configs, and suggested dependencies, so the control point has shifted upstream of human review.

Why it matters: IAM, AppSec, and platform teams now need governance over what an AI agent can introduce, not just what a developer commits, because traditional review and scanning miss configuration-layer risk.

Context

Application security used to assume that a human decided what entered the repository and pipeline. That assumption is now weak because AI assistants and agents can suggest, write, and install code paths before anyone reviews the file contents or dependency names.

The security gap is not just in code. It also sits in rules files, skills, and MCP configurations that control how an AI system behaves inside the development workflow. That creates a governance problem for AI-assisted development, because the organisation must understand both the software supply chain and the identity-like authority of the agent acting within it.

Key questions

Q: How should teams govern AI-suggested dependencies and package trust?

A: Teams should treat AI-suggested dependencies as untrusted until validated. That means checking for typosquatting, malware behaviour, suspicious install scripts and package provenance before installation, then enforcing exact pinning and build-time policy. The goal is to stop hallucinated or malicious packages from becoming an easy supply chain entry point.

Q: Why do AI control files create a new security risk?

A: AI control files matter because they can change agent behaviour without looking like executable code to a human reviewer. That creates a governance gap between visible repository content and the instructions the model actually follows, so teams need explicit policy, ownership, and review for those files.

Q: What breaks when repository review is the only control for AI-assisted development?

A: Review-only control breaks when the risky decision happens before a human sees the artefact. A model can suggest a malicious package, interpret hidden instructions, or carry unsafe configuration into the build path, so the organisation needs controls at creation and installation time, not just pull request time.

Q: Should organisations prioritise AI-BOM work before runtime blocking?

A: They should do both, but AI-BOM comes first when the organisation cannot reliably inventory its AI footprint. Runtime blocking is essential for containment, yet inventory and provenance tell teams what they are actually governing, which is critical for release assurance and accountability.

Technical breakdown

How poisoned skills change repository trust

A skill is a configuration file that tells an AI agent how to perform a task, but the same pattern also applies to rules files, hooks, and MCP configs. These files live beside source code, so they inherit developer trust even when they contain instructions that the reviewer never notices. Attackers can hide commands with formatting tricks or invisible characters, then rely on the model to interpret them as operational instructions. The control failure is not just malware detection. It is the absence of content-aware review for AI control files that can influence execution before a human approval step.

Practical implication: Treat AI control files as governed artefacts, not plain text, and subject them to policy and provenance checks before merge.

Why slopsquatting turns model output into supply-chain risk

Slopsquatting happens when an AI model hallucinates a package name and an attacker registers that name with malicious code. Unlike typosquatting, which depends on human error, this attack uses the model’s own pattern generation against the software supply chain. The risky moment is the install decision, because the suggested package may look plausible even when it never existed before. This is a repository and pipeline problem because the AI-generated dependency can enter before security tooling has any reason to trust or block it.

Practical implication: Validate AI-suggested dependencies against registries and package behaviour before installation, not after the dependency is already in use.

Why AI-BOM and provenance are now part of delivery governance

An AI-BOM extends software inventory thinking to models, datasets, components, providers, dependencies, and agent controls. That matters because organisations cannot govern what they cannot enumerate, and traditional SAST, SCA, and endpoint tools do not fully describe the AI layer that now shapes code creation. Provenance evidence matters here because it helps separate approved AI assets from opportunistic or malicious ones. In practice, this is a governance shift from scanning artefacts after they appear to controlling the identity and origin of the artefacts before they influence delivery.

Practical implication: Build an inventory of AI assets and tie it to provenance evidence so delivery decisions can be enforced at source.

Threat narrative

Attacker objective: The attacker wants to get malicious instructions or packages into the delivery path before human review so they can steal secrets, run code, or persist in the software supply chain.

1. Entry occurs when a malicious skill, MCP config, or hallucinated package name enters the repository or assistant workflow before review.
2. Credential or instruction abuse follows when the agent interprets hidden directives or installs the suggested dependency as if it were trusted input.
3. Escalation occurs when the code path, package, or configuration reaches the build or execution stage and can exfiltrate tokens or alter behaviour.
4. Impact is the insertion of malicious code or secret theft through a supply-chain path that bypassed normal developer scrutiny.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Repository trust has become an identity problem for AI-assisted development. The article describes a shift from human-selected code to AI-suggested instructions and packages, which means the authority to introduce risk now sits partly with the agent. That is an identity and governance issue because the organisation must decide what the assistant is allowed to propose, install, or execute. Practitioners should treat AI-assisted commits as governed actions, not passive content.

AI control files create a new governance surface inside the repo. Rules files, skills, hooks, and MCP configs are effectively policy artefacts for agent behaviour, but they are usually reviewed like ordinary text. That creates a trust gap between what the human sees and what the model executes. The named concept here is agent control-file drift: the growing gap between visible repository content and the operational instructions the agent actually follows. Teams need explicit ownership and review for these files.

Slopsquatting shows that model error has become a supply-chain attack surface. The attacker no longer needs to guess a typo because the model itself can invent the package name first. That makes AI-suggested dependencies part of the security decision chain, not just convenience output. For practitioners, this validates the move toward provenance, package validation, and policy gates at install time rather than after the fact.

AI-BOM is becoming the minimum inventory layer for AI-enabled delivery. The article’s standards references point in the same direction: you cannot govern AI-assisted software without knowing which models, agents, datasets, dependencies, and configs are in play. This is not only a software supply-chain concern; it is also a control boundary problem for identity governance around non-human actors. Practitioners should make inventory and provenance a release requirement, not a post-incident exercise.

Runtime enforcement is now the deciding control when review fails to see the risk. Static review still matters, but it is no longer sufficient when malicious instructions can hide in plain sight or when package names are generated dynamically. The field should move toward policy enforcement that can block unsafe installs and untrusted agent actions in execution context. The practical conclusion is clear: if the agent can act, the control must exist where it acts.

What this signals

Agent control-file drift: the gap between what reviewers think the AI system will do and what the assistant actually executes is now a material governance issue. Teams need to classify rules files, skills, and MCP configs as policy-bearing artefacts, then gate them through release controls rather than treating them as ordinary repository text.

The practical boundary has shifted from code review to instruction review and install-time enforcement. If a model can propose the dependency and the agent can act on it, then provenance, inventory, and approval must be checked before execution, not after the commit lands.

For practitioners

• Govern AI control files as release artefacts Require review and policy checks for rules files, skills, hooks, and MCP configs before they can influence an agent in a repository.
• Validate AI-suggested dependencies before install Block package installation until registry presence, package metadata, and behavioural checks confirm the dependency is legitimate.
• Build an AI-BOM for every AI-enabled application Inventory models, datasets, providers, dependencies, and agent controls so delivery teams can see what is actually in scope.
• Enforce provenance and approval gates at runtime Use policy enforcement that can stop unsafe installs or agent actions when the repository review layer misses hidden instructions.
• Separate human code review from agent behaviour review Create a distinct control path for AI instructions and agent actions so reviewers do not mistake generated text for trusted configuration.

Key takeaways

• AI-assisted development moves security risk into the files and instructions that govern agent behaviour, not just the source code itself.
• Model-generated package names and hidden repository instructions create a supply-chain path that traditional review can miss.
• Inventory, provenance, and runtime policy enforcement are now the controls that matter when AI can influence what enters the build.

Key terms

• 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.
• 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.
• MCP Configuration: MCP Configuration is the set of settings that tells an AI agent how to connect to Model Context Protocol tools, data sources, and permissions. It defines endpoints, authentication, allowed actions, and context boundaries. In practice, it governs how an agent discovers and uses external capabilities without exposing unnecessary data or control.
• Agent Control File: An agent control file is any repository-stored file that shapes an AI assistant’s behaviour, such as a skill, hook, or rules file. These artefacts can influence what the agent does before a human notices, so they require strict review and provenance controls.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the wider security programme that now has to govern AI-enabled delivery.