Contribution
This post adds original detection content: a prompt-to-shell correlation pattern for AI workflow servers that joins application requests, child process evidence, secret reads, and cloud API use by the workload identity. The sources document separate flaws in Flowise and Semantic Kernel; the contribution here is the defender-side chain that catches the moment a model-facing workflow becomes a cloud incident.
The pattern
The useful pattern is not 'prompt injection exists'. That story is already too broad. The sharper pattern is text reaching an execution boundary inside an AI workflow server, then crossing into operating-system or cloud credentials without a normal deployment event.
Flowise gives two concrete examples. In GHSA-3hjv-c53m-58jj, Trend Micro's Zero Day Initiative describes a CSV Agent flaw where Flowise asks a model to produce Python code for pandas analysis, then evaluates that code in a Pyodide environment. The guardrail is a deny-list of forbidden patterns. The advisory shows why that fails: an import expression can alias an operating-system module while appearing to satisfy the intended pandas or numpy allowance. The result is remote code execution on the Flowise server from a chatflow query. The advisory says authentication is not required for that path when a vulnerable chatflow is exposed.
The second Flowise advisory, GHSA-3gcm-f6qx-ff7p, sits on a different boundary but lands in the same place. The CustomMCP node accepts mcpServerConfig, performs variable substitution, then passes user-controlled text into the JavaScript Function() constructor. The advisory describes full Node.js runtime access, including child_process and fs, and shows a proof of concept that writes a file on the server. That is not a model safety failure in isolation. It is a server-side code execution flaw reachable through an agent-tool configuration surface.
Microsoft's Semantic Kernel advisory for CVE-2026-26030 shows the same class in a different framework. The Microsoft Security Update Guide records remote code execution in the Python SDK's InMemoryVectorStore filter functionality, with a fix in python-1.39.4 and a workaround to avoid InMemoryVectorStore for production scenarios. The related GitHub advisory says the vulnerable component was the filter functionality, not a generic chat endpoint. That matters because defenders can look for abnormal filter use and process behaviour around vector-store calls rather than treating every prompt as equally suspicious.
Google's scan of indirect prompt injection on the public web adds the external pressure. Google used Common Crawl to look for known prompt-injection patterns and found that false positives are heavy because many pages discuss attacks rather than perform them. That is the operational trap for defenders. If an alert fires on strings such as 'ignore previous instructions', it will drown in security blogs, test fixtures, and user education pages. The useful alert fires when prompt-like input is followed by a server action that should not follow from that workflow.
Why it matters to cloud defenders
AI workflow servers tend to sit in places cloud defenders already care about: Kubernetes namespaces, container services, developer sandboxes, private VPCs, and SaaS-adjacent automation tiers. Flowise is often self-hosted because teams want connectors, local credentials, private vector stores, or control over data movement. Semantic Kernel agents often run inside application services with managed identities, storage access, or access to internal APIs. The risk is not only that the agent server gets popped. The risk is that the agent server already has the permissions attackers want.
A vulnerable CSV Agent or CustomMCP endpoint is usually a web application first. It receives HTTP requests, parses JSON, reads workflow configuration, and may call out to model providers, vector stores, MCP servers, object storage, or internal APIs. If it runs in Kubernetes, the pod may have a service account token, cloud workload identity, mounted secrets, or environment variables holding API tokens. If it runs on a VM, it may reach instance metadata. If it runs as a managed container, its identity may read blobs, secrets, queues, build artefacts, or application databases.
That makes the detection problem cross-plane. Application logs may show the chatflow request or node-load method call, but not the child process. Container runtime logs may show python, sh, node, or curl, but not the prompt that caused it. Cloud audit logs may show GetSecretValue, storage.objects.get, or ListBuckets, but not the vulnerable route. None of those events is enough alone. Together, in a narrow time window, they are strong.
This also changes ownership. The platform team may patch Flowise. The application team may own the chatflow. The SOC may only see CloudTrail, Azure Activity, Google Cloud Audit Logs, Kubernetes audit events, and endpoint telemetry from nodes. A post-exploitation hunt has to give each team a piece of the same chain. Otherwise the prompt event is dismissed as app noise, while the cloud API call is filed as normal workload behaviour.
The main mistake is to make the prompt the centre of the detection. Prompt content is untrusted, multilingual, often hidden inside uploaded data, and hard to classify at low noise. The centre should be the transition: a model-facing route or tool configuration event that is followed by code execution or secret access by the same workload. That is where the attack becomes visible in logs defenders can query.
ATT&CK mapping
The entry point maps to T1190, Exploit Public-Facing Application, when an exposed Flowise chatflow, node-load method, or Semantic Kernel-backed service accepts attacker-controlled input over HTTP and reaches the vulnerable code path. The product may be an AI workflow tool, but the initial access shape is still a public-facing application receiving crafted input. The signal is not the word 'AI'. It is an exposed route taking data that changes server behaviour.
The execution step maps to T1059, Command and Scripting Interpreter. The Flowise CSV Agent case turns model-produced Python into code execution. The CustomMCP case turns a JavaScript configuration string into code run by Node.js. Semantic Kernel's vector-store filter issue sits in the same execution family because filter text crosses into code execution inside a Python SDK component. The specific interpreter varies. The defensive question is stable: did a workload that normally serves prompts spawn a shell, Python interpreter, Node child process, package manager, downloader, or file-write tool outside a deployment window?
The likely payoff maps to T1552.001, Credentials in Files, when the attacker uses the compromised process to read mounted secrets, .env files, cloud config, SSH material, npm tokens, service account tokens, or application credentials. This is not guaranteed by every exploit, so it should not be asserted as fact for every incident. It is the next hunt stage because both Flowise advisories describe file-system or command-execution impact, and AI workflow servers often run near credentials. If the workload identity then calls cloud APIs that were not part of normal agent execution, the investigation moves from host compromise to cloud access.
There are other honest mappings in some deployments, including Valid Accounts for stolen tokens and Cloud Service Dashboard activity if a human console session follows. I am not listing those in technique_ids because they depend on what the attacker does after the first shell. Keep them in the case notes, not in the article spine.
Detection guidance
Start with a correlation rule rather than a string rule. The first event is an application request to a model-facing route or tool route. For Flowise, useful route families include /api/v1/prediction/, chatflow invocation routes, and /api/v1/node-load-method/customMCP where present in reverse-proxy or application logs. For Semantic Kernel services, use the owning application's route map and mark endpoints that invoke vector-store filters, code-interpreter plugins, file upload or download helpers, and tool registries. The exact path varies, so the inventory step matters.
The second event is local execution evidence from the same container, pod, VM, or workload identity within a short window. On Kubernetes, use audit and node telemetry for exec into the pod, unexpected process starts, new outbound connections, or writes under /tmp, application working directories, and mounted secret paths. On Linux hosts, auditd or EDR should look for the service account that runs Flowise, Node, Python, or the Semantic Kernel app spawning sh, bash, python, node, npm, curl, wget, nc, or cloud CLIs. In container services without process telemetry, fall back to egress and cloud audit logs, but treat that as a weaker view.
The third event is secret access. In AWS, watch for secretsmanager:GetSecretValue, ssm:GetParameter, kms:Decrypt, sts:GetCallerIdentity, and metadata credential retrieval from the affected workload. In Azure, watch Key Vault SecretGet, managed identity token use, storage reads, and role-assignment discovery by the app identity. In Google Cloud, watch Secret Manager access, service account token use, storage object reads, and IAM policy reads. The noisy part is that agent workloads may call these APIs legitimately. The separator is sequence and novelty: a prompt or tool-config request, then local execution, then a new secret or storage read not seen for that workload in the previous baseline period.
A practical query shape is:
- Select model-facing application requests where the route is a chatflow, tool-load, vector filter, CSV analysis, code interpreter, or file helper endpoint.
- Join to process telemetry for the same host, pod, container, task, or service principal within 10 minutes. Flag interpreter, shell, downloader, package manager, cloud CLI, and writes to temp or credential paths.
- Join to cloud audit logs for the workload identity within 30 minutes. Flag first-seen secret reads, metadata credential use, storage enumeration, IAM discovery, or outbound access to an unapproved domain.
- Suppress known maintenance windows, new release rollouts, scheduled connector tests, and approved admin sessions. Do not suppress repeated hits from internet ASNs or from unauthenticated routes.
False positives cluster around developer testing and legitimate data-analysis flows. A Flowise user may upload a CSV and ask for a transformation that produces Python code. A platform engineer may test a new MCP server and trigger CustomMCP list actions. A Semantic Kernel developer may benchmark vector-store filters. Those are expected during build or test windows, but they should not be followed by a production container reading new secrets or calling cloud APIs outside its usual profile.
Do not try to store raw prompt bodies in the SIEM unless privacy approval is already in place. Store route, workflow id, tenant or workspace id, authenticated user where present, source IP or ASN, model/tool node type, request hash, and response status. That gives investigators enough to tie the chain together without turning the SIEM into a copy of user data. If the app already logs prompt text, restrict access and retention. The high-value detection is the transition from text to execution, not the text itself.
What to do now
First, patch the named products. Flowise users should move past the affected versions named in the GitHub advisories: the CSV Agent issue is fixed in flowise and flowise-components 3.1.0 or later, while the CustomMCP advisory lists a fix after the affected 3.0.5 package. Semantic Kernel Python users should move to python-1.39.4 or later for CVE-2026-26030. Treat any exposed AI workflow server as internet-facing application infrastructure, not as a lab toy.
Second, inventory execution-capable nodes. Mark Flowise CSV Agent, CustomMCP, code interpreter, file helper, HTTP tool, shell-like MCP server, vector-store filter, and plugin surfaces. If a node can turn model output or tool configuration into code, it belongs in the higher-risk group. Put those workloads behind authentication, private networking, and egress control. Remove production cloud credentials from them unless they need those credentials for the user-facing task.
Third, add the correlation hunt above to the SOC backlog. It does not need a new product. It needs reverse-proxy or application route logs, process or container telemetry, and cloud audit logs joined by workload identity and time. If one of those three views is missing, write that gap down rather than pretending prompt inspection will cover it. Prompt strings are useful context after triage. They are a poor primary detector.
Fourth, rehearse the response path. If a hit confirms prompt-to-shell behaviour, rotate tokens available to the workload, revoke sessions for affected identities, capture the container or VM image if policy allows, and review downstream cloud API calls from the same identity. Do not stop at patching the framework. The shell is only the first visible move. The cloud incident begins when that process reads a secret, mints a token, or uses the workload identity to reach data.