Varonis · Rogue Agent
Primary disclosure explaining how Dialogflow CX Playbook Code Blocks could be abused to affect AI conversations, runtime behavior, and agent trust boundaries
Rogue Agent is not just a Dialogflow CX bug. It is a warning about the next enterprise AI control gap: the runtime layer where prompts become code, code touches data, and one quiet permission can become a production security boundary.
Enterprise AI is moving from demo mode into workflow mode. Agents are no longer just answering questions. They are routing tickets, collecting information, calling tools, triggering actions, and sitting in front of sensitive business systems.
That is why the Rogue Agent disclosure matters. Varonis Threat Labs reported a vulnerability in Google Cloud Dialogflow CX, Google’s conversational AI platform for building text and voice agents. The issue centered on Playbook Code Blocks, a feature that allows developers to embed custom Python logic into conversational flows.
The exploit path, according to Varonis, required a single edit permission: dialogflow.playbooks.update on one agent. That permission could allow a malicious or compromised user to abuse Code Blocks and affect the shared execution environment used by other agents in the same Google Cloud project.
Google issued an initial security update in April 2026 and fully resolved the issue in June 2026. Varonis and Google said they were not aware of exploitation in the wild before the patch.
Most AI security conversations still orbit around the model: prompt injection, jailbreaks, unsafe output, hallucination, data leakage, and model manipulation.
Those risks are real. But Rogue Agent points to something more operational and more familiar to defenders: runtime control.
In Dialogflow CX, Playbooks define structured conversational workflows. Code Blocks allow developers to add Python logic directly inside those flows. That makes the agent more useful. It can process inputs, call external APIs, manipulate data, and customize behavior.
It also means the agent is no longer just a conversational interface. It is executing logic.
That is the line many enterprises are crossing without updating their security model. Once code runs inside an AI workflow, the question changes from “Can the model be tricked?” to “What can this runtime reach?”
“The model may be the face of the AI system. The runtime is where the blast radius lives.“
Varonis described a design weakness in the architecture around Dialogflow CX Playbook Code Blocks. Code Blocks executed inside a Google-managed Cloud Run service. Critically, agents using Code Blocks inside the same Google Cloud project effectively shared that execution environment.
That shared runtime became the weak point.
According to the research, the Cloud Run environment had public network access, a writable file system, and enough local privilege to modify system files involved in code execution. By abusing Code Blocks, an attacker with the required playbook update permission could interfere with the Code Blocks pipeline and gain visibility into session data and conversation history.
This matters because many organizations would treat a playbook edit as a normal AI workflow change. But in this case, the playbook edit was not just content. It was a path into the execution layer.
The most important detail in the Rogue Agent disclosure is not that the attack involved AI. It is that the initial permission looked ordinary.
The exploit path required dialogflow.playbooks.update. In many organizations, that kind of permission may be granted to developers, automation teams, support engineers, chatbot builders, contractors, or business users responsible for maintaining agent flows.
That is exactly the danger.
In a traditional content system, an edit permission changes text. In an agentic AI platform, an edit permission may change behavior, tools, code, data flows, and runtime execution. It can become closer to a deployment permission than a content permission.
Security teams need to stop asking only who can use AI tools. They need to ask who can change the agent.
| Question | Old framing | Runtime framing |
|---|---|---|
| Prompt risk | Can the user trick the model? | Can poisoned input cause the agent to misuse tools or data? |
| Permission risk | Who can chat with the bot? | Who can edit playbooks, tools, code blocks, and publishing state? |
| Data risk | Can the model reveal sensitive output? | Can the runtime read, move, or exfiltrate conversation and session data? |
| Cloud risk | Is the AI service approved? | Where does agent code execute, what identity does it use, and what network paths exist? |
| Detection risk | Can we review prompts and responses? | Can we detect playbook edits, tool changes, runtime drift, and suspicious execution behavior? |
Indirect prompt injection remains one of the clearest AI threats. Google has described indirect prompt injection as a priority for the security community because AI systems increasingly process websites, emails, documents, and other untrusted content that may contain hidden instructions.
But prompt injection becomes more serious when the AI system can act.
A summarizer that gets manipulated may produce a bad summary. An agent that gets manipulated may call a tool, send a message, retrieve data, update a record, or execute a workflow. Microsoft made this same point in its recent guidance on AI agents: enterprise AI tools are shifting from reading content to taking action, and that changes the security implications.
Rogue Agent fits that shift. It was not about a clever jailbreak. It was about what happens when an AI workflow has executable logic behind it.
One of the most uncomfortable parts of the Rogue Agent research is the shared execution environment.
Varonis said Dialogflow agents using Code Blocks in the same Google Cloud project effectively shared the same Google-managed Cloud Run execution environment. That simplified operations, but it created a trust gap because customers did not directly control or observe that layer.
This is a familiar cloud security pattern in a new AI wrapper.
Managed services abstract infrastructure away from customers. That is the point. But abstraction does not remove security dependency. It moves the boundary. When AI agents run code inside managed runtimes, customers still need to understand what isolation exists, what logging exists, what identities are used, and what blast radius exists if one agent or one permission is compromised.
For AI runtime security, isolation becomes a first-class question.
Varonis said detection was difficult because the overwrite occurred inside a Google-managed Cloud Run environment outside the victim’s direct visibility. Cloud Logging did not capture the exact overwrite or injected logic. That is the kind of monitoring gap defenders should expect as AI agents move deeper into managed platforms.
Traditional cloud monitoring may catch identity events. It may catch API calls. It may catch changes to cloud resources. But it may not tell you whether an AI agent’s runtime behavior changed in a dangerous way.
That means defenders need new telemetry expectations for AI platforms:
Track playbook edits, code block changes, tool additions, publishing events, and rare admin activity.
Understand the managed execution layer, service identity, environment boundaries, and isolation model.
Review outbound access, API reachability, external calls, and paths that could bypass expected data perimeters.
Map conversation history, session parameters, customer data, internal records, and tool-accessible systems.
The fix for Rogue Agent belongs to Google and has been completed. The fix for AI runtime security belongs to every organization deploying agents.
Start with inventory. Not a vague list of “AI tools,” but a runtime inventory:
List every agent that can execute code, call tools, or reach APIs — and flag which agents share an execution environment or project boundary.
Scope playbook, code block, tool, and connector edit rights to least privilege. An edit permission here can behave like a production deployment permission.
Don’t co-locate unrelated or non-production agents in the same project or runtime boundary. Shared runtime means one compromised agent can reach the rest.
Monitor playbook updates, code changes, tool additions, service-identity use, and unexpected outbound connections — the signals prompt logging misses.
OWASP’s 2026 guidance for Agentic Applications frames the risk clearly: autonomous and agentic AI systems plan, act, and make decisions across complex workflows. That makes them different from simple chatbots.
Rogue Agent is a practical example of that shift. The danger was not only that an AI response could be manipulated. The danger was that the surrounding application architecture created a path from an agent edit permission into runtime behavior.
This is where AI security starts to look more like application security, cloud security, IAM, and detection engineering — because that is exactly what it is becoming.
The likely mistake is overfocusing on the vendor name and underreading the pattern.
This is not only a Google Dialogflow CX story. It is also not a reason to avoid enterprise AI. The bigger lesson is that AI platforms are becoming orchestration layers. They sit between users, data, APIs, documents, support flows, cloud services, and business systems.
That makes the runtime valuable.
Attackers do not need to “break the model” if they can abuse the logic around the model. They do not need to defeat every AI guardrail if the platform gives them a path through permissions, code execution, shared services, or outbound access.
That is the real shape of the threat.
Rogue Agent should be read less as a one-off chatbot flaw and more as an early warning about AI runtime security.
The agent is not the boundary. The prompt is not the boundary. The model is not the boundary.
The boundary is the system around the model: permissions, code execution, tool access, service identity, logging, network egress, data access, and isolation between agents.
That is where enterprise AI risk is moving.
Sourcing: Rogue Agent details are based on Varonis Threat Labs’ disclosure of the Dialogflow CX issue, including the role of Playbook Code Blocks, the dialogflow.playbooks.update permission, the Google-managed Cloud Run execution layer, the April 2026 initial update, the June 2026 full resolution, and the statement that Varonis and Google were not aware of exploitation in the wild before the patch. Broader AI-agent risk framing draws from Google’s research on indirect prompt injection, Microsoft’s guidance on AI agents moving from reading to acting, and OWASP’s Top 10 for Agentic Applications 2026.
If you find ByteVanguard useful, you can support the site and help keep the analysis independent.
Support the analysis