AI agents are being handed access to corporate databases, cloud infrastructure, internal APIs and sensitive information in the name of productivity. New security research shows how easily that trust can be turned against the organizations deploying them.
Peyton Kennedy, senior security researcher at Endor Labs, uncovered 14 critical and high-severity vulnerabilities across seven AI orchestration platforms, including attack chains that allow unauthenticated users to turn prompt injection into remote code execution (RCE) and data theft.
The research, presented at DEF CON 34, examined NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra and Apache Airflow. The findings point to a fundamental architectural problem: platforms designed to automate increasingly powerful tasks are still operating under security assumptions better suited to single-user developer tools.
In the latest episode of CYBR.SEC.CAST, hosted by Michael Farnum and Sam Van Ryder, Kennedy explained how his research evolved from a straightforward question: Could a prompt injection against an AI agent become a pathway to executing code on the underlying system?
He found that it could. More than once.
Full episode and related article:
, and CYBR.SEC.Media
Bill Brenner
When a prompt injection becomes a shell
Prompt injection has typically been discussed as a way to manipulate an AI model into ignoring instructions, revealing information or producing unintended responses. Kennedy's research demonstrates something more consequential: When AI-generated output is passed into an execution environment without adequate safeguards, malicious instructions can become operating-system commands.
The distinction matters because attackers don't necessarily need privileged access to the platform. In some configurations, they don't even need an account.
In Flowise 3.1.2, Kennedy demonstrated an unauthenticated attack against a prediction endpoint. The attack manipulated the model into generating Python code that bypassed a 38-pattern validation blocklist. Once executed, the code crossed from the Pyodide runtime into the underlying Node.js environment, enabling command execution and dataset exfiltration.
Langflow presented a similar problem. Its Smart Transform component validated whether generated code resembled a Python lambda expression, but the check failed to prevent dangerous operations. Kennedy demonstrated how a single chat message could lead to command execution on the host.
The larger issue wasn't simply inadequate input filtering. These systems were treating AI-generated output as something trustworthy enough to execute.
That's a dangerous assumption when the model's output can be influenced by an attacker.
The attack doesn't have to start in the chat window
One of the most important points Kennedy raised during CYBR.SEC.CAST was that malicious instructions don't necessarily arrive through direct interaction with an AI assistant.
Agents routinely ingest information from documents, repositories and other external sources. That information becomes part of the context the model uses to decide what to do next.
A PDF, for example, may be legitimate reference material for the task an agent is performing. But if the agent treats instructions embedded in that document as authoritative, the document becomes a potential attack vector.
Kennedy warned that organizations need to treat information entering an agent as potentially malicious, regardless of whether it comes from a direct user request or a supporting source.
That creates a difficult security problem. An agent may be operating with legitimate access to sensitive systems while processing information supplied by someone who has no such privileges.
The attacker doesn't need to steal the agent's credentials if the agent can be persuaded to misuse them.
Sandboxes aren't always the safety net organizations expect
Kennedy's research also found failures in the mechanisms intended to isolate potentially dangerous code.
In Dify, a preload mechanism could execute code before the sandbox's security restrictions were activated. Activepieces exhibited a related problem in which module-loading behavior allowed code to execute outside the intended isolation boundary.
These weren't necessarily failures of the underlying sandbox technologies. They were failures in how the surrounding applications implemented them.
A separate September investigation involving the AI coding-agent sandbox brig reinforced that concern.
Kennedy discovered a symlink traversal vulnerability that could allow an agent to access host directories it had never been authorized to reach. By replacing a project subdirectory with a symbolic link, an agent could influence what the application mounted during a subsequent run.
The flaw, tracked as GHSA-wp6x-29qx-fpr7 and rated 8.2 under CVSS, potentially exposed SSH keys, cloud credentials and other sensitive files. It affected versions before brig 0.3.0, which fixed the problem.
Importantly, this was not a hypervisor escape. The underlying virtual machine isolation remained intact. The application itself crossed the trust boundary by mounting an unintended host directory.
The lesson extends beyond brig: A sandbox is only as effective as the application logic controlling what enters, leaves and executes around it.
The 'working as designed' problem
Perhaps the most troubling finding wasn't purely technical.
Kennedy encountered maintainers who considered some of the reported behavior intentional. Their argument was that these platforms were built to execute code, and securing deployments was the responsibility of whoever operated them.
There's some logic to that position. Workflow engines must execute scripts to perform their intended functions. But the argument becomes harder to defend when an unauthenticated endpoint can trigger those functions using attacker-controlled input.
In Kestra, Kennedy documented how webhook-triggered workflows could pass supplied values into shell execution. In Apache Airflow, the research identified unsafe command construction patterns involving user-supplied configuration values and the BashOperator.
Airflow addressed the documentation issue in version 3.2.0, but the underlying execution capability remained. Existing workflows using the unsafe pattern still required review.
During the podcast, Kennedy described the resulting responsibility gap: Maintainers expect deploying organizations to secure their configurations, while organizations assume the platforms they install already provide appropriate protections.
Both sides may believe someone else has addressed the risk.
Meanwhile, the workflows continue running.
What security teams should do now
The research offers several concrete priorities for organizations deploying AI orchestration platforms.
Audit exposed workflow endpoints. Treat endpoints capable of triggering code execution as privileged interfaces, even when they appear to be ordinary webhooks or prediction APIs. Enforce authentication and restrict network access.
Stop treating model output as trusted code. Any workflow that transforms AI-generated text into executable instructions deserves particular scrutiny. Validation must enforce security boundaries rather than merely check syntax or block a handful of dangerous strings.
Review sandbox implementation, not just sandbox capabilities. Determine whether code can execute before isolation controls activate, whether external paths are resolved safely and whether components can access host resources outside their intended scope.
Limit agent privileges and connected resources. Kennedy emphasized least privilege during the podcast, including restricting access to databases, cloud environments and other agents. Security teams should evaluate the damage possible if an agent's instructions or execution environment are compromised.
Apply fixes and review unsupported platforms. Kennedy's August research identified fixes for several findings, including NocoBase 2.0.39, Langflow 1.10.3 or 1.11.0, and Activepieces 0.80.0. He also reported that Flowise had been archived, making migration planning especially important. Organizations should verify current advisories and vendor status before making remediation decisions.
AI's trust problem is getting harder to ignore
The larger problem is that AI adoption is changing what constitutes a security boundary.
An employee using a chatbot to summarize a document presents one category of risk. An autonomous workflow that reads documents, connects to production systems and executes commands presents another.
Yet organizations are increasingly combining those capabilities without fully accounting for the consequences.
Kennedy's findings show that vulnerabilities can emerge not only from defective code but also from the assumptions developers make about who can trigger a workflow, what information an agent can trust and where execution privileges begin and end.
The industry has spent decades learning to separate untrusted input from executable code. AI orchestration is forcing security teams to confront that lesson again, this time with models capable of generating instructions and platforms eager to execute them.
The danger isn't simply that an AI agent might produce the wrong answer.
It's that the wrong answer might become a command running inside the enterprise.
