Coding Assistants Threaten the Software Supply Chain

Understanding the Agent Loop Attack Surface

A compromised MCP server, rules file or even a code or dependency has the
scope to feed manipulated instructions or commands that the agent executes.
This isn’t just a minor detail – as it increases the attack surface compared
to more traditional development practices, or AI-suggestion based systems.

Figure 1: CD pipeline, emphasizing how
instructions and code move between these layers. It also highlights supply
chain elements where poisoning can happen, as well as key elements of
escalation of privilege

Each step of the agent flow introduces risk:

• Context Poisoning: Malicious responses from external tools or APIs
  can trigger unintended behaviors within the assistant, amplifying malicious
  instructions through feedback loops.
• Escalation of privilege: A compromised assistant, particularly if
  lightly supervised, can execute deceptive or harmful commands directly via
  the assistant’s execution flow.

This complex, iterative environment creates a fertile ground for subtle
yet powerful attacks, significantly expanding traditional threat models.

Traditional monitoring tools might struggle to identify malicious
activity as malicious activity or subtle data leakage will be harder to spot
when embedded within complex, iterative conversations between components, as
the tools are new and unknown and still developing at a rapid pace.

New weak spots: MCP and Rules Files

The introduction of MCP servers and rules files create openings for
context poisoning—where malicious inputs or altered states can silently
propagate through the session, enabling command injection, tampered
outputs, or supply chain attacks via compromised code.

Model Context Protocol (MCP) acts as a flexible, modular interface
enabling agents to connect with external tools and data sources, maintain
persistent sessions, and share context across workflows. However, as has
been highlighted
elsewhere,
MCP fundamentally lacks built-in security features like authentication,
context encryption, or tool integrity verification by default. This
absence can leave developers exposed.

Rules Files, such as for example “cursor rules”, consist of predefined
prompts, constraints, and pointers that guide the agent’s behavior within
its loop. They enhance stability and reliability by compensating for the
limitations of LLM reasoning—constraining the agent’s possible actions,
defining error handling procedures, and ensuring focus on the task. While
designed to improve predictability and efficiency, these rules represent
another layer where malicious prompts can be injected.

Tool-calling and privilege escalation

Coding assistants go beyond LLM generated code suggestions to operate
with tool-use via function calling. For example, given any given coding
task, the assistant may execute commands, read and modify files, install
dependencies, and even call external APIs.

The threat of privilege escalation is an emerging risk with agentic
coding assistants. Malicious instructions, can prompt the assistant
to:

• Execute arbitrary system commands.
• Modify critical configuration or source code files.
• Introduce or propagate compromised dependencies.

Given the developer’s typically elevated local privileges, a
compromised assistant can pivot from the local environment to broader
production systems or the kinds of sensitive infrastructure usually
accessible by software developers in organisations.

What can you do to safeguard security with coding agents?

Coding assistants are pretty new and emerging as of when this was
published. But some themes in appropriate security measures are starting
to emerge, and many of them represent very traditional best practices.

• Sandboxing and Least Privilege Access control: Take care to limit the
  privileges granted to coding assistants. Restrictive sandbox environments
  can limit the blast radius.
• Supply Chain scrutiny: Carefully vet your MCP Servers and Rules Files
  as critical supply chain components just as you would with library and
  framework dependencies.
• Monitoring and observability: Implement logging and auditing of file
  system changes initiated by the agent, network calls to MCP servers,
  dependency modifications etc.
• Explicitly include coding assistant workflows and external
  interactions in your threat
  modeling
  exercises. Consider potential attack vectors introduced by the
  assistant.
• Human in the loop: The scope for malicious action increases
  dramatically when you auto accept changes. Don’t become over reliant on
  the LLM

The final point is particularly salient. Rapid code generation by AI
can lead to approval fatigue, where developers implicitly trust AI outputs
without understanding or verifying. Overconfidence in automated processes,
or “vibe coding,” heightens the risk of inadvertently introducing
vulnerabilities. Cultivating vigilance, good coding hygiene, and a culture
of conscientious custodianship remain really important in professional
software teams that ship production software.

Agentic coding assistants can undeniably provide a boost. However, the
enhanced capabilities come with significantly expanded security
implications. By clearly understanding these new risks and diligently
applying consistent, adaptive security controls, developers and
organizations can better hope to safeguard against emerging threats in the
evolving AI-assisted software landscape.