Google Dialogflow CX security flaw let researchers create rogue agent to hijack AI chatbots

Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots

A critical flaw in Google's Dialogflow CX could have let an attacker with edit rights on one Code Block-enabled agent compromise other Code Block-enabled agents in the same Google Cloud project. From there, they could read live conversations, steal the data users shared, and make the bots send attacker-written messages, including requests to re-enter a password. Security firm Varonis found it and named it Rogue Agent. The flaw affected only organizations that built agents with Dialogflow's Playbooks and custom Code Blocks, which let developers add their own Python. And it was not a remote, unauthenticated attack. Pulling it off needed the dialogflow.playbooks.update permission on one such agent, which limits the realistic attacker to a malicious insider or a compromised developer account, not a stranger on the internet. From that one foothold, though, the reach extended to every agent in the project. Google has fixed it, and both Varonis and Google say there is no sign the flaw was ever used in a real attack. One writable file ran every agent's Code Blocks Dialogflow's Code Blocks let developers add custom Python to a chatbot's conversation flow to check input, control behavior, and invoke defined tools. That code runs in a Google-managed Cloud Run environment, and every agent that uses Code Blocks in the same Google Cloud project shares one instance of it. Google runs that environment, the customer cannot see or control it, and Varonis found no real isolation between the agents inside it. When an agent runs a Code Block, the developer's code is appended to internal setup code and passed to Python's exec() function. That setup code defines the variables and functions the block can touch. Variables include history for the full conversation and state for session details like the session ID. Functions include respond(), which makes the bot reply with a given string. Varonis found the file that does this wrapping, code_execution_env.py, sitting in the shared environment with write access. Because that file was writable, a single Code Block could replace it. That block downloads a modified code_execution_env.py from an attacker-controlled server and overwrites the original inside the running container. From then on, the attacker's version runs for every Code Block execution across every agent sharing that environment. It sits in the same scope as legitimate code, with the same access to history, state, and respond(). That lets it read each conversation, quietly send it to the attacker's server, and make the bot post attacker-written messages. One example is phishing: the bot asks the user to re-verify a login, and the attacker collects whatever they type. To cover the tracks, the attacker restores the original Code Block in the Dialogflow console. That changes only what the console displays; the overwritten file is already running in the container and keeps executing underneath. The sandbox leaked two more ways Varonis reported two related issues, and neither needed the file overwrite. First, the Code Block environment had unrestricted outbound internet access. Using the built-in urllib library, the researchers sent data straight to an external server and could receive commands back. Varonis says this bypasses VPC Service Controls, the Google Cloud perimeter meant to stop data from leaving protected services. The environment sits outside that perimeter and can reach the open internet, which turns it into a channel for both data theft and remote control. Second, and less serious, the environment exposed the Instance Metadata Service (IMDS), a normally internal endpoint that hands out cloud credentials. Querying it returned a token for a Google-managed service account. That account was low-privilege, so the direct risk was limited; the real point is that a code-execution sandbox should not be able to reach IMDS at all. Almost nothing reached the logs The overwrite happened inside Google's environment, where customers have no visibility, and Cloud Logging did not record the file change or the injected code. That makes it hard, though not impossible, to catch from the customer side. The setup actions still leave traces, which the checks below rely on. Varonis disclosed the flaw through Google's Vulnerability Reward Program in November 2025. Google shipped an initial fix in April 2026 and fully resolved it in June 2026, about seven months from report to resolution. No CVE was assigned. What to check if you used Code Blocks If you ran Dialogflow CX agents with Code Block Playbooks before the fix and want to confirm you were not targeted, start with access. The dialogflow.playbooks.update permission is the whole entry point, so audit which roles and accounts hold it. Then: * Review your DATA_WRITE audit logs for the Dialogflow API for unexpected playbook updates, and correlate them with unusual users, IP addresses, or access times. * Run a Cloud Logging query for failed user requests, where the error messages can reveal exceptions thrown by malicious Code Blocks. * In the Dialogflow console, open Playbooks for each agent and confirm every Code Block is one you approved. A different kind of AI flaw Many recent AI security flaws have worked by fooling the model. Varonis's own Reprompt and SearchLeak turned a single click into data theft in Microsoft's Copilot. Noma Security's ForcedLeak hid instructions in a Salesforce web form to pull out CRM data. Microsoft's researchers showed prompt injection turning into code execution in the Semantic Kernel framework. Rogue Agent did not touch the model at all. It abused a normal developer feature and a shared, invisible runtime, reachable with one ordinary edit permission. In a setup like this, a permission that looks like a content-edit right is actually a code-execution right. Anyone who can add a Code Block can run arbitrary Python inside a shared environment that the customer cannot inspect. Treat agent-edit permissions as the runtime controls they are. Even when the provider says nothing needs fixing, customers still have no way to look inside that runtime themselves.

Experts say they were able to create a rogue agent in Google's AI platform with just a single edit permission

One compromised agent could take over every other agent in that project * Varonis uncovered CVE‑level flaws in Google Cloud Dialogflow CX, where malicious Code Blocks in Playbooks could hijack agents, exfiltrate chat logs, and steal credentials * Shared Cloud Run environment with excess privileges meant one compromised agent could control all others in a project, with attacks virtually undetectable in Cloud Logging * Google patched the issue between April-June 2026; researchers advise reviewing audit logs, checking anomalous errors, and manually inspecting Code Blocks for unauthorized code Researchers recently found a critical vulnerability in Google Cloud's Dialogflow CX, allowing threat actors to take over different AI agents, access chat logs, and even exfiltrate sensitive data such as login credentials. Dialogflow CX is Google Cloud's conversational AI platform used to build many voice and text chatbots. This platform lets developers add Code Blocks, which are custom Python snippets, into conversation "Playbooks". These blocks all execute inside a single Google-managed Cloud Run service, shared across all agents in a Google Cloud Platform project. Security researchers Varonis said they discovered a critical vulnerability in which the theoretical attacker didn't need broad admin access. With permission to edit a single chatbot's settings, they would be able to plant malicious code relatively easily. The Cloud Run environment had no code restrictions, Varonis further explained, but had a writable filesystem, public internet egress, and ran with excess privileges. Key files could have been overwritten entirely, it was added. Google issues a fix As a result, the attacker had access to full conversation history and session state. They could call internal functions and fake LLM-generated replies which, they claim, could lead to phishing and credential theft. Since the environment is shared per-project, one compromised agent could take over every other agent in that project, and since Cloud Logging doesn't capture the file overwrite or injected logic, the attack would be "virtually undetectable." Varonis reported the issue to Google in November 2025, and the latter came back with an initial fix in April 2026. However, the issue had not been fully resolved until June 2026. In the report, the researchers said there is no evidence of in-the-wild exploitation attempts and advises customers to review DATA_WRITE audit logs for Playbooks.UpdatePlaybook calls, check for anomalous Sessions.DetectIntent errors, and manually inspect each agent's Code Blocks for leftover unauthorized code. Follow TechRadar on Google News and add us as a preferred source to get our expert news, reviews, and opinion in your feeds.

Exclusive: Researchers uncover Google AI chatbot security flaw

Why it matters: Companies are increasingly relying on AI chatbots to handle customer service, health care and financial interactions -- making flaws in these systems rich targets for attackers. Driving the news: Varonis found a critical vulnerability in Google's Dialogflow CX platform, which companies use to build AI-powered customer service chatbots and voice assistants. * The service is widely used to power customer support chats, financial services bots and health care assistants. * Varonis researchers found that someone who compromised one chatbot could silently monitor conversations, impersonate the bot and, in some cases, interfere with other AI chatbots running in the same Google Cloud project. Threat level: Users could have been tricked into sharing passwords, insurance information or financial data that attackers could then use in future cyberattacks, Matthew Radolec, field CTO at Varonis, told Axios. * Varonis initially discovered the issue in November, and Google issued a security patch last month. Google did not respond to a request for comment. Yes, but: Varonis said it found no evidence the vulnerability had been exploited in the wild before it was patched. * "We appreciate the efforts of researchers like Varonis who disclose their findings through our Vulnerability Reward Program," a Google Cloud spokesperson told Axios in a statement. "The underlying issue has been fully mitigated, and we have no known indication of customer compromise. No customer action is required." Between the lines: Radolec argues AI tools are being adopted faster than technology companies can fully secure them. * "This whole concept of 'zero trust' architecture is supposed to be leading the charge in cloud and AI, and this is a case where that was overlooked," he said. The bottom line: As companies rush to deploy AI, security teams should verify that AI tools are properly isolated and routinely check for exposed credentials.

Google Dialogflow CX flaw let researchers create rogue agents

Varonis uncovered critical vulnerabilities in Google Cloud's Dialogflow CX that allowed malicious Code Blocks in Playbooks to hijack agents, exfiltrate chat logs, and steal credentials. The shared Cloud Run environment featured excessive privileges, enabling one compromised agent to control all others within a project, with attacks remaining virtually undetectable in Cloud Logging. Google patched these vulnerabilities between April and June 2026. Researchers recommended reviewing audit logs, checking for anomalous errors, and manually inspecting Code Blocks for unauthorized code. The vulnerability allowed threat actors access to different AI agents, full conversation history, and sensitive data such as login credentials. Dialogflow CX is an AI platform that enables developers to build voice and text chatbots, allowing for the inclusion of custom Python snippets, known as Code Blocks, within conversation Playbooks, all executing in a shared Cloud Run service. Varonis stated that the attacker did not need broad admin access; permission to edit a single chatbot's settings was sufficient to plant malicious code. The Cloud Run environment lacked code restrictions, featured a writable filesystem, and included public internet egress, which could lead to complete overwriting of key files. Once compromised, an agent could take over all others in the project. The limitation of Cloud Logging meant that file overwrites or injected logic would go undetected. Varonis reported the vulnerabilities to Google in November 2025. An initial fix was released in April 2026, with full resolution achieved by June 2026. There is no evidence of any in-the-wild exploitation attempts. Researchers advised users to review DATA_WRITE audit logs for Playbooks.UpdatePlaybook calls and to check for anomalous Sessions.DetectIntent errors.