TL;DR: AI coding agents now assemble context from repositories, documentation, tools, MCP servers, and skills, which expands the attack surface beyond the underlying model and makes indirect prompt injection and supply chain abuse materially more dangerous, according to HiddenLayer research. The security problem is no longer model quality alone; it is trust, provenance, and execution control across the entire agent harness.
NHIMG editorial — based on content published by HiddenLayer: How Coding Agents Are Changing Application Risk
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI coding assistants that can execute commands?
A: Treat them as delegated non-human identities with bounded execution authority.
Q: Why do AI agents create accountability problems for IAM and NHI teams?
A: AI agents create accountability problems because traditional IAM proves who authenticated, while agent governance must prove what the actor did with that access.
Q: What breaks when prompt injection is not controlled in agentic workflows?
A: When prompt injection is not controlled, the agent can follow malicious instructions hidden in web content and perform actions the user never intended.
Practitioner guidance
- Define the agent harness as a governed asset Inventory every prompt template, tool, skill, MCP server, repository, and shell path that can influence agent decisions.
- Separate trusted context from actionable instruction Tag retrieved material by source trust and block low-trust inputs from directly shaping tool execution, code changes, or command invocation.
- Scope agent permissions to the smallest workable task Bind agent access to task-specific repositories, short-lived credentials, and restricted command surfaces.
What's in the full report
HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:
- Component-level analysis of how agent harnesses assemble prompts, tools, skills, and runtime context.
- Examples of architectural failure points, including exposed workspace elements and shell-mediated execution paths.
- Discussion of how the same harness risks extend beyond coding into other agentic workflows.
- Research framing on why traditional security tools struggle to explain why an agent acted, not just what it did.
👉 Read HiddenLayer's research on how coding agents are changing application risk →
AI coding agents and the harness risk teams are missing?
Explore further
AI coding agents are becoming governed execution environments, not just productivity features. The article’s core point is that the security unit of analysis has moved from the model to the harness, where prompts, tools, skills, and context sources combine into a runtime with real authority. That matters because the same design pattern is now spreading beyond coding into broader agentic workflows. Practitioners should therefore treat agent runtime governance as a first-class control domain, not an AI accessory.
A question worth separating out:
Q: What should organisations do when AI agent privileges change after deployment?
A: They should treat any new plugin, connector, or API integration as a change to the agent’s security posture and revalidate the effective capability set. If the new access exceeds the approved purpose, the agent should be restricted until the gap is reviewed and corrected.
👉 Read our full editorial: AI coding agents are widening application risk beyond the model