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.
What configuration poisoning looks like in practice
AI tool configuration poisoning is usually visible as a change in where the tool gets its behavior, not just in what the user typed. The clearest signals are unexpected config files appearing in shared locations, especially when they are created by a non-admin context and then start influencing an AI CLI or IDE session. When that file path becomes the control point, the tool can behave consistently differently across runs.
A second sign is process ancestry that does not fit the normal launch pattern. If an AI assistant suddenly spawns shells, script runners, package tools, or other children that are not part of the approved workflow, treat that as evidence the tool is following injected instructions or redirected settings. The important question is whether the runtime is honoring a trusted policy source or an untrusted file dropped into a writable location.
A third indicator is behavioral drift without an approved change record. If the same prompt, workspace, or session starts producing new tool calls, different network destinations, or altered output after a config file change you did not authorize, that suggests the configuration layer has been tampered with. For an overview of how poisoned instructions shift an AI tool’s behavior, see the Gemini CLI prompt injection flaw 2025 and the broader Agentic AI Security Guide.
Why the file path and process tree matter more than the prompt
Configuration poisoning works because many AI tools trust local files, inherited environment, or workspace-scoped settings before they fully validate intent. That makes the integrity of the configuration path part of the security boundary. If an attacker can write to the same location the tool reads at startup, they may not need to change the prompt at all. The tool can be made to act differently before the user notices anything unusual.
Watch for three mechanics together: a writable shared path, a configuration artifact that the user did not create, and a process tree that shows the AI tool launching follow-on actions. When those line up, the issue is not just a malformed setting, it is a control-plane problem. The tool has accepted runtime direction from a source that should not have authority over its behavior. The same pattern is discussed in the MCP Security Guide, where tool and configuration trust boundaries are central, and in OWASP Agentic Applications Top 10, which treats tool misuse and identity or privilege abuse as core failure modes.
Sessions that vary materially without an approved config change are especially important because they show persistence, not a one-off prompt anomaly. If the same user action produces different tool invocation chains, different file access, or different outbound connections, assume the configuration layer has been altered until proven otherwise. That is why change control, file integrity, and process telemetry are more useful than trying to infer intent from the output alone.
What usually separates a benign tweak from an active compromise
Benign tuning tends to be traceable, deliberate, and reversible. Poisoning usually is not. A legitimate config update is normally tied to a known owner, a known file path, and a known reason for change. Poisoning becomes more likely when the file appears in a shared or default location, the editor or CLI inherits it silently, and the resulting behavior expands the tool’s reach without user approval.
Unexpected child processes are also a strong separator. A harmless configuration change may alter formatting, model selection, or local preferences, but it should not create unexplained shells, downloaders, or script execution chains. If it does, the config is acting as an execution trigger. That is a materially different condition from a simple preference change, and it raises the need to inspect the file source, ownership, timestamps, and any surrounding automation.
For broader threat framing, the same class of abuse is consistent with poisoned instructions and malicious supply-chain content described in the TrapDoor supply chain campaign 2026 and the Shadow AI and AI Agent Discovery Guide, where unmanaged tools and hidden inputs create blind spots for defenders.
Risk and Threat Considerations
Configuration poisoning is dangerous because it turns a local convenience file into a durable trust bypass. Once an AI tool starts reading attacker-controlled settings, the compromise can persist across sessions, users, and even workspace resets until the shared path is cleaned up.
Failure mechanism: An attacker places or modifies a configuration file in a location the AI tool trusts at startup, causing the tool to inherit malicious behavior, spawn unexpected subprocesses, or change tool routing without an approved change.
Impact: The result can include secret exposure, unauthorized actions, poisoned outputs, lateral movement through developer tooling, and repeated compromise every time the tool starts.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Config poisoning can redirect tool behavior and abuse delegated runtime authority. |
| Recommendation — Bind tool actions to explicit authorization and review any unexpected privilege-bearing behavior. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Unexpected child processes indicate possible scripted execution launched through the AI tool. |
| T1562 — Impair Defenses | Poisoned configs may suppress or reroute normal safeguards around the tool. | |
| Recommendation — Hunt for spawned shells and scripts when AI tools create unusual subprocesses. Inspect configuration changes that weaken logging, validation, or approval controls. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Shared config paths and unexpected settings are a secure-configuration problem. |
| Recommendation — Baseline AI tool configuration files and alert on unauthorized modifications. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The question centers on unauthorized config changes driving altered behavior. |
| SI-4 — System Monitoring | Detection depends on spotting anomalous file creation and process behavior. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Investigators need logs to connect config changes with unexpected behavior. | |
| Recommendation — Require approval and traceability for configuration changes that affect AI tool runtime. Monitor AI tool file writes, process trees, and session drift for anomalous runtime changes. Correlate config writes with process launches and session changes during review. | ||
Practitioner Guidance
What to verify: Confirm the file owner, write path, and timestamp for every AI tool config that affects runtime behavior. If a non-admin account can create or modify a shared config that changes tool execution, treat that as a control failure rather than a normal customization.
What to measure: Track drift between approved configuration state and observed process behavior, especially child-process creation, new network destinations, and changes in tool invocation patterns. A stable session should not need hidden config changes to explain a new execution path.
Common mistake: Teams often inspect the prompt history and ignore the local configuration layer. For this problem, the stronger signal is provenance of the config file and the subprocess tree, not the content of the last user prompt.
Practitioner takeaway: If an AI tool is behaving differently, assume the trust boundary has shifted from the prompt to the configuration path until you can prove the file source, ownership, and execution lineage are clean.