How one edit permission could hijack every Dialogflow CX chatbot in a project

What is this?

On July 7, 2026, Varonis Threat Labs publicly disclosed a flaw it named Rogue Agent in Google Cloud’s Dialogflow CX, the managed platform many organizations use to build customer-facing chatbots. The finding, reported by Varonis and covered by The Hacker News, showed that an attacker holding edit rights on a single agent could take control of every chatbot in the same Google Cloud project — reading live conversations, exfiltrating whatever users typed, and making the bots send attacker-written messages such as fake password re-entry prompts.

This was not a remote, unauthenticated attack, and there is no evidence it was ever used in the wild. Exploitation required the dialogflow.playbooks.update permission on one agent that used Dialogflow’s Playbooks and custom Code Blocks feature, which realistically limits the attacker to a malicious insider or a compromised developer account. Varonis reported the issue in November 2025; Google shipped an initial fix in April 2026 and fully resolved it in June 2026. No CVE was assigned.

How it works

Code Blocks let developers drop custom Python into a chatbot’s conversation flow — to validate input or call an API. That code runs in a Google-managed Cloud Run environment, and here is the structural problem: every agent that uses Code Blocks in the same project shares one instance of that environment, with no meaningful isolation between agents inside it.

When an agent runs a Code Block, the developer’s snippet is appended to internal setup code and handed to Python’s exec(). Varonis found the file that performs this wrapping — code_execution_env.py — sitting in the shared container with write access. Because it was writable, one Code Block could overwrite it with a version pulled from an attacker-controlled server.

one writable permission ──▶ Code Block overwrites shared runtime file
                                       │
                                       ▼
        every agent's Code Block now runs attacker-modified setup code
        (same scope, same access to conversation history + reply function)

From that point the modified runtime executes for all Code Block calls across all agents in the project, in the same scope as legitimate code. Two related weaknesses made it worse: the sandbox had unrestricted outbound internet access — bypassing VPC Service Controls and turning it into an exfiltration and command channel — and it could reach the Instance Metadata Service (IMDS), returning a token for a (low-privilege) Google-managed service account. There is no operational payload in this article; the mechanism, not a script, is the lesson.

Why it matters

The uncomfortable insight is a privilege-model one. In this setup, a permission that looks like a content-edit right — “can add a Code Block” — was actually a code-execution right inside a runtime the customer could neither see nor control. Worse, the blast radius crossed agent boundaries: one writable agent compromised its neighbors through a shared execution environment.

It also breaks a defender’s usual assumptions about visibility. The overwrite happened inside Google’s managed environment, and Cloud Logging did not record the file change or the injected code. An attacker could even restore the original Code Block in the console for appearances while the overwritten file kept running underneath. When the runtime is invisible and multi-tenant within your own project, “the provider says nothing is wrong” is not the same as “you are safe.”

Defenses

Treat agent-edit permissions as runtime controls. If a role can add or modify executable blocks, playbooks, or tool code, scope it like a code-deployment right, not a content right. Audit exactly who holds dialogflow.playbooks.update (and its equivalents on other platforms) and apply least privilege.

Assume shared managed runtimes are not isolated until proven otherwise. When a platform executes customer code, ask the vendor how tenants and projects are separated, whether the execution filesystem is writable, and whether one agent can affect another. Build your threat model on the answers, not on the marketing.

Constrain egress and metadata access. A code-execution sandbox should not have open outbound internet or reach IMDS. Where the platform exposes controls, restrict egress and block metadata endpoints; where it does not, treat any data the agent touches as potentially exfiltratable and minimize what you feed it.

Compensate for the logging gap with what you can see. Even though the in-runtime change is invisible, the setup actions leave traces. Review DATA_WRITE audit logs for unexpected playbook updates, correlate them with unusual users, IPs and access times, query for failed requests whose errors reveal Code Block exceptions, and periodically confirm every Code Block in the console is one you approved.

Separate projects by trust boundary. Because the blast radius was the project, put high-sensitivity chatbots in their own project rather than co-locating them with experimental or lower-trust agents that share a runtime.

Status

Item	Detail
Product	Google Cloud Dialogflow CX (Playbooks + custom Code Blocks)
Discoverer	Varonis Threat Labs (“Rogue Agent”)
Prerequisite	dialogflow.playbooks.update on one Code-Block agent (insider / compromised dev)
Impact	Cross-agent takeover in a project: conversation theft, phishing via bot messages, egress channel
Disclosure	Reported Nov 2025; initial fix Apr 2026; fully resolved Jun 2026
CVE	None assigned
In-the-wild	No known exploitation per Varonis and Google

This article summarizes publicly disclosed, vendor-fixed research for defensive purposes and contains no operational attack instructions.