A Google chatbot 'edit' permission was really a code-execution grant

A permission named dialogflow.playbooks.update sounds like a content-edit right, the kind you hand a colleague so they can tweak a chatbot's replies. On Google Cloud's Dialogflow CX it was something else entirely: a way to run arbitrary Python inside a shared runtime that the customer cannot see, and to reach every other chatbot in the same Google Cloud project. That gap between what a permission is called and what it actually grants is the real story here, and it is not unique to Google.

Varonis Threat Labs disclosed the flaw, which it named Rogue Agent, in early July. Google has fixed it. No CVE was assigned, and Varonis reported no exploitation in the wild before the fix landed. What remains is a governance problem that outlives this one bug: on managed agent platforms, "edit" scopes are frequently latent code-execution scopes, and standard identity reviews are not built to catch that.

How could one chatbot compromise the others?

Dialogflow CX lets developers embed custom Python inside conversation flows through a feature called Code Blocks. Those blocks run on a Google-managed Cloud Run service, and every agent in the same Google Cloud project shares that one execution environment. A single account with edit rights on one Code Block agent could, as The Hacker News reported, plant code that reached all of them: reading live conversations, stealing whatever users typed, and pushing attacker-written replies.

The mechanism was a writable file. Varonis found that code_execution_env.py, the script that wraps and runs each Code Block, sat in the shared environment with write access. A malicious block could download a modified copy from an attacker-controlled bucket and overwrite the original inside the running container. From that point every Code Block execution in the project passed through attacker logic, with access to the history and state variables that hold full conversation records and session parameters.

Two details make this worse than a normal server-side bug. The attacker could then restore the original Code Block configuration, so the Dialogflow console looked untouched while the tampered code kept running in a layer the customer never sees. And the whole thing keyed off one permission that can be granted at the project level or scoped to a single agent. As the reporting put it, a right that looks like content editing was really a right to execute code.

The blast radius was bigger than the grant

Most cloud threat models treat the project as the boundary. Grant a permission on one resource, and you reason about that resource. Rogue Agent broke that assumption because the thing that actually mattered, the shared Cloud Run environment, was managed by Google and lived outside the customer's view. The boundary a defender could see (an individual agent) was not the boundary that governed the damage (a runtime common to the whole project).

This is the part worth internalizing beyond Dialogflow. Whenever a platform executes content you are allowed to edit, and executes it in infrastructure it manages on your behalf, the edit permission inherits the reach of that shared infrastructure. You cannot audit the runtime, you cannot put your own monitoring inside it, and you often cannot even tell how many other tenants of your own org share it. The permission-to-blast-radius mapping stops being something you can reason about from the IAM policy alone.

This was never just chatbot data theft

Headlines framed Rogue Agent as AI chatbot data theft. That undersells it. Varonis reported that the Code Block runtime had public outbound internet access by default, which placed it outside the project's VPC Service Controls perimeter and turned the managed Cloud Run service into a covert channel for pulling data out. The same position let an attacker query the instance metadata service and retrieve access tokens for a Google-managed service account.

A service-account token plus unrestricted egress is not a chatbot problem. It is a foothold for lateral movement inside the cloud environment. Treating this as "someone could read your bot transcripts" misses that the same primitive reached cloud credentials and a data-exfiltration path that the perimeter was supposed to block.

There is a second-order risk in the reply-injection capability that is easy to wave past. A tampered agent could use the platform's respond() function to make the bot return any string as if the model wrote it, including a request to re-enter a password. Users have no reason to distrust a first-party assistant on a site they already trust. A phishing prompt delivered through the real chatbot has a far higher success ceiling than an external lookalike, because every trust signal the user relies on is genuine.

A seven-month fix, and what it leaves

Varonis reported the issue to Google in November 2025. Google shipped an initial fix in April 2026 and fully resolved it in June 2026, roughly seven months from report to full remediation. The timeline above tracks that window. For a flaw that crossed a tenant boundary inside a shared managed runtime, that is a long tail, and it is a reminder that "the provider will fix it" is not the same as "the risk is handled today."

Here is the uncomfortable part for defenders: there was nothing for a customer to patch. The vulnerable code was Google's, in infrastructure customers do not control. If you ran Dialogflow CX with Code Blocks during that window, your only defensive surface was the one thing you did own, the control-plane audit trail of who changed what.

Treat agent-edit rights as code-execution grants

The specific bug is closed. The lesson generalizes to every managed agent platform you run, so act on the governance gap, not just this instance:

• Inventory who holds the edit permission. Find every principal with dialogflow.playbooks.update (or the equivalent "edit the agent" right on whatever platform you use) and review it as if it were a deploy or run permission, because functionally it is one.

• Make the control-plane log your detection surface. With the data plane invisible, the durable signal you own is the change event. Varonis recommends enabling DATA_WRITE audit logs for the Dialogflow API and hunting for playbook updates that correlate with rare users, unusual IP addresses, or off-hours access.

• Watch egress from the managed runtime where the platform exposes it, since a bystander service with public outbound access is exactly what a covert exfiltration channel needs.

• Review configured Code Blocks by hand and confirm each one is approved, since a restored configuration can hide tampering that already ran.

None of that is Dialogflow-specific. The habit of reading control-plane change logs as primary telemetry, rather than trusting a runtime you cannot inspect, is the same discipline behind managed log management and threat hunting. Agentic AI keeps moving execution into places defenders cannot instrument. The permission model is where you still have real control over that, so grade every "edit" scope by what the platform will do with the content, not by the verb in its name.

We have watched this exact pattern land in other AI tools: one Langflow account able to run every other user's workflow, a config file that executed as you the moment an agent opened the wrong repo, and prompt injection reopening old doors in Microsoft 365 Copilot. The plumbing changes, the failure mode does not: content you are trusted to edit becomes code someone else gets to run.