Two of enterprise software’s largest platforms disclosed, within the same week, that their AI agent products broke one of the most basic promises a multi-tenant system is supposed to keep: that one customer’s session or code cannot bleed into another’s. Google patched a flaw that let one Dialogflow CX agent take over every other agent in the same cloud project. GitHub confirmed a prompt injection path that let an anonymous commenter pull private repository data out of its new agentic workflows. Neither vendor was breached. Both disclosures point to the same structural problem: the features that make AI agents useful, shared execution environments, live previews, and issue trackers the agent reads as instructions, are also the surfaces attackers can use to cross a tenant or session boundary.

Google’s Dialogflow CX: One Code Block, Every Agent in the Project

Cloud security firm Varonis disclosed a vulnerability it named Rogue Agent in Google Cloud’s Dialogflow CX, the conversational AI platform enterprises use to build customer-facing chatbots. The flaw lived in Code Blocks, a Dialogflow Playbooks feature that lets developers embed custom Python inside an agent’s conversation logic. According to Varonis, that Python runs inside a Cloud Run environment shared across every Dialogflow agent in the same Google Cloud project, and the underlying file an agent’s code executes in, code_execution_env.py, was writable by anyone holding a single permission: dialogflow.playbooks.update on just one agent.

That meant a developer or attacker with edit rights on one low-value chatbot could overwrite the shared execution file and, in Varonis’s words, “silently take control of every agent in the same GCP project, manipulate conversations, and exfiltrate sensitive data without detection.” Daniel Reyhanian, a cloud security researcher at Varonis, described the effect as a trust problem, not just a code problem: “Like a turncoat spy who exposes colleagues to the enemy, our Rogue Agent could compromise other agents on the same project.”

Advertisement

CyberTech Your brand belongs here. Reach the decision-makers who read CyberTech every day. Premium placements across the site and newsletter. Advertise with us

The practical impact, per Varonis, included exfiltrating conversation data containing personal and payment details, injecting phishing prompts into legitimate chat sessions to harvest credentials, and bypassing VPC Service Controls, the network isolation layer many enterprises rely on to contain what a cloud workload can reach. Varonis reported the issue to Google in November 2025; Google shipped an initial fix in April 2026 and closed the issue fully in June 2026. Both companies say they found no evidence it was exploited before the patch.

GitHub’s Agentic Workflows: A Public Issue as the Attack Vector

Days later, security firm Noma Security disclosed a separate but related flaw in GitHub Agentic Workflows, the feature that pairs GitHub Actions with an AI agent (backed by Claude or GitHub Copilot) so teams can write automation in plain Markdown instead of YAML. Noma’s researchers found that a workflow configured to trigger on an issue being assigned would read the issue’s title and body as input, and treat that input the same way it would treat a trusted operator’s instructions.

Noma’s proof of concept, which it named GitLost, showed that an outside contributor with no repository access beyond the ability to open a public issue could plant instructions inside that issue and have the agent follow them, including instructions to pull and post back content the agent could read from a private repository in the same organization. Noma researcher Sasi Levi summarized the underlying weakness: “The agent’s context window is also its attack surface. Any content the agent reads, including a GitHub issue, can be weaponized if the agent treats that content as instructional input.” Noma says GitLost was responsibly disclosed to GitHub, which had knowledge of the details before they were published.

The Common Thread

Neither flaw required stolen credentials, malware, or a network intrusion. Both existed because the agent’s operating model quietly merged two things that classic application security keeps separate: content the system is supposed to execute or obey, and content a user, potentially an untrusted one, supplied. CyberTech has tracked prompt injection’s rise as the most exploited category of AI vulnerability in 2026, and these two disclosures show why: as vendors give agents more autonomy, read access, and shared infrastructure, the number of places an attacker can smuggle in an instruction grows faster than most security teams’ review processes.

Newsletter

Get the week's best tech coverage.

Free. Read by thousands of HR, tech, and business leaders.

What This Means for the Security Leader

Neither Dialogflow CX nor GitHub Agentic Workflows is a niche product. A CISO who has never heard of either may still be running them, since business units frequently adopt AI agent features inside platforms already licensed for other purposes, without a formal security review. Two implications follow.

First, tenant and session isolation cannot be assumed just because a platform is multi-tenant by design. Both flaws existed in production, patched, well-funded platforms from vendors with mature security programs. The isolation boundary a vendor advertises and the isolation boundary actually enforced in a shared execution runtime are not automatically the same thing, and that gap is where agent security work now needs to concentrate. Vendors such as Zscaler have begun building zero trust controls specifically for autonomous AI agents, treating each agent as its own identity to be brokered and monitored rather than trusting the platform’s default isolation.

Second, any workflow that lets an agent read unauthenticated or low-privilege input, a support ticket, a public issue, a shared chat, and then act on repositories, data stores, or other users’ sessions, is a prompt injection path until proven otherwise. That is true even when the input source seems mundane, since GitLost required nothing more than the ability to open a GitHub issue.

What to Do Now

  • Inventory every AI agent or chatbot builder in use, including ones adopted informally by marketing, support, or engineering teams, and ask each vendor directly whether execution environments, code sandboxes, or preview sessions are shared across customers or agents within an account.
  • For any agentic workflow that reads content from public or low-trust sources (issues, tickets, emails, web pages), restrict what actions the agent can take automatically, and require a human approval step before the agent can read from or write to anything outside the triggering context.
  • Apply patches for both disclosed flaws promptly; Google’s Dialogflow CX fix and GitHub’s mitigations are already live, so the remaining exposure is largely about configuration, not waiting on a vendor update.
  • Monitor agent and chatbot logs for anomalous session or token reuse across accounts, which is the operational signature both Rogue Agent and GitLost would have left behind had they been exploited.

Source: Varonis