One editable agent, one shared runtime

Dialogflow CX is Google's platform for building voice and text chatbots. Its Playbooks describe how an agent should handle a conversation, and Playbook Code Blocks let developers add custom logic in Python, a programming language. That code runs inside an execution environment: the managed system that supplies the files, variables, network access, and computing process needed to run it. Customers configured the agents, but Google managed this particular environment through Cloud Run, its managed application service.

Varonis researchers found that the boundary around that environment was much wider than the permission model suggested. Code Block-enabled agents in the same Google Cloud project shared the Google-managed runtime. A Google Cloud project is the administrative container used to group related services and permissions. Someone who could edit one qualifying agent could therefore reach machinery later used by other qualifying agents in that project.

The researchers named the flaw Rogue Agent and disclosed it publicly on July 7, 2026. The starting condition matters: an attacker first needed dialogflow.playbooks.update permission on one agent that used Code Blocks. This was not a route for a random stranger on the internet. The Hacker News described a malicious insider or a compromised developer account as realistic entry points.

Varonis and Google said they knew of no real-world exploitation, and Google fully resolved the issue in June 2026. Rogue Agent was a controlled demonstration against the researchers' own Google Cloud environment. Its severity comes from what the shared runtime made possible if that initial permission was abused, not from a claim that customer conversations were actually stolen.

How the overwrite worked

Code Blocks are intentionally powerful. Permission to update a Playbook containing one allowed the holder to run custom Python as part of that agent's conversation flow. Varonis examined the files available to that code and found code_execution_env.py, a Google-provided wrapper that prepared each Code Block for execution. The file was writable by the same process running the developer's code.

The wrapper assembled Google's internal setup code and the customer's Code Block, then passed the combined program to Python's exec() function, which runs supplied Python instructions. Varonis wrote a malicious Code Block that downloaded a modified wrapper from an attacker-controlled storage location and replaced the original file inside the Cloud Run environment. Later Code Block executions then went through the altered wrapper.

The attacker could remove the visible malicious Code Block from the Dialogflow console after the overwrite. That cleanup changed the saved Playbook configuration, but it did not immediately undo the wrapper already replaced inside the running environment. Varonis also reported that Cloud Logging did not record the file overwrite or the inserted logic. Audit records could still show the Playbook update that provided the initial foothold, which is why the researchers advised customers to review those records.

No language model had to misunderstand a prompt. The attack used a legitimate code feature to replace a writable system file. In security terms, that is code injection: attacker-chosen instructions enter a process that other workloads trust. The dangerous part was allowing one agent's custom code to modify a shared component used when other agents ran.

Execution-time context became reachable

The wrapper gave each Code Block variables needed for the current conversation. Varonis identified history, which held the conversation history available during that execution, and state, which exposed session details such as the current session identifier. It also supplied respond(), an internal function that could make the chatbot return a chosen string.

Once the modified wrapper ran for another Code Block-enabled agent in the same project, attacker-written code ran alongside those values and functions. The proof showed a path to read execution-time conversation context, send it to an outside server, and replace a trusted chatbot reply with attacker-written text. Because the Cloud Run service allowed outbound internet connections, the modified code could send captured context outside the customer's Google Cloud project.

A fake request to re-enter login details was one response demonstrated by the researchers. It would arrive through the organization's own chatbot rather than an obviously unrelated website or message. If a user supplied information after such a request, the same outbound channel could carry it away.

The research does not establish retrospective access to every conversation Dialogflow had ever stored. The exposed material was the conversation history and session state present when an affected Code Block executed. Nor did Varonis show reach into unrelated Google Cloud projects. The demonstrated boundary was other Code Block-enabled agents sharing the affected project's execution environment.

Entry permission still matters

The attacker still needed a real permission that could be limited to one agent. Organizations that did not use Playbook Code Blocks were outside the reported attack path, as were agents in other projects.

The potential damage after entry was still severe. A permission that appeared scoped to editing one agent could alter replies and expose live conversation context from others. Dialogflow agents can sit in customer support, financial, healthcare, and internal business workflows. The researchers did not report a harmed customer in any of those settings, but the demonstrated access could have exposed sensitive material or turned trusted bots into convincing phishing channels.

Rogue Agent also differs from two ServiceNow failures already catalogued here. BodySnatcher began with broken authentication and identity linking. An attacker could impersonate a ServiceNow user, then invoke AI agents with that user's privileges. Rogue Agent began after someone already held legitimate edit permission on one Dialogflow agent; it crossed into other agents through Google's shared runtime.

ServiceNow's agent-to-agent prompt-injection case followed another route. There, attacker-written text hidden in data was mistaken for instructions by a model. Default agent discovery let the manipulated agent recruit a more capable agent under the initiating user's privileges. Rogue Agent did not trick a model or recruit a collaborator. Malicious Python replaced an interpreter wrapper used by later Code Block executions. ServiceNow crossed an agent-collaboration boundary through prompt injection. Dialogflow crossed a shared-runtime isolation boundary through code injection.

Seven months from report to full fix

Varonis reported Rogue Agent through Google's vulnerability program in November 2025. Google issued an initial security update in April 2026, then fully resolved the issue in June. Public disclosure followed on July 7, roughly seven months after the first report. No public vulnerability identifier was assigned.

Varonis recommended checking which accounts held dialogflow.playbooks.update, reviewing successful Playbook updates for unusual users, network addresses, or times, and inspecting current Code Blocks. It also suggested looking at failed user requests because exceptions produced by malicious code might have surfaced there.

Those checks were necessarily indirect. The consequential overwrite happened inside infrastructure controlled by Google and outside the customer's view. A customer could examine the action that opened the door, but ordinary logs did not reveal what happened to the wrapper after code entered the managed service.

Isolation is a security boundary

Custom code should be confined to the agent and project scope its permission describes. Rogue Agent broke that expectation twice: one agent could alter a shared runtime component, and the altered component received other agents' execution-time context. The edit permission was accurately powerful within the first agent, but the platform failed to contain where that power ended.

Shared infrastructure can reduce operating cost and complexity. Once separate customer-facing agents pass sensitive context through it, file permissions and workload isolation become part of the agents' security model. A writable interpreter wrapper is not an implementation detail when every qualifying agent in a project later trusts it.

The chain still required dialogflow.playbooks.update permission on one Code Block-enabled agent. Google fully resolved it in June 2026, and Varonis and Google reported no known real-world use. The demonstrated path reached across agents, exposed live conversational state, supported outbound data removal, and let attacker-written replies appear to come from a trusted bot. One agent's editor should never have inherited that reach merely because Google reused the room where the code ran.