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

Why the trust boundary changes when an agent creates child sessions

Child sessions are risky because they often inherit enough context to act, but not enough explicit scrutiny to prove that every action is intended. In agentic coding tools, that means a child session can read files, call tools, or continue a task under assumptions that were safe in the parent session but unsafe once the context has expanded or drifted.

That matters most when a parent agent delegates work to a subtask, a plugin, or a spawned execution context. The child may appear operationally convenient, yet it becomes a separate security boundary that can see secrets, repository state, or cloud credentials unless the tool deliberately narrows what is inherited and what must be re-approved.

The practical question is not whether the child session is “the same agent”, but whether it has the same trust justification. If it does not, the inherited permissions need to be treated as provisional, time-bound, and narrowly scoped rather than assumed to remain safe simply because they came from the parent.

Why hooks are especially dangerous when they execute automatically

Hooks create a different kind of risk because they can run without a fresh human decision at the moment they fire. That makes them attractive for automation, but also easy to abuse when an instruction, prompt, file change, or tool event triggers code that was never meant to have broad authority.

A hook can become a hidden execution path. If it can read the workspace, invoke a command, or reach an external service, then any compromise of its trigger conditions can turn into unintended execution with real side effects. The risk is not limited to malicious payloads; ordinary workflow logic can also become unsafe when the hook assumes the same trust level as the main agent.

For that reason, hooks should be designed as bounded event handlers, not as ambient extensions of the agent. Their authority should be explicit, their inputs should be predictable, and their actions should be easy to inspect after the fact.

How hidden instructions and inherited access turn convenience into exposure

Child sessions and hooks become most dangerous when hidden instructions can influence them before the main agent notices. A prompt injection, a poisoned repository file, or a manipulated tool output can steer a child context toward file access, code changes, or command execution that looks routine from the outside.

The security issue is amplified by inherited permissions. If the child session or hook can reuse tokens, mounted credentials, or broad filesystem access, then a small instruction can become a large blast radius. That is why the control problem is not only “what did the agent decide”, but also “what authority did the child inherit, and who can verify each action later?”

In practice, this is the same class of failure that appears whenever execution authority and trust boundary are allowed to drift apart. The safer pattern is to make each child session prove its need for access, rather than letting access follow automatically from the parent context.

Risk and Threat Considerations

Child sessions and hooks increase the chance that a low-visibility action path will bypass the intended guardrails. The main risk is privilege reuse across a boundary that the operator mentally treats as temporary, especially when the child can touch files, tools, or credentials that should have been re-authorised.

Failure mechanism: A hidden instruction, trigger, or plugin event steers a child session or hook into executing with inherited permissions, and the resulting action is not isolated by a separate approval step, scoped credential, or auditable execution trail.

Impact: Attackers or accidental misconfiguration can produce unauthorized tool use, secret exposure, repo tampering, or lateral movement inside the developer environment, while the resulting activity remains harder to attribute back to the exact child context that caused it.

Practitioner Guidance

What to verify: Treat each child session and hook as a separate execution path and confirm that it has its own authorization boundary, its own logging, and its own reversible access model. If you cannot tell which session invoked a tool or touched a file, the control is too weak to trust.

Decision rule: If a child session can access secrets, write to source control, or invoke external tooling, require explicit scope limits and a distinct audit trail before allowing it to run. If that cannot be enforced, keep the action in the parent session where approval is already visible and governed.

Practitioner takeaway: The core control is not to eliminate automation, but to ensure that every delegated or event-driven action remains bounded, attributable, and separately authorizable when its trust context changes.

Related resources from NHI Mgmt Group

• Agentic Coding
• Why do agentic coding tools create new security risk even when users approve commands?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do hidden skill fields create governance risk for agentic coding tools?