A Security Framework for Coding Agents and their Harnesses

In our previous post, we introduced the concept of the agent harness, the ecosystem of prompts, tools, skills, MCP servers, and orchestration logic surrounding the language model in modern coding agents. We argued that this harness, not just the foundational model itself, has become the primary coding agent attack surface.

That distinction matters because coding agents don't operate in isolation. Coding agents are AI systems that can read code, invoke tools, modify files, execute commands, and complete software development tasks with varying levels of autonomy. They read repositories, invoke tools, call external services, execute commands, and exchange information with systems that sit well beyond the model itself. Every one of those interactions creates a new trust relationship, and every trust relationship introduces another opportunity for attackers.

Securing coding agents, therefore, requires a broader security model, one that protects the entire agent ecosystem rather than treating the language model as the only thing worth defending.

The Agent Harness Is the Attack Surface

Many of the attacks emerging against coding agents appear very different on the surface. Some abuse prompt formatting. Others compromise tools, manipulate skills, or exploit runtime behavior. Each attack exploits a different layer of the harness, but they all stem from misplaced trust.

HiddenLayer's research on Cursor demonstrated how trust could be established through something as simple as XML tags. By wrapping malicious instructions within a trusted <user_query> tag, an attacker could cause the agent to interpret them as legitimate user input without relying on traditional prompt-injection techniques.

MCP introduces a different trust challenge. Tool definitions are frequently incorporated directly into the system prompt, allowing malicious instructions hidden within descriptions or parameters to inherit system-level authority. At the same time, remote MCP servers can change after permissions have already been granted, creating opportunities for trusted integrations to quietly become untrusted ones.

Skills present similar risks. Metadata stored within YAML frontmatter is often loaded into the system prompt before a skill's executable logic ever runs. Hidden permissions, trigger conditions, or model configuration changes can influence agent behavior without appearing in the portions of a skill that users or marketplaces typically review.

Even prompt injection has evolved beyond isolated conversations. HiddenLayer's CopyPasta research demonstrated how malicious instructions disguised as a required license header could convince coding agents to copy the payload into every repository they modified. Instead of affecting a single interaction, the prompt injection became self-propagating.

Although these attacks target different components, they all exploit the trust relationships established throughout the agent harness. Every prompt, tool, skill, MCP server, and orchestration layer becomes another point where trust must be established, validated, and continuously monitored. Securing coding agents, therefore, requires a security model that accounts for every layer influencing agent behavior.

A Security Model Built for Coding Agents

Traditional application security assumes software behaves deterministically. Coding agents do not.

Their behavior emerges from interactions between the model, the harness, external tools, and runtime context. Protecting those systems requires security controls that extend across the entire agent lifecycle, from deployment through execution.

At HiddenLayer, we think about that challenge through five complementary layers.

1. Visibility: Understand Every Trust Relationship

You can't secure relationships you can't see. Every recent coding agent attack has relied on an unseen trust boundary, whether that was Cursor trusting XML tags, CopyPasta spreading between repositories, or compromised tools inheriting authority through MCP.

Organizations need continuous visibility into every component participating in agent execution.

That includes:

• Every deployed agent, model, harness, tool, MCP server, and skill, including shadow AI.
• The permissions granted to each agent and the systems it can reach.
• The provenance and integrity of tools, skills, and external services.
• Runtime interactions between agents, tools, repositories, and external systems.

Visibility means actually understanding how trust flows through the environment.

2. Control: Limit the Impact of Compromise

Coding agents are designed to take action. Whether an agent has been manipulated through prompt injection, a compromised MCP server, or a malicious skill, the outcome is ultimately determined by what that agent is allowed to do.

Strong controls reduce the consequences of compromise by limiting unnecessary authority.

Organizations should:

• Apply least-privilege permissions by default.
• Require human approval for high-impact actions.
• Restrict access to approved tools, MCP servers, and skills.
• Limit unnecessary outbound network access.
• Review system prompts and default configurations before deployment.

The objective is that even if trust fails, the impact remains contained.

3. Validation: Trust Components, Not Assumptions

Many attacks succeed before an agent ever executes its first command. Malicious skills hide instructions within metadata. Supply chain attacks target trusted dependencies. Remote services evolve after approval. Every component that influences agent behavior should therefore be validated before it becomes trusted.

Organizations should:

• Red-team agents using adversarial inputs before deployment.
• Validate proposed actions before execution.
• Review third-party tools and skills, including hidden metadata.
• Approve specific versions rather than continuously trusting "latest."

Trust should be deliberately established, not automatically inherited.

4. Monitoring: Security Must Exist Outside the Model

Language models are designed to follow instructions, not enforce security policy. That makes independent runtime monitoring essential.

Recent incidents continue to reinforce this lesson. HiddenLayer's research has shown how malicious instructions can move through trusted workflows, while the OpenAI model evaluation incident demonstrated how unexpected behavior can emerge inside otherwise legitimate environments.

Effective monitoring focuses on behavior rather than prompts alone.

Organizations should continuously observe:

• Sensitive data movement.
• Tool usage and file operations.
• Privilege escalation attempts.
• Shadow AI activity.
• API usage and abnormal compute consumption.

Runtime monitoring provides independent oversight when the model itself cannot.

5. Governance: Security Requires Ownership

Technology alone cannot secure coding agents. Organizations need clear ownership, operational processes, and accountability that evolve alongside agent capabilities.

That includes:

• Assigning ownership for every production agent.
• Including coding agents within existing threat models and AI governance programs.
• Developing incident response procedures specific to agentic AI.
• Regularly reviewing permissions and trusted integrations.

Governance ensures security remains an ongoing practice rather than a one-time deployment exercise.

Looking Ahead

Coding agents are changing how software is built. They're also changing what it means to secure software.

The primary challenge is no longer protecting a language model from malicious prompts. It is understanding and defending the network of trust relationships that allows an autonomous system to read code, invoke tools, modify files, and interact with production environments.

As organizations accelerate AI-assisted development, the most resilient security strategies will focus on the entire agent harness. Visibility, control, validation, monitoring, and governance together provide a practical foundation for securing coding agents as they continue to evolve.