AI coding assistants have evolved rapidly over the past few years. What began as simple code-completion tools has evolved into coding agents capable of planning work, using tools, executing terminal commands, modifying repositories, retrieving documentation, and completing complex development tasks with minimal human guidance.
Coding agents promise faster software development, reduced operational overhead, and the ability to automate increasingly complex engineering tasks. As these systems become more capable, many organizations are beginning to treat them less like productivity tools and more like autonomous collaborators.
Much of the conversation surrounding this evolution has focused on the language models powering these agents. However, while models remain an important part of the equation, they represent only one component of a much larger system. The real security challenge lies in the agent’s harness, the execution layer that coordinates model interactions, tool calls, and workflows, as well as the repositories it can access, the documentation it consumes, the tools it invokes, and the growing ecosystem of skills that shape its behavior.
As coding agents become active participants in software development, organizations are no longer securing a single AI model. They're securing an entire execution environment composed of models, context, tools, skills, and orchestration logic. Coding agents are also maturing harnesses for broader use, and the same execution layer is beginning to power agents that handle work well beyond software development. That shift inherently changes how AI systems must be defended.
Coding agents are changing the trust model
Unlike traditional chatbots, harnesses like coding agents are designed to perform work on a codebase rather than simply answer questions about that codebase. To accomplish that work, they retrieve information from both trusted and untrusted sources before invoking tools and executing commands. A single task, such as fixing an API usage bug, might require an agent to consult a code repository, search public documentation, inspect a GitHub issue, and then update source code, all within the same workflow.
This ability to gather and synthesize context is what makes coding agents so effective. Rather than relying solely on user prompts and intrinsic LLM knowledge or static document sets, they continuously collect the information needed to reason about a problem and determine the next action. That capability also critically changes the trust model.
Developers naturally evaluate the credibility of the information they consume. They can recognize an outdated blog post, question suspicious documentation, or ignore an instruction that doesn't make sense in the context of their work. A developer’s skepticism naturally increases as their understanding of the potential blast radius of an action increases.
Coding agents, however, are designed to retrieve information automatically and incorporate it into their reasoning. Every README they parse, every documentation page they summarize, every issue they inspect, and every website they visit can influence how they behave. Rather than being skeptical of dangerous actions, the underlying models used in coding agents primarily reward helpfulness by following instructions.
As a result, every new source also becomes a potential
attack surface for indirect
prompt injections. Rather than directly prompting the model, an adversary can manipulate the information an agent is likely to retrieve by embedding malicious instructions into documentation, code examples, issue comments, or other external resources. These indirect prompt injection attacks leverage the underlying model’s helpfulness training, which seeks out external information sources in an attempt to solve the user’s request, to exploit the agent's trust model.
Most of the time, this additional information is necessary and really does help the model solve the given task. The challenge, therefore, is not reducing the amount of context an agent consumes, as its effectiveness depends on that context. The challenge is enabling agents to reason over information from many sources without allowing untrusted content to influence privileged actions.
The trust model doesn't stop with the information an agent retrieves. It also extends to the components that shape how an agent behaves, introducing an entirely new set of supply chain considerations.
Coding agents introduce a new AI supply chain
Software supply chain security has traditionally focused on protecting the components developers rely on to build applications. Organizations learned to verify dependencies, monitor package registries, scan open source libraries, and validate software artifacts because attackers increasingly targeted the software that developers previously trusted.
Like human developers, coding agents routinely identify, download, recommend, and integrate third-party software packages. This introduces familiar software supply chain threats, including typosquatting, dependency confusion, and compromised packages, but at a speed and scale that can reduce opportunities for human review. The breadth of knowledge that coding agents bring to bear make it more likely for packages that human reviewers are unfamiliar with will be used in the solutions, in turn creating familiarity with using unfamiliar supply chain elements that would not have been selected by a human developer.
At the same time, coding agents rely on an entirely new class of dependencies. Modern agent frameworks are intentionally designed to be extensible through models,
Model Context Protocol (MCP) servers, external tools, and reusable skills. Unlike traditional software libraries, these components don't simply provide functionality. They introduce instructions, permissions, and capabilities that directly shape how an agent reasons, what it trusts, and what actions it performs.
In many cases, those instructions become part of the agent's core instructions, similar to how importing a software library becomes part of an application. A tool description, skill definition, or MCP server can introduce new behavior that the agent is expected to follow, making these components different from conventional software dependencies.
Many of these components also lack the maturity organizations have come to expect from traditional software supply chains.
Skills can be difficult to audit, marketplaces often expose only limited information about what they contain, and remote MCP servers can be updated or replaced without an organization's knowledge, changing agent behavior long after deployment. As HiddenLayer recently explored in our research on
AI skills, these characteristics create new opportunities for supply chain attacks that are difficult to detect using existing security practices.
Securing coding agents, therefore, requires organizations to think beyond software packages alone. They must also understand the provenance, integrity, and behavior of the growing ecosystem of models, tools, MCP servers, and skills that increasingly define how AI systems operate.
The way we build coding agents introduces new vulnerabilities
Many of the most significant attacks against coding agents aren't just caused by flaws in the underlying language model. Instead, they arise from the architectural decisions made in the harness that surrounds it.
Modern coding agents rarely rely on a static system prompt. Instead, they dynamically assemble their execution context from system prompts, prompt templates, tool descriptions, skill definitions, and other runtime components. Together, these elements determine how an agent interprets requests, what capabilities it has available, and ultimately what actions it performs.
That flexibility enables increasingly capable agents, but it also creates new opportunities for attackers. Many frameworks expose parts of an agent's workspace, including prompt templates, configuration files, and persistent memory, in locations that can be modified or influenced during normal operation, creating opportunities for self-modifying agent behavior. Instructions intended to guide the agent can become part of the attack surface themselves, providing a persistence mechanism for attacks.
The architecture also introduces challenges beyond prompt construction. Tools and skills often provide only limited visibility into the instructions they contribute, making them difficult to audit before deployment. Some harnesses simplify execution by routing many operations through a general-purpose shell, reducing visibility into what an agent is actually being asked to do and making it harder to enforce meaningful security boundaries. Researchers have also demonstrated that architectural features, such as control sequences, can be abused to alter agent behavior in unintended ways.
Individually, these issues may appear unrelated. Collectively, they point to a broader reality: many of today's coding agent frameworks were designed to maximize flexibility, extensibility, and developer experience, not to enforce strong security boundaries. As organizations deploy increasingly autonomous agents, securing the surrounding architecture becomes just as important as securing the underlying model.
Existing security approaches weren't built for this
Traditional security tools are designed to observe deterministic software. They can inspect the code an application executes, monitor network connections, and enforce policies around known processes and APIs. Those capabilities remain important, but coding agents introduce a different kind of visibility challenge.
An agent's behavior is shaped by far more than the code it executes. Every decision is influenced by a constantly changing collection of system prompts, user instructions, retrieved documentation, external websites, internal repositories, tools, MCP servers, skills, and other runtime context. Understanding
what an agent did is only part of the problem. Defenders also need to understand
why it did it.
That becomes increasingly difficult as agents combine information from sources with different levels of trust. An instruction originating from a user should not necessarily be treated the same as one retrieved from a public website. Internal documentation should not carry the same weight as an externally hosted code sample. Likewise, instructions introduced by tools, skills, or MCP servers often become part of an agent's execution context in ways that are difficult to observe or distinguish from higher-trust instructions.
Without visibility into where context originated and how it influenced an agent's decisions, organizations struggle to determine whether an agent is behaving as intended or responding to malicious influence. Securing coding agents, therefore, requires understanding the flow of information through the entire agent system and the trust relationships that shape its behavior.
Looking ahead
Coding agents will continue to reshape how software is built. As organizations pursue increasingly autonomous development environments, these systems will gain access to more tools, more context, and greater authority over critical engineering workflows.
That evolution promises enormous productivity gains, but it also transforms the security assumptions that have guided software development for decades. The risks no longer reside solely in the model. They emerge from the growing ecosystem of context, tools, skills, and the agentic harness that orchestrates how they all work together. And because that shift is driven by the harness rather than the code, the same risks appear wherever agentic harnesses operate, not only in coding.
Understanding the ecosystem and learning how to secure it will define the next generation of security for AI.