When Prompt Injection Becomes Code Execution

New research found attack chains from a text injection to RCE across seven AI platforms. OWASP 2026 says the pattern has a name.

A researcher at Endor Labs started with a simple question: could a prompt injection against an AI agent become a path to executing code on the underlying system? Across seven AI orchestration platforms, the answer was yes.

Peyton Kennedy uncovered 14 critical and high-severity vulnerabilities in platforms including Flowise, Langflow, Dify, Activepieces, and Apache Airflow. The research, presented at DEF CON 34, found complete attack chains: an unauthenticated user injects a malicious instruction into content the agent reads, and the agent, acting on that instruction with its real permissions, executes code on the server or exfiltrates data.

Not theoretical. Not edge-case. Present in production tooling used by small teams.

The Architecture Problem Behind the Finding

The issue is not a missing input sanitization check in one place. It is structural.

These platforms were built when AI agents were mostly developer tools, running in a controlled environment with a human watching closely. Their security model reflects that origin. As they gained more capabilities, the permissions expanded without the security assumptions catching up.

Prompt injection works by feeding the model text that overrides or hijacks its instructions. When the agent has access to a database, an internal API, or a code execution context, those injected instructions can reach all of it. The payload does not need to arrive at your server directly. It arrives as text. The agent carries it inward.

Any external content the agent reads is a potential injection surface: emails, documents, API responses, web pages, user-supplied data. If the agent processes it and has real permissions downstream, the surface is real.

OWASP 2026 Names the Pattern

The timing matters. The OWASP Top 10 for LLM Applications 2026 was released this month. Prompt injection remains number one. But the notable shift is that "excessive agency" has risen to number three.

Excessive agency is when an LLM has been given persistent memory, broad tool access, credentials, and connections to systems holding sensitive data, without enforcing strict limits on what it can actually touch. OWASP's framing is precise: the question is not whether the model behaves well under normal conditions. The question is whether the damage is bounded when it does not.

The recommended control is identity-based, least-privilege access enforced outside the model. The model should not be trusted to self-limit. The system around it should limit it.

That is a design principle, not a security feature you add later.

What This Changes for a Small Builder

The platforms Kennedy examined are tools many small teams use to wire AI into their product. Flowise and Langflow are common starting points. Dify and Activepieces show up in internal automation stacks. These are not enterprise-only targets.

The uncomfortable question is whether the limits on your agent are enforced in code, or only in a prompt.

A prompt tells the model what it should do. A server-side control decides what the model can do. Under adversarial input, the gap between those two things is a vulnerability. I think most small builders close the first gap carefully and underestimate the second.

One Check Before the Next Deploy

Before giving an agent a new capability, trace what that tool can do with the worst possible argument. Then ask: if this call were triggered by injected content, what is the maximum damage?

If the answer involves data users did not intend to expose, an irreversible operation, or access to infrastructure beyond the current task, the permission boundary is too wide. A tighter scope, a human gate, or a confirmation step belongs in the architecture, not in the prompt.

The Endor Labs research and the OWASP 2026 update are pointing at the same thing: once an agent has real capabilities, prompt injection is an access control problem. Access control belongs in the system, not in the model's behavior.

I'm Gilles, a developer building SaaS products where AI acts and learning to secure them. gilleshelleu.com