One writable folder can turn AI coding tools into cross-user access

At a glance

What this is: A writable Windows ProgramData path can let a standard user turn AI coding tool configuration into cross-user command execution.

Why it matters: IAM and endpoint teams need to treat AI coding tools as shared-privilege software because machine-wide defaults can become an access boundary bypass, not just a settings convenience.

Context

The security problem is not the AI model itself but the way desktop AI coding tools trust a machine-wide configuration path that standard users can modify. When a shared Windows directory becomes the source of default settings, the access boundary shifts from per-user intent to file-system control.

In this case, a writable ProgramData folder allowed a low-privileged user to drop configuration that executed commands in another user’s session, including an administrator’s. That is a cross-user governance failure for endpoint identity, because the application treats shared defaults as authoritative without proving ownership or integrity.

The article covers multiple Windows tools, but the core issue is the same trust pattern repeated across them: a privileged execution context consuming untrusted machine-wide configuration. That makes endpoint configuration governance and application trust validation part of identity security, not just desktop hardening.

Key questions

Q: What breaks when AI coding tools trust writable system-default folders?

A: A writable system-default folder lets a low-privileged user define configuration that later executes in other users’ sessions. The break is not only file integrity. It is cross-user trust leakage, because the application treats attacker-controlled state as authoritative machine policy. That can lead to code execution, persistence and privilege escalation on shared Windows endpoints.

Q: Why do writable default settings increase cross-user risk in AI coding tools?

A: 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.

Q: What are the signs that AI tool configuration poisoning is happening?

A: Look for non-administrative creation of vendor-specific configuration files in ProgramData, unexpected child processes spawned by AI CLI or IDE executables, and sessions that behave differently without an approved configuration change. Those signals show that runtime behaviour is being redirected through a shared file path rather than user intent.

Q: How should teams respond when an AI coding tool stores trust settings in ProgramData?

A: Treat the path as a privileged control surface, not a convenience folder. Restrict who can create vendor directories, pre-stage secure ACLs, remove administrative use where possible, and verify that logging captures both writes to the configuration file and any downstream shell execution.

Technical breakdown

Why world-writable ProgramData becomes a trust boundary failure

C:\ProgramData is intended for machine-wide settings, but Windows leaves portions of it writable to standard users unless administrators tighten the ACLs. If an application creates or consumes its own subdirectory there without restricting permissions, any user can plant files that the software later treats as trusted defaults. The security flaw is not the path alone. It is the combination of default write access, missing ownership checks, and application logic that loads the file as authoritative for all users on the host.

Practical implication: create and ACL-restrict application subdirectories at install time, and reject machine-wide configuration that a standard user can create or modify.

How event-triggered hooks turn configuration into command execution

The vulnerable tools expose hooks or notify-style actions that run shell commands when routine events occur, such as session start or an agent turn. Once a malicious configuration file is loaded, the application does not need a prompt or additional approval because the command is executed by design as part of normal workflow. That is why the issue becomes cross-user code execution instead of a harmless settings override. The file is not merely changing behaviour. It is redirecting built-in automation into attacker-chosen execution under the victim’s context.

Practical implication: treat event-driven command features as privileged execution surfaces and control them with integrity checks, not just user-facing settings.

Why shared defaults can bypass per-user safety controls

These tools apply system-wide configuration before or alongside user-specific settings, so a planted file in the shared path can affect every account that launches the application. In the worst case, one configuration also disables sandboxing and approval prompts, which compounds the impact from code execution into broader privilege exposure. The result is not simple persistence but a durable machine-level trust failure, because the same file keeps re-triggering whenever any user starts the tool.

Practical implication: monitor shared configuration writes and child-process creation together, because the dangerous condition is trusted defaults plus repeatable execution.

Threat narrative

Attacker objective: The attacker wants code execution inside higher-value user sessions on the same Windows host, with the ability to persist and harvest developer credentials.

1. Entry occurs when a low-privileged user creates the missing vendor directory under ProgramData and writes a malicious configuration file into it.
2. Credential or privilege abuse happens when the application loads that file as a trusted machine-wide default and executes the embedded hook or notify command.
3. Escalation follows when another user, including an administrator, launches the tool and the command runs inside that victim’s security context.
4. Impact is cross-user command execution with durable persistence, and the victim’s session can expose tokens, keys and other accessible developer credentials.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-user configuration trust is the real failure mode: these tools treated machine-wide defaults as trustworthy even when a standard user could create them. That assumption belongs to a world where shared configuration is controlled by administrators, not a world where user-writable directories are loaded as authoritative execution inputs. The implication is that desktop AI tooling now needs explicit trust validation for configuration provenance, not just functional settings handling.

Writable ProgramData created an identity boundary bypass: the application effectively let file-system write access decide which account could influence another account’s execution context. That is an identity control failure, not merely a local storage mistake, because authority over the configuration path became authority over runtime behaviour. Practitioners should read this as a broken mapping between file ownership and execution trust.

Host-based AI coding tools are converging with NHI-style risk patterns: once a tool can execute commands on behalf of any user and retain settings across sessions, it behaves like a privileged non-human executor on the endpoint. That brings the same governance questions seen in NHI programmes, including ownership, scope, monitoring and offboarding of machine-level trust paths. The practitioner conclusion is that endpoint AI tools need lifecycle governance, not ad hoc hardening.

Configuration poisoning is now a supply-side concern for identity governance: the attack surface is not only secrets and tokens but also the control files that determine how an agentic tool behaves on every launch. Where the vendor did not secure the path, the attacker controlled the policy. The implication is that identity teams and endpoint teams have to govern settings as security artefacts, because they can define privilege outcomes without ever presenting credentials.

Privilege escalation is easier when sandbox and approval controls live in the same trust domain as writable defaults: Codex CLI showed how one planted file could both trigger execution and weaken containment settings. That creates a compounding failure where trust in configuration undermines the very controls meant to limit damage. The practitioner conclusion is that execution policy and containment policy should not depend on the same modifiable file path.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Cloud PAM and CIEM Guide

What this signals

Configuration trust has become an endpoint identity issue: when an application reads machine-wide defaults from a writable directory, the file system is deciding privilege outcomes. That shifts AI tool governance into the same operational space as privileged access management, because execution authority can be redirected without a credential prompt.

Writable defaults create identity debt on shared hosts: the longer a vendor path remains user-writable, the more opportunity exists for repeated cross-user execution and quiet persistence. According to the State of Secrets in AppSec, only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

ProgramData hardening should be policy, not exception handling: if the secure path depends on every individual tool getting ACLs right, the control will remain inconsistent. Endpoint teams should standardise secure folder creation, monitor for configuration writes, and treat AI coding tools as shared-risk software rather than ordinary developer utilities.

For practitioners

• Inventory AI coding tools on Windows endpoints Identify where Claude Code, Cursor, Codex CLI, Google Gemini CLI and similar tools are installed, then classify which endpoints expose shared configuration paths.
• Pre-create and restrict shared configuration folders Use Group Policy or configuration management to create the relevant ProgramData subdirectories with tight ACLs so only SYSTEM and Administrators can write them.
• Alert on non-administrative writes to managed config files Monitor creation or modification of managed-settings.json, hooks.json, config.toml and system-defaults.json by standard users, then route those events to the SIEM.
• Remove administrative context from AI coding sessions Prevent developers from running these tools under administrative accounts and isolate access to production credentials and SSH keys from the host process.
• Validate detection of child-process spawning Test whether EDR and SIEM rules flag AI CLI or IDE processes that spawn shell commands from configuration rather than direct user action.

Key takeaways

• A writable shared configuration path can let a low-privileged user redirect AI coding tool execution into another user’s session.
• The exploit pattern works because the application trusts machine-wide defaults without proving that the configuration file belongs to an administrator-controlled path.
• Endpoint teams should harden shared folders, watch for unauthorized config writes, and keep AI coding tools out of administrative contexts.

Key terms

• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• Cross-User Code Execution: 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.
• ProgramData Trust Boundary: The ProgramData trust boundary is the security line that should separate administrator-controlled machine settings from user-controlled data on Windows. If an application consumes files from this location without enforcing restrictive ACLs and ownership checks, the boundary becomes writable by non-administrators and loses its protective value.
• Event-Triggered Command Execution: Event-triggered command execution is a design where software runs a shell command when a defined action occurs, such as session start or a prompt event. This is useful for automation, but it becomes dangerous when untrusted configuration can point that trigger at attacker-chosen code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.