Code Execution Risks in LLM Tool Use

Code execution risks in LLM tool use arise when the text a model generates can change systems. A model may give a bad answer that connected tools may turn into an action. Meaningful defense therefore starts with the mechanisms that connect language to authority, then puts limits on what can execute regardless of what the model decides.

Why tool-use marks a qualitative shift in LLM risk

A passive code-completion tool produces a suggestion that a person must review and use. An agentic system can search repositories, invoke tools, run tests, edit files, and revise its work without stopping at each step. That difference moves the security boundary from an individual snippet to the whole workflow. The system is no longer only proposing work, because it can carry out the work itself.

As a result, an error can affect more than the quality of an answer. A model with access to databases, records, messages, or deployment tools can turn a manipulation attempt into a change in the outside world. Greater autonomy also makes intermediate actions less visible to human reviewers. Even successful completion of the task does not establish security, because code can work as intended while containing an exploitable weakness.

The semantic blind spot that makes tool-using LLMs attackable by design

Instructions and data both arrive as natural-language text. A model has no architectural mechanism that reliably separates an instruction it should follow from content it should merely examine. Its context may contain user input, retrieved documents, tool responses, system and developer instructions, and conversation history. Those sources have different authority, but all can influence the model’s reasoning. A malicious instruction inside a retrieved document can therefore be mistaken for a direction governing the task.

Helpfulness does not solve this ambiguity. Models are optimized to comply with requests. The Model Context Protocol (MCP), the main standard that links agents to external tools, spreads this problem by putting reasoning and control flows in the same semantic context. Traditional middleware frameworks such as REST or gRPC separate data transport, authentication, and execution. MCP’s shared context blurs those boundaries, so the protocol inherits and amplifies the model’s difficulty in telling content from authority.

Prompt injection: how malicious instructions travel through trusted content

Direct injection gives the model an overt instruction such as “ignore previous instructions”, making the attempt comparatively easy to spot. Indirect injection hides the directive in material the agent encounters while doing legitimate work, including documents, emails, and web pages. Careful assessment examines both the safety of the user’s request and whether the material retrieved to answer it is trying to redirect the agent. Content can be relevant to a task without being entitled to control it.

Unit 42’s research on AI code assistants found that indirect prompt injection can get through context attachment features. Attackers contaminate a public or third-party source with crafted prompts, which can hijack the assistant when a user supplies that material as context. The resulting risks include backdoor execution, malicious code insertion, and sensitive information leakage. GitHub Copilot CVE-2025-53773 showed this route to remote code execution through hidden prompts in source code files, repository content, GitHub issues, or web pages, earning a CVSS score of 7.8.

Improper output handling and excessive agency: how the model's response becomes the exploit

Injection is not the only way language can cross into execution. Improper output handling occurs when an application passes model output downstream without treating it as untrusted data. An unsafe response can lead to cross-site scripting when it is rendered, SQL injection through an auto-generated query, or code execution when it is passed to an execution system. These failures do not require malicious input, because a model can generate unsafe output while attempting the legitimate task. The downstream application creates the exploit path by trusting that output.

An agent that can issue refunds, change accounts, or run shell commands without enough limits can take actions that look authorized to the system but go against what the business intends. Broad tool permissions, weak runtime authorization checks, and limited input and output validation all widen that gap. The ability to write and execute Python scripts or shell commands is especially consequential because exploitation can reach the host system.

Flowise CVE-2025-59528 illustrates how code injection and over-privileged execution meet. Active exploitation reported in April 2026 affected more than 12,000 exposed instances over more than six months. The server had full Node.js runtime privileges, which let it use child_process to run commands and fs to access the file system. This was the third Flowise flaw with in-the-wild exploitation, following CVE-2025-8943 and CVE-2025-26319. The case places both the surrounding execution software and the model’s judgment inside the security boundary.

MCP and supply chain attack surfaces: how compromise enters before the model runs

That surrounding software can itself be compromised before a model evaluates any prompt. MCP brings context, metadata, and executable instructions into a shared semantic space without strong isolation. A poisoned server can exploit that ambiguity, while a compromised dependency can bypass model-level defenses entirely. Poisoned model files in open source repositories offer another way in because they can run arbitrary code when loaded.

The Deadbugz campaign in August 2026 spread a malicious MCP server named “productivity-suite” through public GitHub pull requests. After three ordinary tool calls, it changed its instructions and directed the agent to search for SSH keys, AWS credentials, shell history, and Kubernetes configuration while concealing the activity from the user. GTG-1002 in November 2025 showed a different use of the orchestration layer. Attackers connected Claude Code with MCP servers to coordinate open-source penetration testing tools, including network scanners, database exploitation frameworks, password crackers, and binary analysis suites. MCP served as a live command-and-control layer for real-time coordination and adaptive targeting.

A repository’s own Git configuration named a command that the agent ran on the developer’s machine, and four flaws remained unpatched at publication. Plugin4Shell, disclosed in September 2026, involved the same zero-click RCE vulnerability across Claude Code, Codex, GitHub Copilot, and Gemini CLI. AIR found the bug in May 2026 with working proof-of-concept exploits against all four agents. Anthropic patched Claude Code in version 2.1.179 and OpenAI patched Codex in version 0.146.0, while Microsoft had not shipped a fix for Copilot at publication.

Why attacks in agentic systems compound across steps in ways single-turn risks do not

These mechanisms become harder to contain when an agent chains actions together. A compromised retrieval step can corrupt a planning step, which then directs execution steps. The initial instruction need not remain the visible cause of each later action for its influence to propagate. With fewer human checkpoints, there is more room for the chain to run before someone intervenes. Securing a single component therefore does not establish the safety of the workflow.

Compounding also concerns permissions and time. A poisoned dependency or MCP server can use whatever authority the agent already has. Deadbugz changed its behavior after a delay, showing that a session that starts with what looks like ordinary activity can still become unsafe. At the same time, Anthropic’s forensic analysis of GTG-1002 found frequent hallucinated successes, so some claimed outcomes were not genuine compromises. That caveat limits conclusions about the attack’s achievements without removing the danger of propagated errors and real actions that appear authorized.

What the active debate about classifier-based defenses reveals about where protection actually holds

Classifier-based defenses look for malicious patterns in inputs or outputs. Structural defenses instead constrain what the agent can do, regardless of how the model interprets a request. The controls that held up under real-world attack were sandboxing, privilege separation, allow-listed egress, and human approval for destructive actions.

Human approval cuts into the throughput advantage that makes agents useful, sandboxing adds overhead, and limits on multi-agent interactions can make agents less efficient when they work together. Outside researchers’ challenge to Anthropic’s claimed GTG-1002 autonomy figures adds another reason to be precise about the threat model. Frequent hallucinated successes may mean that accounts of near-fully autonomous attacks overstate what those attacks can do today. The practical conclusion is not to discard detection or to assume unlimited attacker capability, but to make structural controls the baseline and classifier-based detection an additional layer.

Structural defenses that address the mechanisms rather than the symptoms

Least privilege directly addresses excessive agency by giving an agent only the permissions needed for its current task. Those permissions should be revoked or scoped down when the task ends. For systems that generate and execute code, strong isolation is a non-negotiable requirement because it limits the route from unsafe execution to host compromise. Docker containers are common, while microVMs such as Firecracker and Kata Containers are the recommended most effective method for untrusted code. Sandboxing addresses the escalation path illustrated by Flowise and Plugin4Shell without assuming the generated code is benign.

The semantic boundary needs its own controls because even when execution is restricted, some instructions may be untrustworthy. Approaches such as StruQ use separate input channels to keep prompt instructions apart from external data. Treating all context as untrusted by default also means treating every tool response as data to inspect. Prompt-level output filtering can detect injection patterns in tool responses before they enter context and supplements enforced separation. Tool inputs and outputs also need validation instead of implicit trust in model-mediated decisions.

Workflow controls then limit how far a mistaken or manipulated plan can travel. Human approval should be required for high-impact actions that are hard to undo, so routine automation can continue while the actions with the largest consequences stay under control. Invariant monitoring specifies behavioral constraints in advance and aborts execution when a plan violates them, before review after the event. MCP servers need explicit authentication, auditing, and enforcement independent of model output because they are privileged interfaces. Deadbugz’s delayed activation shows why these controls must work together from the start of a session through the whole execution.

Why continuous monitoring of vendor AI assets is the missing control for enterprises that didn't build the agent themselves

For enterprises using vendor AI, many of those controls sit outside their direct reach. The enterprise may not control the agent’s internals, tool permissions, or MCP connections, even though it bears the consequences of their use. A point-in-time vendor assessment cannot track every later change in that supply chain. Traditional security frameworks focus on discrete vulnerabilities in known codebases, while agentic incidents can also arise from how models interpret instructions, assemble context, and interact with tools. A static vulnerability-and-patch view therefore captures only part of the risk.

The disclosure history makes the vendor ecosystem central to this problem. Plugin4Shell affected four major coding agents simultaneously, while Deadbugz entered through public GitHub pull requests. Risk can arrive after deployment and after the assessment that justified adoption. Continuous monitoring of vendor AI assets fills that visibility gap rather than replacing the structural controls inside the agent.

Platforms that combine vendor risk assessment with real-time AI threat detection meet this need by checking AI assets across the vendor ecosystem and keeping watch over them. The aim is to surface emerging threats before they breach compliance or business continuity, a gap that generic governance frameworks and traditional TPRM tools miss. That monitoring must extend beyond the enterprise’s own perimeter to the vendor assets on which its workflows depend. The governing principle remains the same from model context to vendor oversight, which is that language must not become authority without independent controls.