A Single Writable File Under Every Bot
Varonis Threat Labs has disclosed a vulnerability it calls Rogue Agent, and the mechanics deserve the attention of every enterprise now shipping conversational AI. In Google Dialogflow CX, agents that use Playbooks and custom Code Blocks let developers drop their own Python into the conversation flow. What Varonis found is that every one of those code-block agents inside a given Google Cloud project executes inside the same Google-managed Cloud Run environment, and that environment contained a single writable setup file, code_execution_env.py, that ran before every agent's code.
That design detail is the whole story. Because the file was writable and shared, an attacker who could edit one agent could replace that file with a malicious version pulled from an external server, and from that moment their code ran inside every other agent in the project. There was no meaningful isolation between agents that belonged to different teams, business units, or use cases but happened to share a cloud project. In our view this is the classic multi-tenant mistake, reproduced inside a managed AI service where customers could neither see the shared runtime nor reason about it.
What an Attacker Could Actually Do
The impact was not theoretical. With code running in the shared environment, an attacker could read live conversations across agents, harvest the data users typed into any bot, and access session state and variables that other agents held. More alarming for anyone who runs customer-facing bots, the attacker could make the compromised agents send attacker-written messages, including a polite request to re-enter a password. A chatbot that customers trust becomes a phishing surface that speaks in the brand's own voice.
Varonis reported two further gaps that compounded the first. Outbound internet access from the environment was unrestricted, which meant the malicious setup file could bypass VPC Service Controls and exfiltrate data to an arbitrary destination. The instance metadata service endpoint was also reachable, the same endpoint that has anchored a decade of cloud privilege-escalation research. Individually each is a misconfiguration. Together they turned an editing permission into a data-theft and impersonation primitive.
Who Could Have Exploited It
Context matters, and we should be precise about the threat model. Exploitation required the dialogflow.playbooks.update permission on at least one code-block agent. That is not a permission a stranger on the internet holds, so the realistic attacker here is a malicious insider or, far more likely, a compromised developer account. Given how routinely credentials leak through phishing, infostealers, and over-broad service accounts, that constraint is thinner comfort than it sounds. The set of people who can edit a bot is almost always larger than the set of people who should be able to read every conversation it handles.
This is where the finding intersects with how enterprises actually govern AI. Permission to build and iterate on an agent is handed out liberally because iteration speed is the point. But that same permission, under Rogue Agent, silently conferred read access to every other agent's traffic in the project. The lesson is not that Dialogflow is uniquely unsafe. It is that the permission models for AI-building tools were written for productivity, not for the blast radius those tools now carry.
A Seven-Month Timeline
Varonis reported the flaw through Google's Vulnerability Reward Program in November 2025. Google shipped an initial fix in April 2026 and fully resolved the issue in June 2026, roughly seven months from report to resolution, and no CVE was assigned. Google says all affected components are patched and that it found no evidence of exploitation in the wild before disclosure. That is the outcome everyone wants, and the responsible-disclosure process worked.
Still, a seven-month window on a shared execution plane is worth sitting with. During that time, any organization that built Dialogflow agents with custom code blocks was exposed to the class of insider and account-compromise scenarios described above, without any way to detect the shared-file weakness from their side of the managed boundary. Managed services trade control for convenience, and that trade is usually worth it, but it also means customers inherit the provider's remediation clock and cannot shorten it.
The Broader Lesson for Agent Platforms
Rogue Agent is a preview of a category of risk, not a one-off bug. The industry is racing to give agents the ability to run code, call tools, and act autonomously, and much of that execution is landing on shared, provider-managed infrastructure that customers cannot inspect. When the isolation boundary between a customer's own agents is weaker than the boundary they assume exists, the result is exactly this: an editing permission that quietly becomes a data-exfiltration permission. Traditional application security scanners see none of it because the vulnerable component lives inside the vendor.
For CISOs and platform owners, the practical takeaways are concrete. Treat the permission to edit an AI agent as sensitive as the data that agent touches, and scope code-execution capabilities to the smallest possible project boundary rather than pooling unrelated agents together. Demand isolation guarantees from AI platform vendors in writing, and log agent edits the way you log changes to production code. The agents are becoming production systems. It is past time to secure them like production systems.
