Securing coding agent harnesses means governing trust, not just models

At a glance

What this is: This research reframes coding agent security around the harness, showing that trust placed in prompts, tools, skills, MCP servers, and orchestration layers creates the main exposure.

Why it matters: It matters to IAM practitioners because coding agents behave like high-privilege non-human identities, so access scope, approvals, and runtime monitoring now need to extend to AI-driven execution paths.

👉 Read HiddenLayer's research on securing coding agent harnesses

Context

Coding agent security is increasingly a trust-boundary problem. The model may generate output, but the harness determines what the agent can read, invoke, modify, and execute. That makes the security question less about prompt quality and more about who or what is trusted to act on behalf of the system, which is directly relevant to identity governance, non-human identity control, and privileged access decisions.

The article's core point is that every tool, skill, MCP server, and orchestration step expands the attack surface. When those components are treated as implicitly trusted, coding agents can inherit authority they were never meant to have. For identity teams, this is the same control problem that appears with service accounts and workloads: access is not safe just because it is machine-operated.

Key questions

Q: How should security teams govern coding agents that can execute repository instructions?

A: Treat repository instruction files as executable input, not documentation. Review AGENTS.md and similar artefacts before unsupervised execution, scan them for shell commands and credential-path access, and enforce allow or block decisions outside the model. The control objective is to prevent untrusted repository content from becoming trusted pre-task execution.

Q: Why do coding agents make least privilege insufficient on its own?

A: Least privilege limits what an identity can reach, but it does not constrain how a coding agent chains legitimate actions into an unsafe outcome. An agent may read a file, call a tool, and send data outward without breaking any permission rule. That is why agentic governance must cover behaviour, sequencing, and intent.

Q: What breaks when tool metadata or remote integrations change after approval?

A: The original authorisation decision no longer matches the live environment. If a tool description, skill frontmatter, or remote MCP server changes after review, the agent may inherit new authority or different instructions without a fresh control decision. That creates governance drift, where the reviewed state and runtime state diverge.

Q: How can teams tell whether a coding agent is operating outside its intended boundary?

A: Watch for unexpected tool calls, abnormal file writes, unusual data movement, privilege escalation attempts, and elevated API or compute activity. Those signals show that the harness, not just the model, may be under influence. Effective monitoring should sit outside the model so it can independently confirm whether behavior matches policy.

Technical breakdown

Why the agent harness becomes the real attack surface

A coding agent is not just an LLM. It is a system that combines prompts, tools, skills, connectors, and runtime logic into a decision-and-action loop. That loop creates many trust boundaries, and attackers do not need to break the model itself if they can influence any trusted component around it. HiddenLayer's examples show how XML tags, metadata, and injected instructions can enter the harness and be treated as legitimate inputs. The architectural lesson is that agent security depends on validating every component that can alter execution, not only the model output.

Practical implication: inventory every component in the harness and treat each one as a separately governed trust boundary.

How MCP servers and skills inherit authority

Model Context Protocol servers and skills are especially risky because their definitions and metadata can be loaded into the system prompt or execution path before a user sees them. That means tool descriptions, parameters, frontmatter, and remote service state can shape behavior with system-level authority. If a remote MCP server changes after approval, the trust decision made earlier no longer matches the live dependency. This is a classic identity and authorization drift problem, but applied to AI execution: a trusted integration can silently become an untrusted one without any explicit regrant.

Practical implication: approve specific versions, revalidate remote integrations continuously, and restrict tool access to scoped, reviewed permissions.

Why runtime monitoring must sit outside the model

LLMs follow instructions, but they do not enforce security policy. That is why independent monitoring has to observe tool usage, file changes, sensitive data movement, privilege escalation attempts, and abnormal compute activity. The important distinction is between intent and effect. A prompt can look harmless while the resulting action chain is not. For AI systems that can execute commands or modify repositories, runtime telemetry is the only reliable control plane for proving whether the harness is behaving within its intended boundary.

Practical implication: place behavioral monitoring around the agent runtime and alert on tool use, data movement, and escalation patterns.

NHI Mgmt Group analysis

The harness is the identity layer for coding agents. Once an agent can invoke tools, change files, and reach external services, its security profile starts to resemble a non-human identity with delegated privileges. That means the real governance question is not whether the model is trusted, but which parts of the harness are authorized to act and under what conditions. IAM and PAM teams should treat agent harnesses as governed identities, not just application features.

Hidden trust relationships create governance debt. When prompts, metadata, and remote services are allowed to shape execution without explicit validation, organisations accumulate a trust model they cannot easily audit. That is a distinct control problem from ordinary software risk because the actor can change behavior dynamically. The lesson is to align AI governance with identity governance, especially where tool access and execution rights are effectively delegated to software systems.

Least privilege is necessary but not sufficient for coding agents. The article shows that compromise can enter through trusted components before a single privileged action is taken. A narrow permission set still fails if the agent is fed malicious tool definitions or if a remote integration changes after approval. Practitioners should think in terms of continuous trust validation, not static authorisation alone.

Named concept: harness trust drift. This is the gap between the trust state that was reviewed and the trust state that actually exists at runtime. It matters because coding agents can inherit new authority from changed tools, skills, or MCP servers without a fresh governance decision. Security teams should operationalise revalidation as a standing control, not an exception process.

Agentic AI security now depends on identity-style lifecycle controls. Ownership, review, approval, and revocation all need to exist for the agent ecosystem the same way they do for human and non-human identities. A coding agent that can act independently is not just software. It is an operational identity surface that must be scoped, monitored, and retired like any other high-risk credentialed actor.

What this signals

Coding agents are pushing IAM and PAM teams toward a broader control model in which software actors are reviewed like identities, not like static applications. The practical shift is from one-time approval to continuous revalidation of tools, skills, and remote services, because authority can change after deployment without a visible governance event.

The most important programme signal is that agent security now depends on the same lifecycle disciplines used for human and non-human identities. Ownership, access scope, monitoring, and revocation need to be explicit across the harness, or the enterprise will end up with delegated software privileges that no team can fully explain or defend.

For practitioners

• Map the full agent harness Create an inventory of every deployed agent, model, tool, MCP server, skill, and orchestration component, including shadow AI. Record what each component can reach, modify, or execute, and assign a business owner for each production instance.
• Constrain agent authority by default Apply least-privilege permissions, require human approval for high-impact actions, and restrict access to approved tools, MCP servers, and skills. Remove unnecessary outbound network access so a compromised agent has less room to pivot.
• Validate trusted components before use Red-team agents with adversarial inputs, review hidden metadata in skills and tools, and approve specific versions instead of trusting latest by default. Recheck remote MCP services whenever their configuration or ownership changes.
• Monitor runtime behavior independently Track sensitive data movement, tool usage, file operations, privilege escalation attempts, and abnormal API or compute activity outside the model. Use those signals to detect when the harness is behaving outside its intended boundary.
• Embed coding agents in governance workflows Add agentic systems to threat models, AI governance reviews, and incident response runbooks. Review permissions and trusted integrations on a fixed cadence so delegated software authority can be reduced or removed when its role changes.

Key takeaways

• Coding agent risk is really a trust-governance problem, because the harness determines what the system can do.
• When tools, skills, and MCP servers can change after approval, static access review is no longer enough to manage exposure.
• Teams need identity-style lifecycle controls, runtime monitoring, and least privilege to keep agentic execution inside policy.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Claim Trust Drift: Claim trust drift is the gap between where a token was issued and where it is later accepted without enough restriction. It happens when audience, issuer, or lifetime controls are too broad, allowing a valid cryptographic token to create invalid access across systems.

What's in the full report

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• Component-by-component breakdown of the agent harness attack surface, including prompts, tools, skills, and MCP servers.
• Examples of trust failures across XML tag abuse, metadata injection, and self-propagating prompt payloads.
• The five-layer security model in more depth, including the specific controls HiddenLayer associates with visibility, control, validation, monitoring, and governance.
• Runtime examples of how independent monitoring can detect sensitive data movement and privilege escalation patterns.

👉 HiddenLayer's full post covers the harness attack surface, five-layer model, and runtime control detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect delegated software access to identity controls they can actually operationalise.