Rogue Agent: A Code Injection Flaw in Google Dialogflow CX That Could Hijack AI Conversations

Varonis Threat Labs disclosed a critical vulnerability in Google Cloud’s Dialogflow CX, the conversational AI platform used to build voice and text chatbots. Tracked under the name “Rogue Agent,” the flaw stemmed from how Playbook Code Blocks execute inside a Google-managed environment and could have allowed a single authorized user to inject persistent malicious logic across every agent in a project.

What the vulnerability actually targeted

Dialogflow CX uses Playbooks to structure conversations. Inside Playbooks, Code Blocks let developers drop custom Python directly into a conversation flow, which lets an agent process input, call APIs, and manipulate data on the fly. From a researcher’s standpoint, that feature is interesting because it is, by design, a sanctioned path to executing arbitrary Python.

Code Blocks run inside a fully managed Cloud Run service. That service ships with a writable file system, outbound internet access by default, and no enforced network perimeter. Varonis found that all Dialogflow agents using Code Blocks within the same Google Cloud project effectively share that same Cloud Run execution environment, with no direct visibility from the customer side. The shared environment is convenient for operations and dangerous from a trust standpoint.

The only permission required

The exploit required a single edit permission: dialogflow.playbooks.update, scorable to one agent. With that, an attacker could configure a Code Block that downloaded a modified Python file from an attacker-controlled Google Cloud Storage bucket and overwrote the existing execution environment inside the Cloud Run container.

How the exploit chain worked

Varonis enumerated the files inside the Cloud Run filesystem and located a file, code_execution_env.py, that is responsible for running configured Playbook Code Blocks via Python’s exec() function. That file was writeable.

Because the user-supplied Code Block is appended to internal code that defines variables like history (full conversation history) and state (session parameters including the session ID), the injected code ran in the same scope as those variables. That gave it direct visibility into ongoing conversations, without needing any extra prompts or tricks to surface that data.

The modified environment file did three things:

• Intercepted every execution before exec() was called
• Sent conversation data to an attacker-controlled server
• Used the internal respond() function to make the agent output attacker-chosen text, including phishing prompts disguised as reauthentication requests

After the overwrite, the attacker could revert the Code Block configuration in the Dialogflow console to make everything look normal. Cloud Logging did not capture the file overwrite or the injected logic, so the activity was effectively invisible to the victim.

Two related weaknesses that amplified the impact

VPC Service Controls bypass

Dialogflow CX often runs behind VPC Service Controls, which are meant to enforce a strict data perimeter. Because Code Blocks execute inside a Google-managed Cloud Run service with unrestricted outbound internet access, the execution environment sat outside VPC-SC. A simple HTTP request from inside a Code Block opened a bidirectional channel that bypassed the perimeter and could double as a command-and-control channel.

Credential leakage through the Instance Metadata Service

The same Cloud Run environment exposed the Instance Metadata Service. Querying IMDS returned access tokens belonging to a Google-managed service account. While the account was low-privileged, its exposure represented a meaningful architectural gap: code execution environments should not have visibility into IMDS.

Discovery, disclosure, and remediation

Varonis first reported the vulnerability to Google in November 2025. Google issued an initial security update in April 2026 and fully resolved the issue in June 2026. Varonis stated it was not aware of any exploitation in the wild before the patch. Any organization using Dialogflow CX agents with Playbook Code Blocks was potentially in scope before the fix.

Recommended actions for defenders

Even though the underlying issues are now patched, Varonis and Google recommend auditing Dialogflow CX configurations and analyzing past playbook update actions. Practical steps include:

• Reviewing Dialogflow API audit logs for past successful playbook update events, filtering on Playbook.Create or similar events and the relevant methods
• Checking for rare API access by a user, unusual IP addresses, and atypical access times
• Running a Cloud Logging query for failed requests and reviewing protoPayload.status.message for Dialogflow Code Block exceptions
• Manually reviewing every Playbook’s Code Blocks in each agent, confirming only approved blocks are present

The broader takeaway

The Rogue Agent disclosure lines up with other recent AI-flavored findings from Varonis, including Reprompt in Microsoft Copilot Personal and SearchLeak in Microsoft Copilot Enterprise. Taken together, they suggest that cloud-hosted AI platforms are increasingly rewarding researchers who go looking for shared execution environments, writable files, and forgotten perimeter controls.

For defenders, the practical lesson is straightforward. As agent features get built on top of managed serverless runtimes, auditing the surrounding identity, logging, and network controls becomes just as important as testing the conversational layer itself. Treating a managed service as a black box is no longer a safe default.