Nobody Fooled the Chatbot. One Edit Permission Took Over Every Bot in the Project.

Nobody fooled the chatbot, and that is what makes this one different

Most AI security stories this year follow one plot. Someone hides instructions in a document, an email, or a code comment, the model reads them, and the model obeys. Rogue Agent never went near the model. Varonis Threat Labs published it on July 7, 2026: a flaw in Google Cloud's chatbot platform where a single edit permission on a single bot let an attacker read every conversation running across every bot in the same project, copy it all to a server of their choosing, and put words in the bots' mouths.

Google has fixed it, and neither Varonis nor Google has found any sign it was used before the patch. The reason to keep reading is the shape of the thing. A permission most organizations would file under "content editing" turned out to be permission to run arbitrary code inside an environment the customer could not see, could not log, and did not know they were sharing.

What Varonis found

The affected product is Dialogflow CX, Google Cloud's platform for building the chatbots that sit in front of customer support queues, banking apps, and healthcare intake forms. Those bots handle exactly the material you would expect: personal details, payment information, confidential business data. Varonis Threat Labs reported the flaw to Google's Vulnerability Reward Program in November 2025. Google shipped a partial fix in April 2026 and closed the issue fully in June. No CVE was ever assigned. The researchers named it Rogue Agent.

Dialogflow lets developers drop Code Blocks, snippets of custom Python, into a conversation flow so a bot can validate an input or call an external service. That Python runs inside a Cloud Run container (a Google-managed environment that spins up code on demand), and here is the design detail that carries the whole story: every agent using Code Blocks in the same Google Cloud project shares one instance of it. Google operates it, the customer cannot look inside, and Varonis found no real isolation between the agents in there. When a block runs, the developer's Python is appended to internal setup code and handed to exec(), Python's run-this-string function. That setup code hands the block a variable called history, holding the full conversation, a variable called state, holding session details, and a respond() function that makes the bot say a given string. The wrapper file doing all of this, code_execution_env.py, sat in the shared container with write access on it.

So one Code Block was enough. It fetched a doctored copy of code_execution_env.py from storage the attacker controlled and overwrote the original inside the running container. From that moment the attacker's version wrapped every Code Block execution for every agent sharing the environment, with the same reach into history, state, and respond().

• The entry ticket was a single permission, dialogflow.playbooks.update, on one agent. In practice that means a malicious insider or a compromised developer account, not a stranger on the internet.
• Using respond(), an attacker could make the bot ask a user to re-verify their password, then collect the answer from the next batch of stolen conversation.
• The attacker could then restore the original Code Block in the console. The console goes back to looking clean while the overwritten file keeps running underneath. Cloud Logging recorded neither the overwrite nor the injected code.

Why it matters

Varonis stayed inside its own environment, so no customer lost anything. What was demonstrated is a path from one over-granted permission to silent, complete surveillance of an enterprise's customer conversations, with credential phishing available on top and almost nothing left in the logs. If your organization runs chatbots on this platform, the practical question is not whether you were breached. It is who holds edit rights on your agents, and whether anyone has ever reviewed that list as a list of people who can execute code. Varonis also found the shared container had unrestricted outbound internet access, which let their test code reach an external server straight through VPC Service Controls, the Google Cloud perimeter many organizations lean on to satisfy GDPR and HIPAA. A perimeter is only a perimeter if the code inside it cannot dial out.

The broader shift is that AI platforms have quietly created a new class of permission. Anywhere a product lets you configure an agent by adding code, prompts, or tools, that configuration surface is an execution surface, and the runtime it executes in probably belongs to your vendor rather than to you. Microsoft reported in February 2026 that 80 percent of the Fortune 500 are actively running AI agents. Most of them are running in someone else's container.

What to do about it

1. Audit who can edit your agents, and read that list as a list of people who can run code. Rogue Agent needed exactly one permission on exactly one agent, so the blast radius of an over-granted edit right is every agent in the project, not the single bot you granted it on.
2. Look through the logs you do have for playbook updates you cannot explain. The pre-patch window ran from at least November 2025 to June 2026, so pull DATA_WRITE audit logs for the Dialogflow API and correlate any unexpected update with unusual accounts, addresses, and hours.
3. Ask every AI vendor where your code runs and what it can reach from there. The entire attack depended on a shared runtime with a writable filesystem and open internet egress, and that is a question worth asking before you adopt the next platform rather than after someone else's researcher answers it for you.

Bottom line

Rogue Agent is worth remembering not for the damage it did, which was none, but for the assumption it broke. The industry has spent a year learning to distrust what models read. This flaw did not involve the model at all. It was an ordinary developer feature, a writable file, and a container the customer had no standing to inspect. When you rent an AI platform, you also rent its runtime, and you cannot audit what you cannot see. One question is worth putting on the table at your next security review: for every AI service you have adopted, do you know who can change how it behaves, and would you find out if they did?