Agentic coding agent controls fail when trust shifts at runtime

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Adversa AI's research: Recent agentic coding incidents show that runtime trust boundaries, not model quality alone, are the decisive failure point when tools can write configs, spawn child sessions or relay commands.

Why it matters: IAM and security teams need to govern agent authority as a moving trust boundary, because approval prompts, sandboxes and local settings do not reliably contain runtime misuse once execution shifts path.

Context

Agentic coding tools create a governance gap when the same runtime can read prompts, write configuration, spawn sessions and invoke external tools. Traditional control assumptions break when trust is not fixed at login or provisioning time but shifts from one action path to another inside the same workflow.

That matters because many organisations still treat model safety, IDE policy and repository trust as separate problems. In practice, the risk surface is the entire execution path, including child sessions, config files, MCP settings and gateways that can change what the agent is allowed to do without a new authorisation decision.

Agentic AI Security Guide offers the broader control lens for this class of behaviour, where the issue is not a single prompt but the sequence of runtime choices that define who or what the agent really trusts.

Key questions

Q: What should teams do first when a coding agent can reach local secrets or config files?

A: Start by removing the agent’s access to local secrets and config files, or isolating them behind a tighter execution path where the agent can read only what it needs. A coding agent with filesystem access can expose API keys, tokens, certificates, and environment files, so the first control is to narrow its runtime scope and revoke unnecessary read permissions before enabling tools.

Q: Why do child sessions and hooks create a security risk in agentic coding tools?

A: Child sessions and hooks can create a security risk because they run in a different trust context from the main agent, often with inherited permissions or automatic execution. That allows hidden instructions, tool calls, or file access to bypass the intended scope unless each session and hook has explicit authorisation, bounded credentials, and separate audit trails.

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: What is the difference between prompt injection and runtime trust abuse in coding agents?

A: Prompt injection is malicious input that tries to steer the agent’s behaviour, usually through prompts, files, or web content. Runtime trust abuse happens when the agent already has excessive authority and an attacker exploits that trust at execution time, such as through tool access, child processes, or over-broad secrets exposure. One attacks instructions, the other exploits delegated runtime privilege.

Technical breakdown

How agentic coding tools cross from model output into system action

Agentic coding tools are dangerous when the boundary between suggestion and execution is porous. A model may produce text, but the surrounding runtime decides whether that text becomes a shell command, a file write, a config edit or a network call. Once the toolchain allows the agent to act on local state, trust becomes contextual rather than fixed. That is why the same session can appear safe in the chat layer and still be unsafe in the shell or file system layer. The control problem is therefore about execution boundaries, not model accuracy alone. See the AI Coding Agents Security Guide.

Practical implication: Treat agent execution boundaries as security controls, not convenience features.

Why child sessions and hooks bypass parent guardrails

A parent session can enforce approvals, but a child session launched through a different path may inherit a different permission context. Hooks then become a hidden execution surface, because they can run at session start or workspace load before a human sees the full sequence. This is a classic trust divergence problem: the agent appears to be operating inside policy, while a subordinate path reaches outside it. The result is not simply prompt injection. It is a separate runtime route that never triggers the original confirmation logic. Read OWASP Agentic Applications Top 10.

Practical implication: Map every session-launch path and hook to the same approval policy.

Why config files and relays become privilege multipliers

Configuration files are not passive metadata when agents can read and rewrite them during execution. If an agent can alter its own MCP settings, base URL, sandbox flags or relay endpoint, it can change the trust boundary before the next action begins. That turns a simple configuration object into a privilege multiplier. In these incidents, the practical failure was not only unauthorised access to a file, but the ability to convert configuration state into operational authority without a separate governance decision.

Practical implication: Control agent-owned configs as high-risk identity artefacts.

Threat narrative

Attacker objective: The attacker wants to turn agent trust into execution authority, then use that authority to exfiltrate secrets, manipulate local state or run code without a visible approval event.

1. Entry began through trusted agent workflows that accepted malicious repository content, malicious URLs or compromised relay infrastructure as normal inputs.
2. Credential or authority exposure followed when the agent read local secrets, config files or shell context and used them as trusted material inside its own runtime.
3. Escalation occurred when the agent spawned child sessions, wrote to its own settings or executed commands through a path that bypassed the parent approval gate.
4. Impact was unauthorised command execution, secret disclosure or outbound data transfer to attacker-controlled infrastructure.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Runtime trust, not model safety, is the primary control problem in coding agents: these incidents show that the decisive boundary is where text becomes action. A safe prompt does not matter if the agent can write its own settings, launch a child session or execute through a relay that was never re-authorised. Practitioners need to treat agent execution paths as identity-bearing infrastructure, not just application behaviour.

Self-modifying agent config is a governance failure, not a convenience issue: when a coding agent can alter its own MCP settings, base URL or sandbox posture, policy no longer describes the runtime state. That is a direct break from the assumption that access decisions remain stable after provisioning. The lesson is that config files under agent control are part of the privileged surface, not ordinary developer prefs.

Session inheritance creates a hidden offboarding problem for agentic access: a parent approval model does not contain authority that can be reconstituted inside a child session, a new shell or a relay layer. This is why the control question shifts from what the agent may do to which execution path can reproduce authority without a new decision. That is a coding agent security problem, not a model-safety problem.

Escalation paths in agentic tooling now resemble identity chain abuse more than traditional prompt injection: the harmful action often arrives through nested runtime trust, not a single malicious instruction. That changes how security teams triage alerts, because the most important evidence is the path taken by the agent, not the payload alone. The practical conclusion is to govern session lineage, config provenance and tool invocation as one control plane.

Model-aware controls are necessary but insufficient because the runtime is the real adversary interface: the same agent can be safe in one mode and unsafe in another depending on where trust is granted. That means the programme must measure enforcement points outside the model, especially at session creation, config mutation and network egress. Identity governance for agents is becoming a runtime assurance discipline.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Runtime authority will become the central governance metric for coding agents: teams will need to measure not just whether an agent is allowed to act, but where that authority can be recreated through child sessions, config mutation or relays. The sharpest risk is a control stack that still assumes one stable human operator behind each action path.

Ephemeral session trust will replace static approval as the better design lens: once an agent can inherit, rewrite or replay authority mid-workflow, a one-time prompt is no longer a durable control. The next generation of governance will focus on issuance time, session lineage and what the agent can change about itself before the next decision.

October's incident pattern shows why review cadences alone will not catch agentic misuse: the attack surface moves faster than manual checks, and some of the most important failures happen in config, hooks or relay layers that scanners do not understand. That makes runtime telemetry, policy enforcement and trust-path analysis the practical baseline for agent programmes.

For practitioners

• Audit agent trust boundaries by path, not by product Map every place a coding agent can start, restart, spawn a child session, load hooks or inherit repository trust. Record where approvals are required today and where a different execution path can bypass them.
• Treat agent configuration as privileged state Inventory settings files, MCP definitions, sandbox flags, relay endpoints and environment variables that can change agent authority. Restrict who can edit them and alert on unexpected changes.
• Move enforcement outside the agent runtime Use network, identity and host controls that do not depend on the model or its own harness to behave correctly. If the agent can alter the guardrail, the guardrail is not a guardrail.
• Review download-and-execute workflows for hidden trust Block or scrutinise workflows that let agents run repository-provided instructions, open files from Downloads automatically or convert external content into shell execution without explicit review.
• Log the full action chain for every agent decision Capture the prompt source, tool call, session lineage, config mutations and outbound destination so you can reconstruct how authority moved across the runtime before impact.

Key takeaways

• Recent coding-agent incidents show that the real weakness is often the execution path around the model, not the model output itself.
• Child sessions, config writes and relay layers can recreate authority without a fresh human decision, which makes path-level governance essential.
• Practitioners should move controls to runtime boundaries, because prompt filtering alone will not contain self-modifying or session-spawning agent behaviour.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · OWASP Agentic Applications Top 10 · Agentic AI Security Guide · Top 10 Vibe Coding Security Risks

Key terms

• Agentic Coding Agent: An agentic coding agent is software that writes, edits, tests, and refactors code with limited human direction. In identity terms, it is an NHI that may use tools, repositories, and secrets, so governance must control its permissions, approvals, audit trail, and supply chain impact across development workflows.
• Session-start hook: A session-start hook is a command that runs automatically when an AI coding tool begins or resumes a session. In security terms, it is an execution boundary because it can act before a human approval loop has time to intervene, which makes the hook itself part of the trusted computing surface.
• MCP Configuration: MCP Configuration is the set of settings that tells an AI agent how to connect to Model Context Protocol tools, data sources, and permissions. It defines endpoints, authentication, allowed actions, and context boundaries. In practice, it governs how an agent discovers and uses external capabilities without exposing unnecessary data or control.
• Runtime Trust Boundary: A runtime trust boundary is the point where software must stop assuming trust and start verifying identity, context, and authorization before allowing action. In identity security, it separates approved execution from untrusted inputs, external services, or delegated agents, so access decisions can be enforced at the moment a workload or AI agent acts.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.