Because the application treats the shared file as authoritative for every account on the machine. When event-driven hooks or notify commands are loaded from a path that standard users can modify, the resulting command runs under the victim’s context and can expose tokens, keys, and other session material.
Why writable defaults turn one local setting into a shared trust boundary
The problem is not simply that the setting exists, it is that the tool reads it as authoritative for every account using that machine. When a default file, hook path, or notify command is writable by a less-privileged user, the tool stops treating per-user intent as separate. That turns a convenience feature into a cross-user execution path.
In AI coding tools, this matters because the setting often controls code execution, command dispatch, or event handling rather than a passive preference. A writable default can therefore become a shared control plane, where one user can influence what another user’s session loads, runs, or trusts.
That same pattern shows up in AI Coding Agents Security Guide, which frames secrets in context, over-scoped tokens, and sandboxing as core issues for IDE and terminal agents. The underlying lesson is that defaults are security-relevant when they decide execution scope, not just user experience.
How writable hooks and notify commands become an execution problem
Event-driven hooks are high impact because they run automatically when a trigger fires. If the tool loads a hook script or notify command from a path standard users can edit, an attacker does not need to change the victim’s session directly. They only need to change what the victim’s session will later execute.
That creates a simple but dangerous sequence: modify the shared file, wait for the victim to use the tool, and let the tool invoke the attacker-controlled command in the victim’s context. In practice, that means the command can inherit the victim’s environment, open files, shell state, API tokens, and any other session material already available to the tool.
This is closely related to the failure mode described in Gemini CLI prompt injection flaw 2025, where hidden commands led to code execution and secret exposure. The specific trigger is different, but the control failure is the same: untrusted content is allowed to steer execution.
Why the risk expands from one user to the whole workstation
Cross-user risk appears when the tool treats a shared path as a single source of truth. A setting that is meant to be local and harmless becomes a way to influence another account’s workflow, especially on developer workstations, shared VMs, lab machines, or jump hosts. The attacker does not need elevated privileges if the default is already writable.
The impact is broader than one bad command. A malicious hook can exfiltrate credentials, alter build output, tamper with source files, or silently redirect the tool’s behavior during later sessions. If the tool is used for coding, the result can also include poisoned artifacts, unsafe package installation, or propagation into shared repositories.
That is why Human vs Non-Human Identity is a useful lens here: the machine account, tool process, and developer session are separate actors with different privileges, and the boundary between them must be explicit. Writable defaults blur those boundaries and make local trust assumptions easy to abuse.
Risk and Threat Considerations
Writable defaults create a low-friction privilege crossing. An attacker with ordinary local access can turn a configuration path into an execution primitive, then harvest whatever the victim session can reach, including tokens, keys, and source code.
Failure mechanism: The tool reads a shared or user-editable path as authoritative, so the attacker replaces a hook or notify command with content that runs automatically under the next user’s session.
Impact: The victim’s context can be used to expose secrets, alter builds, trigger unauthorized actions, or spread tampering across other developer workflows and repositories.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Writable defaults can expose shared execution paths and secret-bearing settings. |
| NHI-02 — Secret Leakage | The issue can expose tokens, keys and other session material under another user's context. | |
| Recommendation — Remove writable shared defaults from agent and tool execution paths. Restrict hook paths and prevent secrets from being exposed through shared tool settings. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | A shared writable setting lets one local user influence another user's authorized execution. |
| CM-6 — Configuration Settings | The question is about unsafe default settings that govern tool behavior and execution. | |
| IA-5 — Authenticator Management | The risk includes exposure of tokens, keys and session material through executed commands. | |
| Recommendation — Limit tool and file permissions so only the intended account can change executable settings. Harden default settings and review any configuration that can trigger commands. Protect and rotate exposed credentials whenever a tool setting can surface secrets. | ||
Practitioner Guidance
What to verify: Confirm that every hook, command, and default file used by the tool is owned by the intended account, not writable by other local users, and not resolved from an ambiguous shared location. If the tool supports per-user configuration, prefer it over machine-wide defaults for anything that can execute code.
Common mistake: Teams often harden the obvious secret stores but leave “just configuration” paths writable. For coding tools, that is enough for cross-user compromise because configuration can become execution.
Decision rule: If a setting can run commands, load scripts, or influence automated behavior, treat it like code, not preference. Lock down file permissions, separate users cleanly, and review any shared workstation baseline before allowing the tool to run with access to secrets or production credentials.
Practitioner takeaway: In AI coding tools, the real risk is not writable configuration by itself, it is writable configuration that the tool executes with someone else’s trust and credentials.