Prompt injection can turn AI tools into silent RCE backdoors

At a glance

What this is: This is a Cymulate analysis showing how prompt injection can escalate into silent remote code execution in AI developer tools through untrusted binary resolution and configuration poisoning.

Why it matters: It matters because AI tools that can write files or invoke local binaries can become an identity and access boundary problem, exposing credentials, host privileges and workflow trust assumptions to compromise.

By the numbers:

• AWS assigned CVE-2026-10591 with a severity score of 8.8 high for the Kiro issue.

👉 Read Cymulate's analysis of prompt injection leading to zero-click RCE in AI tools

Context

Prompt injection becomes a host compromise issue when an AI tool can write files, resolve local binaries, or trigger commands without explicit approval. In this case, the primary risk is not model hallucination but the security boundary between an AI agent-like tool and the operating system it can influence, especially where credentials, source code, and developer sessions live.

The identity angle is real because these tools often run with the user's privileges and can reach cloud profiles, SSH keys, API tokens, and workspace secrets. That makes the problem relevant to IAM, PAM and NHI governance even though the vulnerable component is a developer productivity tool rather than a traditional identity platform.

Key questions

Q: What breaks when an AI coding agent can write files that host tools later trust?

A: The sandbox boundary breaks in practice, even if the agent process itself never escapes. Host tools such as task runners, Git helpers, and IDE extensions may treat agent-created files as trusted configuration and execute them. The result is indirect code execution, which means the real control gap is trust in the artefact, not containment of the process.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: How do security teams know whether AI access is actually working safely?

A: Look for three signals: complete discovery of the AI estate, clear mapping of source data to each system, and logs that prove what was accessed and why. If any of those are missing, the control environment is incomplete. Safe AI access is evidenced, not assumed.

Q: Who is accountable when an AI assistant memory poisoning incident affects code or systems?

A: Accountability sits with the programme that owns the authenticated AI session, the browser controls, and the downstream execution environment. If those layers are separated across teams, the gap becomes a governance failure. Identity and platform owners need a shared control model for memory, sessions, and execution.

Technical breakdown

Prompt injection to local code execution in AI tools

The first mechanism is indirect instruction delivery. A malicious prompt hidden in a README, issue, forum reply or documentation page is consumed by the AI tool, which then performs a seemingly legitimate action such as writing a file or invoking a helper command. If the tool does not separate untrusted content from execution-sensitive actions, the model becomes a control plane for the attacker. The dangerous part is not the text itself but the tool permissions attached to it. In these products, the prompt is enough to reach file system and process execution primitives.

Practical implication: treat external content as hostile input and require explicit approval before any AI tool can write files or spawn processes.

Untrusted binary resolution on Windows

Windows executable search order can prioritize the current working directory before trusted system paths. If an AI tool or its bundled dependency resolves commands like git.exe or npx.exe without enforcing an absolute path, a workspace-local binary can be executed silently. That is binary hijacking, not a model-level issue. In this research, the attack works because the tool inherits a desktop operating model that assumes the current directory is benign, even when the directory is attacker-influenced. The result is host execution under the user's context with no obvious warning.

Practical implication: enforce absolute-path resolution and application allowlisting for every executable an AI tool may call.

Configuration poisoning through file-write permissions

The second class is configuration poisoning. Many AI tools can write files inside a project to help automate development tasks, but some execution-sensitive files are automatically consumed by the IDE or shell on reopen. If the tool can modify paths such as .vscode/tasks.json or settings.json without a separate approval step, it can plant commands that execute later as part of normal workspace loading. This is dangerous because the malicious write looks like ordinary productivity output, yet it persists beyond the original prompt and survives until the next workspace session.

Practical implication: block AI write access to execution-sensitive paths unless a human explicitly approves the change and its destination.

Threat narrative

Attacker objective: The attacker aims to turn normal AI-assisted work into unauthorized host execution that can expose credentials, persist access and extend into cloud or developer environments.

1. Entry occurs when an attacker places prompt injection content in a repository, web page, issue or other source the AI tool reads during normal use.
2. Credential or execution access follows when the tool accepts the malicious instruction and writes a binary or configuration file into the workspace without approval.
3. Impact occurs when the local binary runs or the poisoned configuration triggers command execution, giving the attacker silent code execution under the user's privileges.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection has moved from content safety into execution safety. The practical risk is no longer that a model says something wrong, but that an AI tool performs an OS-level action on hostile instruction. That shifts the control question from prompt hygiene to boundary enforcement around file writes, command execution and workspace trust. For NHI and IAM teams, this is the same governance problem seen with over-broad machine identities: a trusted runtime is given more authority than the input source deserves.

Configuration poisoning is the most underappreciated AI tool abuse path. When an assistant can create or alter files that the IDE, shell or build system later consumes automatically, the attacker has persistence without needing a separate implant. That is a distinct named concept, execution-sensitive path abuse, and it should be treated as a privileged action surface. The security failure is the assumption that file writes are harmless because they look like productivity work. Practitioners should classify those paths as high-risk control points.

Windows search order remains a supply chain for local execution. Workspace-local binaries can override trusted executables if tools resolve commands unsafely. That makes identity governance relevant because the resulting process inherits the user's cloud tokens, SSH material and developer entitlements. NHI programs that already track credential exposure should extend that discipline to AI-assisted execution paths, because a local binary can become the shortest route from prompt to privilege.

AI coding agents need the same lifecycle controls as other high-risk non-human actors. These tools are not just applications, they are decision-making systems with write and execute authority. That means ownership, approval, segmentation and revocation need to be explicit, not implied by developer convenience. The right control model combines NIST CSF access and protective functions with NIST SP 800-53 controls for execution and authenticator management, because the risk sits at the intersection of identity, endpoint and developer workflow governance.

The market is converging on runtime validation rather than static trust claims. Security teams are increasingly being asked to prove whether an AI tool can actually cross the boundary from instruction to execution. That validates the need for exposure testing, but it also raises the bar for procurement and internal approval. Teams should assume any AI tool that can write or run commands needs continuous validation, not a one-time trust decision.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For adjacent guidance, see 52 NHI Breaches Analysis for real-world root cause patterns behind identity-driven compromise.

What this signals

Execution-sensitive path abuse is the concept security teams should carry forward from this research. Once AI tools can write to files that later trigger code execution, the issue becomes governance of privileged write paths, not just model safety. That means endpoint policy, software allowlisting and identity controls have to be designed around the tool's real runtime authority, not its advertised use case.

The operational signal for practitioners is that AI assistant trust should now be revocable at the workspace level, not just at the application level. Teams should expect more attacks that hide in ordinary project files, then execute later when the workspace opens or a helper binary resolves incorrectly. Continuous validation matters here, and the strongest external reference point is the OWASP Agentic AI Top 10.

For identity programmes, the lesson is that human context and machine context are converging inside the same session. If an AI tool can act with a user's privileges, the organisation must know which actions require step-up controls, which require host isolation, and which should never be delegated to a tool at all. That is where AI governance meets IAM in practice, not theory.

For practitioners

• Restrict AI tool execution rights by default Allow AI CLIs and desktop assistants only on vetted endpoints, then block their ability to spawn processes or write to execution-sensitive locations unless a user explicitly approves the action.
• Enforce absolute-path binary resolution Review every toolchain dependency that calls git.exe, npx.exe or similar executables and ensure the resolved binary comes from trusted system paths, not the working directory.
• Protect configuration paths as privileged assets Treat .vscode/tasks.json, settings.json, shell startup files and scheduled-task locations as sensitive write targets, with separate approval and logging for any AI-generated change.
• Add prompt injection to threat modeling Classify repositories, issues, web pages and documentation consumed by AI tools as untrusted input sources, then test whether they can influence file writes, binary planting or command execution.
• Validate detection in SIEM and EDR Alert on AI tool processes that create child processes, write binaries, or modify execution-sensitive files, and correlate those events with unusual cloud credential use or workspace trust changes.

Key takeaways

• Prompt injection becomes materially worse when an AI tool can turn hostile instructions into file writes or local execution.
• The evidence shows that untrusted binary resolution and configuration poisoning can both lead to silent host compromise with user privileges.
• Practitioners need host-level approval, allowlisting and path controls around AI tools, not just prompt filtering or policy language.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.
• Untrusted Binary Resolution: Untrusted binary resolution occurs when software executes a local executable without proving that it came from a trusted path. On Windows, search-order behaviour can allow a workspace-local binary to override a system binary, creating a direct route from file placement to code execution.
• Execution-sensitive Path: An execution-sensitive path is any file location that can trigger commands, startup actions or privileged behaviour when modified. Examples include task definitions, shell startup files and IDE settings that are automatically read by the environment, making them high-value targets for abuse.

What's in the full report

Cymulate's full research covers the operational detail this post intentionally leaves for the source:

• Tool-by-tool attack chains for Cursor CLI, AWS Kiro, Codex Desktop App and Gemini CLI
• Proof-of-concept mechanics for binary planting, prompt injection and configuration poisoning
• Vendor response and remediation detail, including the AWS Kiro CVE-2026-10591 update
• Recommended validation scenarios for testing detection and response coverage in production-safe conditions

👉 Cymulate's full post covers the attack chains, vendor responses and validation scenarios in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in practical terms. It helps security practitioners connect identity controls to the broader runtime risks created by AI tools and automated workflows.