Validated Research Published: Aug 25, 2026

Rogue Agent: One Dialogflow CX Permission Crossed a Shared Project Runtime

Varonis showed that update rights on one Dialogflow CX agent could be converted into persistent control of a Google-managed Cloud Run execution environment shared by other agents in the project. A Playbook Code Block overwrote code_execution_env.py, after which the modified runtime could intercept conversations, alter live replies, exfiltrate data, and query instance metadata. Google fully remediated the affected components in June 2026.

Privilege EscalationData ExfiltrationRuntime IsolationTool AuthorizationEnterprise AI
6 applicable AIDEFEND defenses
Source: Rogue Agent: How a Single Code Block Could Hijack Your AI Conversations in Google's DialogFlow 
Author: Daniel Reyhanian (Varonis Threat Labs)
Original article: Jul 7, 2026

Threat Analysis

  • The starting privilege was narrow but legitimate. The attacker needed dialogflow.playbooks.update on one Dialogflow CX agent, enough to edit that agent's Playbook.
  • A Code Block crossed from agent configuration into managed runtime code. The malicious Playbook downloaded a modified code_execution_env.py and overwrote the file in the Google-managed Cloud Run environment used to execute Playbook Code Blocks.
  • The runtime was shared across project agents. The modified file did not remain confined to the agent whose Playbook was changed. Later Code Block executions by other agents loaded the same compromised environment.
  • The attacker could hide the visible change. After the overwrite, the Playbook could be restored while the modified runtime file remained active. Varonis reports that Cloud Logging recorded neither the file replacement nor the injected logic.
  • The shared hook exposed multiple impact paths. It could read conversation history and session state, send captured data through unrestricted egress, modify replies through respond() to insert phishing prompts, and query IMDS.
  • The IMDS result was bounded. The researchers obtained a token for a Google-managed, low-privilege service account. The source does not claim that this token produced further privilege escalation.

Applicable AIDEFEND Defenses (6)

AID-H-021.002
Runtime Integrity Enforcement (Signed Configurations)
Very High
Reconcile the running Code Block environment against a signed desired-state manifest before each invocation. A change to code_execution_env.py must stop execution even if the visible Playbook has been restored. This targets the persistence mechanism and the logging blind spot at the same time.
AID-I-001.002
MicroVM & Low-Level Sandboxing
Very High
Give each agent or invocation its own disposable sandbox with no writable shared runtime layer. Deny access to host-management interfaces and IMDS from inside the workload. This prevents one agent's Code Block from becoming a project-wide execution hook.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Confirm that the managed Dialogflow service is on Google's June 2026 remediated control plane, then review historical Playbook updates and retest shared-file overwrite, cross-agent persistence, egress, and IMDS access. The provider fix addresses the disclosed path, while customer review determines whether it was attempted before closure.
AID-H-018.002
Policy-Based Access Control
High
Treat executable Code Block creation as a separate permission from ordinary Playbook editing. A fail-closed policy must verify the principal, project, agent, operation type, and code authority before allowing executable logic, instead of inheriting all capability from playbooks.update.
AID-I-001.004
Sandbox Network Egress Restrictions
High
Enforce network policy outside the managed runtime: outbound connections should be blocked by default, with no route to IMDS and only approved destinations allowed. This limits conversation exfiltration and C2 even if a Code Block gains execution.
AID-H-006.002
Text, Markup & Structured Output Sanitization and Release Gate
High
Hold chatbot responses until a release check compares them with the approved Playbook and policy. Reject injected reauthentication links, credential requests, and hidden markup that cannot be traced to trusted response logic. This specifically constrains the phishing branch, not the underlying runtime compromise.

What Defenders Should Do Now

  • Confirm with Google Cloud that affected Dialogflow CX environments are on the remediated control plane. Retest the exact overwrite and cross-agent persistence behavior in a non-production project.
  • Inventory principals with dialogflow.playbooks.update and determine which can also add or change Code Blocks. Separate executable-code authority from ordinary Playbook maintenance.
  • Review historical Playbook revisions, Code Block source, public-storage downloads, unexpected respond() behavior, outbound destinations, and IMDS attempts around privileged changes.
  • Require isolated, disposable execution environments for Code Blocks. Verify that no writable interpreter, library, cache, or helper file is shared across agents or tenants.
  • Block IMDS and default-deny egress outside the workload. Permit only named destinations required by an approved Playbook.
  • Add independent runtime-file integrity and response-release evidence because the disclosed Cloud Logging path did not record the overwrite or injected logic.

Conclusion

Rogue Agent converted a legitimate update permission on one agent into control over execution code shared by the project. The blast radius came from the managed runtime boundary, not from the compromised Playbook alone.

AIDEFEND  places the primary breakpoints at AID-H-021.002 signed-state reconciliation and AID-I-001.002 per-agent isolation. AID-H-018.002 narrows who may introduce executable logic, while AID-I-001.004 and AID-H-006.002 constrain the egress and response paths that remain after code execution.