Untrusted Binary Resolution

Expanded Definition

Untrusted binary resolution is the failure to verify that an executable originated from a trusted location before it is launched. In practice, the risk appears when the operating system, launcher, or wrapper script resolves a command by searching local directories before protected system paths. On Windows, that can let a workspace-local binary impersonate a system tool; on other platforms, similar confusion can emerge through PATH manipulation, current-directory precedence, or unsafe launcher behaviour.

In NHI security, the issue matters because automation frequently runs with service account privileges, CI/CD credentials, or agentic execution authority. A malicious or unexpected binary can inherit those privileges without needing to steal the identity itself. The control objective is therefore not just "block malware" but make execution provenance explicit, especially where agents, build jobs, or operational scripts invoke tools by name rather than by absolute path. Guidance varies across vendors, but the core principle is consistent with NIST Cybersecurity Framework 2.0: verify what is allowed to run and where trust boundaries begin.

The most common misapplication is assuming a signed package or trusted repository prevents local binary hijacking, which occurs when execution still resolves through an unprotected search path.

Examples and Use Cases

Implementing untrusted binary resolution rigorously often introduces deployment friction, because teams must trade command convenience and legacy compatibility against tighter execution control and more explicit path management.

• A CI job calls a tool by name, and the runner executes a malicious copy placed in the workspace before the system binary.
• An admin script launched from a writable directory resolves git, python, or another utility from the current folder instead of a protected system path.
• An AI agent with tool access invokes a local helper executable without validating its location, allowing a tampered binary to inherit the agent’s permissions.
• A build pipeline downloads dependencies but does not pin executable paths, so an attacker with repository write access can stage a replacement binary for later execution.
• Endpoint hardening rules prevent searches in writable directories, aligning with the principle described in Ultimate Guide to NHIs — The NHI Market and the execution controls discussed in NIST Cybersecurity Framework 2.0.

This issue is also closely related to the broader NHI reality that automation is now massively overrepresented in enterprise identity estates, and NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises.

Why It Matters in NHI Security

Untrusted binary resolution turns ordinary file placement into code execution, which makes it especially dangerous in environments where service accounts and agents already possess elevated or persistent access. If a workflow launches a local executable before a trusted system binary, the attacker does not need to break authentication at all. They only need a writable directory, a predictable command name, and an execution context that was never constrained.

That matters because NHI controls often focus on secrets, rotation, and privilege scope, while this weakness sits one layer lower in the execution chain. A compromised CI runner, automation host, or agent workspace can become a launch point for lateral movement, credential theft, or destructive actions. In NHI operations, the failure mode is often discovered after an incident exposes how a legitimate identity was used to run untrusted code. The most direct lesson is that trust in the identity is not enough if the binary being executed was never trusted in the first place. Organisations typically encounter this consequence only after a build compromise or endpoint compromise, at which point untrusted binary resolution becomes operationally unavoidable to address.

For broader NHI risk context, NHI Mgmt Group reports in Ultimate Guide to NHIs that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

Related resources from NHI Mgmt Group

• What breaks when mobile banking apps treat device integrity as a binary control?
• What should teams do when an agentic browser must handle untrusted content?
• What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
• Who is accountable when untrusted project configuration changes what an AI assistant sees?