Varonis disclosed the flaw through Google's Vulnerability Reward Program in November 2025, and Google shipped an initial fix in April 2026 before fully resolving the issue in June 2026 — about seven months from report to resolution.
How Rogue Agent worked inside Dialogflow CX Code Blocks
Varonis named the defect "Rogue Agent." It affected Dialogflow CX agents that used Playbooks with custom Code Blocks — the feature that lets developers insert Python into a conversation flow. Those Code Blocks execute in a Google-managed Cloud Run environment shared by every agent in the same Google Cloud project. Varonis found a writable wrapper file in that shared runtime named code_execution_env.py. When Dialogflow runs a Code Block, the developer’s code is appended to internal setup code and passed to Python’s exec() function; the setup defines scoped variables (including history and state) and functions such as respond().
Because code_execution_env.py was writable from within the environment, one malicious Code Block with write access could download an attacker-controlled replacement for that wrapper and overwrite the file inside the running container. The attacker’s wrapper would then execute for every subsequent Code Block across every agent sharing that runtime, with full access to conversation history, session state, and respond(). That access enabled reading live conversations, silently sending them to an external server, and having bots post attacker-written messages — for example, requesting a user to re-enter a password.
Who could abuse it: the dialogflow.playbooks.update permission
The vulnerability was not a remote, unauthenticated flaw. Exploitation required the dialogflow.playbooks.update permission on a Code Block-enabled agent. Varonis notes that limitation constrains the realistic attacker to a malicious insider or a compromised developer account rather than "a stranger on the internet." From that single foothold, however, the reach extended to every Code Block-enabled agent in the same Google Cloud project because of the shared runtime.
Sandbox failures beyond the overwrite: outbound network and IMDS access
Varonis reported two additional weaknesses in the Code Block sandbox. First, the runtime had unrestricted outbound internet access. Using Python’s built-in urllib, researchers could exfiltrate data directly to an external server and receive commands back. Varonis says this bypassed VPC Service Controls — the Google Cloud perimeter designed to prevent data from leaving protected services — because the environment sits outside that perimeter and can reach the open internet.
Second, the sandbox could query the Instance Metadata Service (IMDS), returning a token for a Google-managed service account. Varonis describes that account as low-privilege, limiting direct damage, but emphasizes the principle: a code-execution sandbox should not be able to reach IMDS at all.
Visibility, logging, and what to check now
The overwrite and injected code ran inside Google’s environment, which customers cannot see or control. Cloud Logging did not record the file change or the injected code, so the definitive overwrite leaves no direct customer-facing log entry. Varonis points out, however, that setup actions around an attack can leave traces customers can hunt for.
- Audit who holds dialogflow.playbooks.update in your project — that permission is the primary entry point.
- Review DATA_WRITE audit logs for the Dialogflow API for unexpected playbook updates and correlate those entries with unusual users, IP addresses, or access times.
- Run a Cloud Logging query for failed user requests; error messages can reveal exceptions thrown by malicious Code Blocks.
- In the Dialogflow console, open Playbooks for each agent and confirm every Code Block shown is one you approved — note that restoring a Code Block in the console does not remove an already-overwritten runtime file that is still executing.
Varonis and Google say there is no sign the flaw was ever used in a real attack. Google did not assign a CVE for the issue.
How technologists, procurement leaders, and end users should treat agent-edit permissions
Technologists and security teams: treat Code Block edit rights as runtime execution rights. A permission that looks like a content-edit right (playbook edits) was effectively a code-execution capability because anyone who can add a Code Block can run arbitrary Python inside a shared environment the customer cannot inspect.
Procurement and platform owners: if your teams use Dialogflow Playbooks with Code Blocks, inventory that usage and insist on clear runtime isolation guarantees from providers. Even when a vendor issues a patch or says “no change required,” customers still have no way to look inside the provider-managed runtime themselves.
End users: the immediate risk to any individual depends on whether an organization used Code Blocks and whether an account with edit permission was compromised. Varonis recommends auditing access and the logs described above to confirm no targeting occurred.
Rogue Agent is a reminder that in managed AI and bot platforms, an “edit” is not always cosmetic. When runtime code is shared and opaque, a single edit permission can become a project-wide backdoor — a fact the July 2026 fixes close, but which leaves customers without direct visibility into the runtime that once allowed it.
