AI coding agents are widening application risk beyond the model

At a glance

What this is: This research argues that AI coding agents are changing application risk by shifting security attention from the model to the surrounding harness, tools, skills, and context sources.

Why it matters: IAM, NHI, PAM, and AI security teams need to treat agent tool access and context ingestion as governance problems because privileged actions can be influenced by untrusted external content.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read HiddenLayer's research on how coding agents are changing application risk

Context

AI coding agents have moved beyond autocomplete into systems that can plan tasks, inspect repositories, use tools, execute commands, and modify code with limited human oversight. That shift matters because the primary security problem is no longer just the LLM itself, but the agentic harness that decides what context it consumes and what actions it can take, especially where MCP, skills, and repository access are involved.

The governance gap is familiar to identity teams even if the technology is new. When an agent can accept external instructions, invoke privileged tools, and operate across multiple sources of truth, it starts to look less like a chat interface and more like a governed non-human identity with runtime authority. HiddenLayer’s analysis places the trust boundary where many programmes still do not: around context provenance, execution rights, and the boundaries between trusted and untrusted inputs.

Key questions

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. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.

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. When the system can act, forget, and continue later, the organisation needs evidence across the whole task lifecycle. Identity controls alone do not show whether the action was justified or repeatable.

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. That creates a direct path from ordinary page content to unauthorized execution, which bypasses normal access-control thinking.

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.

Technical breakdown

Why the agent harness is the real security boundary

Coding agents are not single models. They are execution systems that combine prompts, retrieval, tools, skills, repositories, and orchestration logic into one runtime. That design allows the agent to decide what to inspect, what to summarise, and what to execute, which means trust decisions are made continuously rather than once at login. The important security question is therefore not only what the model can say, but what the surrounding harness allows it to do with that output. Once tool calls and shell execution are in scope, the security model becomes a control problem, not a model-only problem.

Practical implication: Treat the harness as a governed runtime and inventory every tool, skill, and context source that can influence agent actions.

How indirect prompt injection alters agent decisions

Indirect prompt injection works by planting malicious instructions in content the agent is likely to retrieve, such as documentation, code comments, issue threads, or web pages. The attack does not need direct access to the agent prompt. Instead, it exploits the agent’s tendency to ingest external material as if it were useful context. In coding agents, that matters because the agent is designed to keep searching until it has enough information to act. If trust levels are not separated, untrusted content can shape privileged actions, code changes, or command execution through the back door.

Practical implication: Classify and weight retrieved content by trust level before it can influence tool use or repository changes.

Why MCP servers and skills create a supply chain inside the agent

Modern agent frameworks often rely on extensible components such as MCP servers, tools, and skills. These are not just functional add-ons. They can change behaviour, inject instructions, and expand what the agent is allowed to do. That makes them part of the supply chain for agentic systems, especially when remote components can be updated without clear operator visibility. HiddenLayer’s point is that the dependency model has changed. Security teams now need provenance, integrity, and change control for agent components, not just for application libraries.

Practical implication: Apply supplier review, change tracking, and permission scoping to agent components the same way you would for software dependencies.

Threat narrative

Attacker objective: The attacker wants to influence the agent’s runtime decisions so that privileged development actions occur under malicious guidance rather than trusted operator intent.

1. Entry occurs when malicious instructions are embedded in documentation, code examples, issue comments, or other retrievable content that the coding agent is likely to ingest.
2. Escalation happens when the agent treats that untrusted material as valid context and turns it into privileged tool use, shell execution, or repository modification.
3. Impact follows when the agent changes code, executes unsafe commands, or propagates compromised behaviour into the development workflow.

NHI Mgmt Group analysis

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.

Indirect prompt injection is the clearest example of trust collapse inside agentic systems. The attack succeeds because the agent is built to seek, merge, and act on outside information, while defenders still assume useful context is distinct from malicious instruction. This is not a simple content-safety issue. It is a provenance and trust-weighting problem that belongs in AI governance, NHI governance, and runtime authorisation review. The practitioner conclusion is to segregate what an agent can read from what it can obey.

AI agent components now form an internal supply chain, and that chain needs lifecycle control. MCP servers, skills, tools, and prompt templates can all alter behaviour after deployment, which makes them governance objects rather than static configuration. The article surfaces a named concept here: agent harness trust boundary, meaning the point at which untrusted context becomes actionable privilege. Security teams should control that boundary explicitly and continuously.

Identity governance must catch up to agentic authority before autonomous work becomes normal. When an agent can issue tool calls, access repositories, and change code, it behaves like a non-human identity with delegated capability and a changing trust profile. That creates a direct intersection with NHI governance, especially around entitlement scoping, approval models, and offboarding of component access. The practical conclusion is that agent identity and access policy should be designed before autonomy expands further.

The biggest failure mode is not a clever model jailbreak but unmanaged runtime flexibility. Frameworks that maximise extensibility often weaken visibility into what the agent actually consumed and why it acted. That makes detection and response harder because defenders must reconstruct both context lineage and action lineage. Practitioners should focus on the architecture that permits action, because that is where the real control gap sits.

What this signals

Agent harness trust boundary: the practical question for security teams is no longer whether an AI system can generate correct output, but where untrusted context becomes actionable privilege. That boundary should be treated like any other control point in IAM and PAM, with explicit policy, auditability, and revocation paths before agentic use spreads into broader operational workflows.

Teams should expect agentic platforms to inherit the same governance failures seen in secrets management, but at higher speed and with more complex execution paths. The operational lesson is to map context sources, tool permissions, and update paths to the same risk register used for NHI and privileged access, then enforce lifecycle review on each one.

The next planning step is to align agent governance with established external guidance such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026. That gives practitioners a vocabulary for access, provenance, and misuse that extends beyond model-centric AI safety.

For practitioners

• 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. Assign an owner, review cadence, and change-control path for each component so the runtime cannot expand silently.
• 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. Use explicit policy gates before untrusted context can influence privileged actions.
• Scope agent permissions to the smallest workable task Bind agent access to task-specific repositories, short-lived credentials, and restricted command surfaces. Remove general-purpose shell paths where possible, because broad execution access makes malicious context far more costly.
• Review MCP servers and skills as supply chain dependencies Track version, provenance, and update history for every remote component that can change agent behaviour. Do not allow unreviewed skill updates or remote replacements to alter production agent policy.
• Instrument context lineage and action lineage Log which sources influenced each decision and which tools were invoked as a result. That gives incident responders a way to distinguish malicious instruction ingestion from normal agent behaviour during investigation.

Key takeaways

• AI coding agents expand application risk from model behaviour into the harness, where tools, skills, and context sources can shape privileged action.
• Indirect prompt injection and component supply chain changes are governance failures because they turn untrusted context into executable authority.
• Practitioners should control agent access, provenance, and lifecycle the same way they manage non-human identity and privileged access.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• 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.
• Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
• 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.

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.

👉 HiddenLayer's full research covers the harness, supply chain, and trust-boundary detail behind agentic application risk.

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 connect identity controls to emerging runtime authority.