AI coding agents are widening application risk beyond the model

At a glance

What this is: NHI Mgmt Group's analysis, drawing on HiddenLayer's research: AI coding agents are broadening application risk by pulling context, instructions, and capabilities from a much larger execution environment than the model itself.

Why it matters: For security, IAM, and AI governance teams, this shifts the problem from model-only review to controlling provenance, permissions, and execution paths across the whole agent harness.

Context

AI coding agents are software systems that can plan tasks, call tools, retrieve context, and act on code or infrastructure with limited human intervention. That makes them different from ordinary chatbots because they do work, not just generate text. The security implication is that the attack surface now includes the full harness around the model, including repositories, documentation, tools, skills, and execution logic.

This matters for identity and governance because the agent’s authority is not abstract. It is expressed through credentials, access to repositories, tool permissions, and delegated execution paths that can be influenced by untrusted context. Once an agent can fetch external instructions and then act on them, the governance question becomes who controls the inputs, the permissions, and the runtime boundaries, not just which model is in use.

Key questions

Q: What breaks when an AI agent can run code on untrusted ciphertext and then act on the result?

A: The core failure is that the agent starts trusting its own runtime output more than the original untrusted input. That lets attacker instructions bypass static filters, because the payload is hidden until after decryption. If the same context also has network access or write permissions, the failure can escalate into data theft, unwanted content generation, or unsafe tool execution.

Q: Why do coding agents create higher risk than chatbots or copilots?

A: Coding agents create higher risk because they do work, not just answer questions. They can retrieve context, invoke tools, run commands, and change repositories, which means a malicious instruction can influence real execution instead of simply corrupting a response. The risk is operational, not just conversational.

Q: How can security teams tell whether an agent is being influenced by hostile input?

A: Look for context provenance gaps, especially when external documentation, public web pages, or issue comments shape a privileged action without clear trust tagging. If you cannot trace which source influenced a command, code change, or tool call, you do not have enough visibility to distinguish normal automation from injected influence.

Q: Should organisations treat MCP servers as part of the identity control plane?

A: Yes. An MCP server that brokers access to secrets, models, or downstream services is effectively making authorisation decisions on behalf of machine workloads. That makes its retrieval policy, identity trust chain, and audit trail part of identity governance. If those controls are weak, the server becomes a privileged access path rather than a neutral integration layer.

Technical breakdown

Why the agent harness is the real trust boundary

A coding agent is an orchestration layer, not just a language model. The harness decides what context is loaded, which tools are callable, how outputs become actions, and which repositories or services are in scope. That means the security boundary sits around the workflow, not inside the model. Once the harness can dynamically assemble prompts, pull documentation, and invoke commands, the system inherits trust relationships from every source it touches. Traditional model safety testing does not capture this because the risk comes from runtime composition, not static model behaviour.

Practical implication: Treat the harness as a governed execution environment and constrain which tools, sources, and credentials it can combine at runtime.

How indirect prompt injection becomes an execution risk

Indirect prompt injection works when an adversary hides instructions in content the agent is likely to retrieve, such as documentation, issue comments, code samples, or websites. The agent then treats that hostile content as part of the reasoning context and may act on it because its design rewards helpfulness and retrieval. The key problem is not that the model is foolish, but that the harness cannot reliably distinguish trusted instructions from attacker-controlled ones once they are merged into the same workflow. This is especially dangerous when the agent can also execute terminal commands or modify source code.

Practical implication: Separate retrieval from action and require explicit trust controls before retrieved content can influence privileged operations.

Why AI supply chain risk now includes MCP servers and skills

Coding agents depend on extensible components such as MCP servers, tools, and reusable skills that do more than provide functionality. They introduce instructions, permissions, and behaviour that can shape what the agent trusts and how it acts. That creates a supply chain problem that is closer to delegated authority than to ordinary package management. Remote components may change without visibility, skill content may be hard to audit, and tool descriptions can effectively become part of the agent’s operating logic. In NHI terms, these components behave like machine identities with behaviour-bearing privileges.

Practical implication: Inventory, review, and continuously validate MCP servers and skills as governed dependencies with explicit ownership and change control.

Threat narrative

Attacker objective: The attacker aims to turn the agent’s delegated authority into unauthorized code, configuration, or infrastructure changes.

1. Entry occurs when the agent retrieves untrusted external context, such as documentation, issue comments, or websites containing hidden instructions.
2. Credential or authority abuse follows when the harness treats those instructions as equivalent to trusted guidance and allows the agent to use tools or shell access.
3. Escalation happens when the agent combines retrieved context with repository access, execution rights, or extensible skills to make privileged changes.
4. Impact is code, configuration, or infrastructure alteration under attacker influence, even though the model itself was never directly compromised.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

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

The decisive control problem is no longer model safety, but runtime trust composition. Coding agents combine user intent, retrieved content, tool output, and repository context into a single decision path, which means the security outcome depends on provenance and authority at every step. That is a different governance problem from testing an LLM in isolation. Practitioners should treat the harness as a control plane for delegated execution, not a harmless wrapper around a model.

AI coding agents create a new class of machine identity exposure. When skills, MCP servers, and tools carry implicit permissions or behavioural instructions, they begin to function like non-human identities with embedded authority. That is where IAM and NHI governance meet agentic AI security. The important question is not whether the agent is smart enough, but whether its delegated access can be bounded, attributed, and revoked with the same discipline used for other privileged machine actors.

HiddenLayer's article sharpens a useful concept: harness risk. This is the gap between what an agent can retrieve and what it should be allowed to do with that retrieval. The term is useful because it captures provenance, permission, and execution in one frame. Security teams should use it to avoid over-focusing on prompt content while missing the orchestration layer that turns context into action.

Software supply chain controls now need to extend into agent behaviour supply chains. Package verification alone does not address component types that ship instructions and permissions as part of their function. Remote MCP servers, skills, and prompt templates can alter agent behaviour after deployment, which means provenance and change detection must reach beyond code artefacts. Practitioners should assume the most dangerous dependency may be the one that changes the agent's decision model, not its binaries.

From our research library:

• Developers using GenAI tools like GitHub Copilot are reporting 35% productivity gains, according to IDC’s 2024 Generative AI Study.
• Read next: Threat Modelling AI Agents

What this signals

Harness risk will become a standard governance term for AI teams. The useful question is no longer whether an agent uses a model safely, but whether its harness can keep untrusted retrieval from becoming privileged execution. Teams that already manage secrets, repository permissions, and runtime approvals will be better positioned than teams focused only on prompt engineering. Use this as a design cue to extend governance from model policy into execution control.

Agentic systems are starting to resemble non-human identities with mutable authority. That is the point where IAM, PAM, and AI governance converge, because delegated access now includes tools, skills, and orchestrated workflows, not just static tokens. The governance model has to account for behaviour-bearing components that can change over time without a user explicitly reauthorising each action. Practitioners should assume agent authority must be inventoried, bounded, and revocable like any other privileged machine actor.

For practitioners

• Constrain the agent harness as a privileged execution boundary Limit which repositories, tools, shell commands, and network destinations an agent can combine in a single task, and require explicit policy for each privileged workflow.
• Separate untrusted retrieval from privileged action Tag external documentation, issue content, and web pages as low-trust inputs until a policy engine or human review approves their use in command execution or code changes.
• Inventory MCP servers and skills as governed dependencies Track ownership, versioning, update rights, and removal paths for every remote tool, skill, and MCP server that contributes instructions or capabilities to an agent.
• Review delegated credentials used by coding agents Map every token, repository grant, and automation secret the agent can reach, then reduce scope to the minimum permissions needed for the task.
• Add observability for agent decision provenance Log where context came from, which tools were invoked, and why a given action was taken so investigations can distinguish trusted input from injected influence.

Key takeaways

• AI coding agents shift security risk from the model itself to the harness, tools, context sources, and permissions that enable runtime action.
• Indirect prompt injection and supply chain abuse are more dangerous when agents can retrieve content and immediately convert it into privileged execution.
• Governance needs to move from prompt review to provenance control, permission scoping, and observability across the full agent workflow.

Key terms

• Coding Harness: A coding harness is the working environment where a developer and an AI agent explore ideas, write code, review changes, and run checks in one continuous session. Security teams care about it because it becomes a live control surface, not just a productivity tool.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Agentic Supply Chain: The collection of models, tools, plugins, prompts, memory stores, and middleware that an AI agent depends on to operate. Weaknesses in this chain can introduce hidden instructions, poisoned context, or exposed secrets, so security teams need inventory, trust validation, and isolation controls across the entire path.
• Harness Risk: Harness risk is the security exposure created by the gap between what an agent can retrieve and what it should be allowed to do with that retrieval. It captures provenance, trust, and execution control in one operational concept, which is why it matters for AI governance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to govern delegated access as AI systems begin to act like privileged machine actors.