A single permission in Google Dialogflow CX could have let an attacker with edit rights on one chatbot agent compromise every other agent in the same Google Cloud project. Varonis discovered the flaw, named Rogue Agent, in early 2024. Google shipped an initial fix in April 2026 and fully resolved it in June 2026.
No evidence suggests anyone exploited this in the wild. But the vulnerability reveals a fundamental problem in how you think about permissions in shared cloud runtimes: what looks like a configuration control can actually be a runtime execution path.
What Happened
Dialogflow CX lets you build conversational AI agents that handle customer interactions. The platform includes a Code Block feature where you can write custom logic in JavaScript or Python to extend agent capabilities.
The flaw centered on the dialogflow.playbooks.update permission. If you had edit rights on one agent that used Code Blocks, you could inject malicious code that would execute in the context of other agents in the same Google Cloud project. Those other agents didn't need to use Code Blocks themselves. The shared runtime environment meant your code could reach across isolation boundaries.
This required specific permissions. You couldn't exploit it from outside the organization. But an insider with legitimate edit access to a single agent, or an attacker who compromised such an account, could pivot to every other conversational AI workflow in the project.
Timeline
- Early 2024: Varonis security researchers discovered the vulnerability during cloud environment testing.
- Disclosure to Google: Varonis reported the finding through responsible disclosure.
- April 2026: Google released an initial fix addressing the core isolation issue.
- June 2026: Google deployed the complete remediation.
- No evidence of exploitation: Neither Google nor Varonis found indicators of real-world abuse.
The two-month gap between the initial and full fix suggests this wasn't a simple patch. Google likely needed to rearchitect how Code Block execution contexts were isolated across agents within a project.
Which Controls Failed
The vulnerability exposed three missing controls:
Runtime isolation between tenants sharing the same project space. Dialogflow CX treated agents as separate entities in the UI and API, but the Code Block execution environment didn't enforce that separation. An agent's custom code could access resources belonging to other agents.
Permission scoping that matched the actual blast radius. The dialogflow.playbooks.update permission appeared to grant edit rights on a single agent. The actual capability was broader: it let you inject code that could affect all agents in the project. The permission name and description didn't reflect the runtime reality.
Monitoring and detection for cross-agent access patterns. Even if you logged all Code Block executions, you'd need to correlate them with agent boundaries to spot one agent's code touching another agent's resources. Most logging configurations wouldn't catch this.
What Standards Require
ISO/IEC 27001:2022 Annex A.9.4.1 requires "restriction of access to information and information processing facilities." When you grant edit permissions on one agent, you expect those permissions to be scoped to that agent. The standard's access control objectives assume that permission boundaries match functional boundaries.
NIST 800-53 Rev 5 AC-3 (Access Enforcement) requires systems to "enforce approved authorizations for logical access." The authorization was "edit this agent," but the enforcement allowed "execute code that affects all agents." That's a control gap.
SOC 2 Type II CC6.1 requires logical access controls to be "consistent with the entity's business and security objectives." If your security objective is agent isolation, but your runtime doesn't enforce it, you're not meeting the criterion. Your auditor will ask how you verify that permissions work as documented.
PCI DSS v4.0.1 Requirement 7.2.1 states "access control systems are configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function." When a developer needs to edit one chatbot, they shouldn't automatically get runtime access to all chatbots. The requirement assumes your access control system knows the difference.
Lessons for Your Team
Map every permission to its actual runtime capabilities, not its UI description. Review your cloud service permissions quarterly. For each one, ask: "If an attacker had only this permission, what could they actually do?" Test it. The permission name and documentation often lag behind what the code allows.
Treat any code execution permission as a potential lateral movement path. If a service lets users run custom code, webhooks, Cloud Functions, Lambda functions, agent extensions, workflow scripts, assume that code can reach beyond its intended scope until you've verified the isolation. This applies to CI/CD pipelines, too. A permission to edit a GitHub Action in one repo might let you access secrets from other repos in the same organization.
Implement detection for cross-boundary access in shared environments. Set up alerts when:
- Code executing in Agent A's context accesses resources tagged to Agent B.
- A service account with permissions scoped to Project X makes API calls affecting Project Y.
- A webhook registered to one tenant sends data to another tenant's endpoint.
These patterns are rare in normal operations. They're loud signals of either misconfiguration or exploitation.
Segment your Google Cloud projects by trust boundary, not just by team. Don't put all your Dialogflow agents in one project because it's administratively convenient. If agents handle different data classifications or serve different customer populations, put them in separate projects. The project is often the actual isolation boundary, regardless of what the service documentation implies.
Require MFA and session recording for any permission that touches code execution. The Rogue Agent flaw needed the dialogflow.playbooks.update permission. That's an edit permission, not an admin permission. Your MFA policy probably covers admin roles. Extend it to any role that can modify executable logic: playbooks, workflows, functions, pipeline definitions.
Test your incident response for insider scenarios. Most tabletop exercises assume an external attacker. Run one where the threat model is "developer with legitimate access to System A uses that access to compromise System B." Your detection, containment, and communication plans will look different. You can't just block an IP or revoke all credentials, the person might need access to keep doing their job while you investigate.
The Rogue Agent vulnerability is fixed. But the pattern it exposed, permissions that appear narrow but enable broad runtime access, exists across every cloud platform you use. Your job is to find those gaps before someone else does.
