In June 2024, researchers at JFrog disclosed CVE-2024-5565, a critical flaw in Vanna.ai, a popular text-to-SQL library used by dozens of downstream analytics products. The bug had nothing to do with a buffer overflow or a missing authentication check. Instead, an attacker could embed a malicious instruction inside a database column or a natural-language prompt, and the AI agent — designed to translate questions into SQL and then visualize the results using Python's Plotly library — would faithfully generate and execute attacker-controlled Python code on the host system. CVSS score: 8.8. No traditional exploit chain required, just words.
This is the shape of a new vulnerability class we call agentic unexpected code execution: cases where an AI agent's own code-generation or tool-use capability becomes the payload delivery mechanism. As coding assistants, data agents, and autonomous DevOps bots get wired directly into shells, interpreters, and CI pipelines, this class of bug is showing up faster than security teams can track it — and it's largely invisible to teams that only scan code for vulnerabilities in the traditional sense, since there's no bad line of code to find, only a bad instruction the agent decided to follow. Here's what it actually looks like, and what to do about it.
What Is Agentic Unexpected Code Execution?
Agentic unexpected code execution happens when an AI agent with code-execution privileges — a Python REPL, shell access, a SQL runner, a browser automation tool — is manipulated into running code its operator never intended, without any conventional memory-corruption or injection bug in the underlying software. The vulnerability lives in the reasoning layer: the model treats untrusted input (a support ticket, a web page, a file it was asked to summarize) as if it were a trusted instruction, and then acts on that instruction using a tool that can touch the filesystem, network, or OS.
The distinguishing feature is that the "exploit" is plain language, not shellcode. OWASP's Top 10 for LLM Applications (2024) formalized this as LLM01: Prompt Injection, and by 2025 the OWASP GenAI Security Project had split out a dedicated "Excessive Agency" category (LLM08) to cover exactly this: agents granted more functionality, permissions, or autonomy than a task requires, which then gets abused through indirect instructions the agent never should have trusted.
How Did the Vanna.ai Exploit Actually Work?
It worked by chaining a prompt injection into an unsandboxed exec() call. Vanna.ai's ask() function took a natural-language question, asked an LLM to produce SQL, ran that SQL, then asked the LLM to produce Plotly Python code to chart the results — and executed that generated code directly on the host with Python's exec(), with no sandboxing. JFrog's researchers showed that if an attacker could influence any text the LLM would see (a crafted question, or even data sitting in the target database), they could get the model to emit Python code that opened a reverse shell instead of a chart. Vanna's maintainers patched it by adding a runs_in_sandbox flag and warning users to isolate the visualization step — but by the time of disclosure, the pattern had already been copied into other "LLM writes code, LLM runs code" pipelines across the ecosystem.
Why Do Coding Agents Get Tricked Into Running Malicious Commands?
They get tricked because they're built to treat retrieved content as instructions, and attackers only need to plant text somewhere the agent will read it. Autonomous coding tools like GitHub Copilot Workspace, Cursor, and agentic CLI tools routinely ingest READMEs, issue comments, pull request descriptions, error messages, and web search results as part of their working context. Security researchers demonstrated throughout 2024 and 2025 that a hidden instruction inside a GitHub issue or a package's README — invisible to a human skimming the page, but perfectly legible to the model — could direct an agent to run curl | bash, exfiltrate environment variables, or modify CI configuration files on the agent's next turn. This is "indirect prompt injection": the attacker never talks to the model directly, they just leave a note somewhere the agent is guaranteed to read while doing its job. Because these agents are frequently granted shell or terminal tool access to be useful for real engineering work, the blast radius of a successful injection is a live command execution, not just a bad chat response.
What Other Real-World Incidents Show This Pattern?
Several, going back further than most teams realize. LangChain's CVE-2023-36258, patched in October 2023, allowed arbitrary code execution through its PALChain and Python REPL tool because generated code was passed straight to exec(); a related SSRF issue, CVE-2023-46229, let injected content force the framework's document loaders to fetch attacker-controlled URLs. OpenAI's ChatGPT Code Interpreter (now "Advanced Data Analysis") saw multiple 2023 disclosures where crafted files caused the sandboxed container to read or leak files outside the intended session scope. And in 2025, as the Model Context Protocol (MCP) became the default way to plug tools into agents, security researchers documented "tool poisoning" attacks where a malicious MCP server description — text a user never sees, but the agent parses as context — silently redirected file writes or command execution to attacker-chosen targets. The common thread across a Vanna.ai chart generator, a LangChain math chain, and an MCP tool server: whenever natural language output feeds directly into an execution primitive, the trust boundary collapses to "whatever text the model has seen recently."
How Is This Different From Traditional RCE Vulnerabilities?
It's different because the flaw is in intent, not in memory or syntax, which means classic scanners largely can't see it. A traditional remote code execution bug — say, a deserialization flaw or a format-string bug — exists in code that a static analyzer or fuzzer can inspect deterministically: the same input always produces the same vulnerable path. Tools built to scan code for vulnerabilities are excellent at catching that class of bug, but they have nothing to flag in a prompt-injection case, because the executing function is behaving exactly as designed. Agentic unexpected code execution is probabilistic and context-dependent: the same injected text might trigger malicious execution on one run and get ignored on another, depending on model version, temperature, or surrounding conversation state. There's frequently no CVE-worthy "patch the function" fix available, because the vulnerable function is doing exactly what it was designed to do — take instructions and act on them — the only defect is that it can't yet tell a legitimate instruction from a malicious one embedded in retrieved data. That's why OWASP, NIST's AI Risk Management Framework, and MITRE's ATLAS knowledge base all treat this as an architectural and governance problem, not a single-patch problem: it has to be mitigated with sandboxing, permissioning, and monitoring around the agent, not just inside it.
What Can Engineering Teams Do to Reduce Risk Right Now?
Start by treating every AI agent with tool access as if it were an internet-facing service, because functionally it is one. Concretely: run any agent-generated code in an isolated, network-restricted sandbox with no access to production credentials, secrets, or the host filesystem by default. Apply least privilege to every tool binding — a data-analysis agent does not need shell access, and a code-review agent does not need write access to CI configuration. Treat all retrieved content (web pages, file contents, issue text, third-party API responses) as untrusted input requiring the same scrutiny as user-submitted form data, and add explicit approval gates before an agent executes anything with side effects — file writes, network calls, package installs, or shell commands. Log and diff every action an agent takes against source control, so unexpected commits or config changes surface immediately rather than at the next audit. None of this eliminates the risk, because the underlying issue is a reasoning-layer weakness that will persist as long as models can't perfectly separate instructions from data — but it collapses the blast radius from "full host compromise" to "contained, observable, reversible."
How Safeguard Helps
Safeguard was built for exactly this shift: securing software supply chains that now include AI agents as first-class actors, not just human developers and CI runners. We give engineering and security teams visibility into every tool-calling agent operating in their pipelines — what permissions it holds, what it's allowed to execute, and what it actually did — so that indirect prompt injection and excessive-agency issues like the Vanna.ai and LangChain cases above get caught before they reach production. Our platform continuously maps agentic workflows against the same dependency, provenance, and integrity checks we apply to traditional software supply chains, flags overly permissive tool bindings (shell, exec, network egress) before they ship, and alerts on anomalous agent behavior in real time rather than after a post-incident forensic review. As agentic coding assistants and autonomous pipelines become standard infrastructure, Safeguard's goal is to make sure the trust you extend to an AI agent is as auditable, scoped, and monitored as the trust you extend to any other privileged system in your stack. If your team is deploying agents with code-execution tools, talk to us about a supply chain risk assessment before your next release.