A condition where one user can influence commands that run in another user's session on the same host. It matters here because the malicious configuration file is loaded as a system default, so the attack affects whoever launches the tool, not just the original writer.
Expanded Definition
Cross-User Code Execution describes a local trust failure where a configuration, script, or command source written by one user is later loaded in another user’s session and executed with that later user’s privileges. In NHI and agentic AI environments, this is especially dangerous when tools auto-load defaults from shared paths, profile directories, or system-wide startup locations. The distinction matters: the exploit is not merely “user runs their own code,” but “one user’s input becomes another user’s execution context.” That makes it adjacent to misconfiguration, unsafe file precedence, and privilege boundary violations rather than classic remote code execution. Definitions vary across vendors, but the common security property is the same: untrusted user-controlled material crosses a session boundary and gains execution authority. For governance framing, map the risk to least privilege and explicit trust boundaries as described in NIST Cybersecurity Framework 2.0. The most common misapplication is treating the issue as a harmless per-user preference bug, which occurs when the same file or command source is implicitly reused by a different account or launcher.
Examples and Use Cases
Implementing protections against Cross-User Code Execution often introduces friction, because stricter loading rules can reduce convenience and break long-standing workflow defaults. Teams must weigh startup simplicity against the cost of verifying ownership, path precedence, and execution context.
- A shared shell profile contains an alias or function added by one user, and another user’s session sources it automatically during login.
- An AI coding assistant or CLI tool loads a project-local configuration file that was created by a different user and contains executable hooks. The Analysis of Claude Code Security shows why tool-bound execution paths deserve explicit scrutiny.
- A build runner or workstation opens a system-default script from a shared directory, allowing another user’s edits to shape the next session’s behavior.
- A developer trusts a command file in a collaborative repo without checking whether it is invoked under the current user’s identity or inherited from a previous session.
- A local helper utility processes a configuration file that should have been user-scoped, but instead is placed in a global location where every launcher inherits it. The Gemini CLI Breach — Silent Code Execution illustrates the stakes when silent execution paths are not constrained.
Why It Matters in NHI Security
Cross-User Code Execution becomes an NHI issue when service accounts, automation runners, developer tools, or agentic workflows inherit commands from files that were never meant to cross identity boundaries. That is a direct governance problem, because NHI compromise often begins with ordinary-looking local trust decisions: a shared config file, an unchecked startup hook, or a default path that loads before the operator notices. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes execution-by-default patterns especially hazardous when those files are reused across users or hosts. The control objective is to ensure that execution is bound to the correct identity, not merely to the presence of a file. This aligns with broader least-privilege and visibility expectations in NIST Cybersecurity Framework 2.0. Organisations typically encounter this consequence only after an audit, incident, or unexpected command execution reveals that another user’s configuration was being trusted all along, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers unsafe identity and execution trust boundaries for non-human workflows. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is directly undermined when another user's code runs in a session. |
| NIST Zero Trust (SP 800-207) | SC-7 | Cross-user execution is a trust-boundary failure that Zero Trust treats as unverified access. |
| NIST AI RMF | AI systems should be governed against unsafe autonomy and uncontrolled tool invocation. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can execute untrusted instructions through configuration and tool chaining. |
Bind tool execution to the correct NHI and block inherited commands from cross-user sources.
Related resources from NHI Mgmt Group
- When should organisations sandbox code execution in agentic platforms?
- What is the difference between prompt injection and LLM remote code execution?
- How should security teams harden user authentication without building custom auth code?
- Who is accountable when a workflow flaw exposes session secrets and code execution?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
