Name-based resolution lets the operating system choose the first matching executable in PATH, so a malicious file placed earlier in the search order can run as if it were trusted tooling. That breaks the assumption that the assistant only launches intended binaries and turns local write access into silent code execution.
Why name-based command resolution breaks the trust boundary
When an assistant launches tools by name, it relies on PATH order and whatever executable the operating system finds first. That means the decision is no longer “run the intended binary,” but “run the first binary with this name,” which is a different trust model. If local write access can place a lookalike command earlier in PATH, the assistant can be steered into executing attacker-controlled code without any visible error.
This is a software execution problem first, but it becomes a security problem because the assistant is acting with the user’s authority. In practice, the break is not just theoretical command confusion, it is loss of deterministic tool selection, which undermines sandbox assumptions, review expectations, and any policy that assumes the assistant only invokes approved binaries.
Where the attack surface comes from
The risk appears whenever an ai coding assistant runs in a workspace, shell, or automation context where PATH is inherited from the environment and writable locations are searched before trusted system directories. That can happen in developer laptops, ephemeral containers, CI jobs, or repositories that add local tooling directories. A malicious file named like a common utility, package manager, or helper script can be picked up as if it were legitimate.
Once that substitution happens, the fake command can read files, modify source, leak tokens, or pivot into other tooling the assistant is already allowed to use. The assistant does not need to be “fooled” by language alone, because the operating system has already made the wrong selection on its behalf.
For coding-assistant workflows, this is the same class of failure that makes trusted automation dangerous when the execution environment is not pinned. The AI Coding Agents Security Guide covers the broader pattern of keeping assistant execution bounded by sandboxing, secret hygiene, and restricted tool access.
How to prevent silent command substitution
The most reliable fix is to resolve security-sensitive commands by absolute path, not by bare name. That removes PATH ambiguity and forces the assistant to call a specific binary whose location and provenance you can verify. If a workflow must use shell resolution, the safer fallback is to constrain PATH to trusted directories and remove writable locations from the search order.
Validation should focus on the exact execution path, not just on whether the command name looks familiar. In reviews, check whether the assistant is allowed to invoke shell commands directly, whether the workspace can influence PATH, and whether wrapper scripts resolve their own dependencies with unqualified names. A single unsafe hop can reintroduce the problem even if the top-level launcher is pinned.
Keep this control close to the execution boundary. If the assistant runs in CI or a developer container, hard-code the command path in the launcher, lock down filesystem permissions on tool directories, and treat any environment that can rewrite PATH as part of the trusted computing base.
What the failure means for compromise detection
Because the substitution is silent, the first sign may be an unexpected subprocess, an unusual file change, or a command performing network or filesystem actions it should not need. That is especially important when the assistant has access to credentials, build pipelines, or deploy scripts, because a substituted executable can turn a simple tool call into lateral movement or secret exposure.
Detection is therefore about observing what actually executed, not what was requested. If your logs only capture the command string, you can miss the compromise. Capture the resolved executable path, parent process, and the surrounding environment whenever the assistant runs commands with meaningful authority.
Risk and Threat Considerations
Name-based resolution creates a classic execution-hijack condition: a local attacker or poisoned workspace can place a malicious executable earlier in PATH and inherit the assistant’s trust. The danger is highest when the assistant runs with developer credentials, access tokens, or deployment permissions, because the substituted binary can immediately act with those privileges.
Failure mechanism: The assistant asks for a command by name, the shell resolves the first matching executable in PATH, and a writable directory or repository-controlled location supplies the attacker’s version instead of the intended binary.
Impact: The attacker gains silent code execution under the assistant’s authority, which can lead to source tampering, secret theft, unauthorized network activity, or destructive actions in build and deployment environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Covers unsafe agent tool invocation and unintended command execution paths. |
| Recommendation — Constrain agent tool calls to approved executables and safe invocation paths. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Validates command inputs and launch parameters before execution to prevent substitution. |
| AC-6 — Least Privilege | Limits damage if a substituted command executes with fewer permissions. | |
| Recommendation — Validate command targets and parameters before execution. Restrict assistant execution rights to the minimum required. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Supports controlling execution environment settings like PATH and trusted binaries. |
| Recommendation — Lock down execution environment settings and approved tool locations. | ||
Practitioner Guidance
What to verify: Confirm that every high-trust assistant action resolves to an absolute binary path, not a PATH search, and verify that no writable directory appears ahead of trusted system locations for the assistant’s execution context.
Decision rule: If the assistant can reach production secrets, CI credentials, or release tooling, treat bare-name command execution as an unacceptable ambiguity and pin the executable path before allowing autonomous runs.
What practitioners underestimate: The problem is not only malicious PATH tampering, but also accidental shadowing by local dev tools, repo scripts, or environment bootstrap files that change the command selected at runtime.
Practitioner takeaway: Deterministic tool selection is a security control, not just a reliability preference, and assistants that can execute commands should be forced onto explicit paths whenever the command can change state or reach sensitive material.
Related resources from NHI Mgmt Group
- How should security teams govern AI coding assistants that can execute commands?
- How should security teams govern AI coding assistants that can run terminal commands?
- What breaks when allow-listed interpreters are available to AI coding assistants?
- What breaks when AI coding assistants can read .env secrets by default?