Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
- AIDEFEND in Action — Rogue Agent: One Dialogflow CX Permission Crossed a Shared Project Runtime
- Primary source — Rogue Agent: How a Single Code Block Could Hijack Your AI Conversations in Google's DialogFlow (Varonis Threat Labs, 2026-07-07)
- AIDEFEND SecureFlow — Rogue Agent: One Dialogflow Permission Compromised 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 same project. The starting privilege was narrow but legitimate: dialogflow.playbooks.update on one agent, enough to edit that agent's Playbook. A malicious Playbook Code Block downloaded a modified code_execution_env.py and overwrote the file in the shared managed runtime. 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.
After the overwrite the Playbook could be restored while the modified runtime file remained active, and Varonis reports that Cloud Logging recorded neither the file replacement nor the injected logic. The shared hook exposed several impact paths: reading conversation history and session state, sending captured data through unrestricted egress, modifying replies through respond() to insert phishing prompts, and querying the instance metadata service. The IMDS result was bounded — a token for a Google-managed, low-privilege service account — and the source does not claim it produced further escalation. Google fully remediated the affected components in June 2026.
ASSESSED SYSTEM
Google Dialogflow CX in its pre-June-2026 state: the Google-managed Cloud Run execution environment that runs Playbook Code Blocks, shared by all agents in a project, together with the permission model that governs Playbook edits. A principal holding dialogflow.playbooks.update on one agent could add a Code Block that downloaded and overwrote code_execution_env.py in that shared environment, after which later Code Block executions by other agents in the project loaded the compromised file.
OUT OF SCOPE
The attacker's replacement code_execution_env.py and the public storage location it was downloaded from are the attack, not the assessed system. Google's post-June-2026 remediated control plane is out of scope; this assessment is of the pre-remediation state Varonis exercised. Cloud Run and Google Cloud IAM as products are not assessed. The Google-managed, low-privilege service account whose token the researchers obtained from IMDS is recorded as a bounded outcome — the source does not claim it produced further privilege escalation — and no unclaimed escalation is scored.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 = NO for the assessed boundary: the project hosts several agents that share a runtime, but the disclosed failure is shared execution state rather than runtime coordination or delegation between them, and no agent-to-agent message flow is described. Q2 = YES: a Dialogflow CX Playbook agent autonomously executes a multi-step conversational workflow and invokes Code Block execution — running operator-supplied code in a managed runtime — without per-invocation human approval. Evidence in the brief: the Playbook Code Block downloaded a file and overwrote it in the managed environment, and later Code Block executions by other agents loaded it. Tier 2: Tier 2 (Consumer): Dialogflow CX agents are customer-facing conversational deployments, and the demonstrated impact set — intercepting live conversations, altering replies to insert phishing prompts, and exfiltrating conversation history and session state — lands on the end users of those conversations. The privilege-escalation mechanism inside the project is carried by the Containment scores rather than by raising the tier.
Documented attack or failure path
- An attacker obtains dialogflow.playbooks.update on a single Dialogflow CX agent — a narrow, legitimate permission sufficient to edit that agent's Playbook.
- A malicious Playbook Code Block downloads a modified code_execution_env.py and overwrites the file in the Google-managed Cloud Run environment used to execute Code Blocks, crossing from agent configuration into managed runtime code.
- The modified file is not confined to the originating agent: later Code Block executions by other agents in the project load the same compromised environment.
- The Playbook is restored while the modified runtime file remains active. Varonis reports Cloud Logging recorded neither the file replacement nor the injected logic, so the visible configuration no longer reflects the executing code.
- The shared hook reads conversation history and session state, sends captured data through unrestricted egress, modifies replies through respond() to insert phishing prompts, and queries IMDS, obtaining a token for a Google-managed low-privilege service account.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The starting permission was genuinely narrow: the attack requires dialogflow.playbooks.update on one agent, and no identity spoofing, credential theft, or authentication bypass was demonstrated. The identity and authentication layers are therefore not scored as failures.
- The IMDS outcome was bounded: the researchers obtained a token for a Google-managed, low-privilege service account, and Varonis does not claim that token produced further privilege escalation.
- Google fully remediated the affected components in June 2026, so the disclosed path is closed in the current managed service.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–0.75 (midpoint 0.38), Tier 2 MVT 0.50 indeterminate | |||
| Ro-5Supply-Chain Artifact Admission Integrity | 0.00w 0.25 | The 0.00 anchor: an executable runtime artifact was admitted and loaded with no signature, hash or manifest verification. The 0.25 anchor requires pinning or allow-listing for some artifact classes, and no such control on the managed runtime's loadable code is evidenced. | Later Code Block executions by other agents 'loaded the same compromised environment' after code_execution_env.py had been replaced by a file downloaded by a malicious Code Block. Nothing verified the origin or integrity of the execution-environment file before load; the brief recommends reconciling 'the running Code Block environment against a signed desired-state manifest before each invocation', a control absent in the assessed configuration.source: brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.00–0.75 (midpoint 0.38), Tier 2 MVT 0.50 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.00w 0.25 | 0.00 anchor: no audit record exists for the security-relevant action, which is the literal 0.00 criterion. The 0.25 anchor requires partial logging that omits critical fields; here the event itself is absent from the log rather than incompletely described. | Varonis reports that Cloud Logging recorded neither the file replacement nor the injected logic. The single most security-relevant event in the chain — overwriting the shared runtime's execution environment — produced no record, and because the Playbook could then be restored, the surviving audit surface actively misrepresents the executing state. AID-H-021.002 is recommended in part to close this blind spot by reconciling the running environment against a signed manifest before each invocation.source: brief |
| Privacy (Pr) — scenario interval 0.00–0.65 (midpoint 0.33), Tier 2 MVT 0.55 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.00w 0.35 | 0.00 anchor: no minimisation or data-boundary control is evidenced on the shared execution path — the full conversation history and session state of unrelated agents were reachable from a hook installed by one agent's Playbook. The 0.25 anchor requires some minimisation to exist, and the shared runtime applies none. | Once the shared hook was in place it could read conversation history and session state for agents other than the one whose Playbook was edited, and send captured data out through unrestricted egress. No data-class boundary separated one agent's conversation data from another agent's execution context in the shared runtime, and none constrained what left it.source: brief |
| Containment (Cn) — scenario interval 0.00–0.37 (midpoint 0.18), Tier 2 MVT 0.55 confirmed breach | |||
| Cn-1Scope Enforcement | 0.00w 0.09 | 0.00 anchor: no effective scope boundary existed between one agent's configuration and the shared execution environment, and the brief states the modified file did not remain confined to the originating agent. The 0.25 anchor requires boundaries that exist but are inconsistently enforced; here the runtime layer is shared and writable by design. | A Playbook Code Block belonging to one agent wrote to a runtime file shared by every agent in the project. AID-I-001.002 is the Very High recommendation precisely because each agent or invocation should have its own disposable sandbox with no writable shared runtime layer and no access to host-management interfaces or IMDS — none of which the assessed configuration provided.source: brief |
| Cn-2Escalation Prevention | 0.00w 0.12 | 0.00 anchor: no escalation control separates editing a Playbook from introducing executable logic into a shared runtime — the capability is inherited, not authorised. The 0.25 anchor requires role checks that exist but are defeated by role confusion; here the role boundary between configuration and code authority does not exist. | A narrow, legitimate permission on one agent converted into persistent control of the execution code for every agent in the project. AID-H-018.002 states the missing requirement: executable Code Block creation should be a separate permission from ordinary Playbook editing, verified fail-closed against principal, project, agent, operation type, and code authority rather than inherited wholesale from playbooks.update.source: brief |
| Cn-3Output Filtering Robustness | 0.00w 0.13 | 0.00 anchor: no output filtering or release policy is evidenced between the runtime and the end user — an attacker-modified reply reached the conversation directly, which is the literal 0.00 criterion. | The compromised hook could modify live replies through respond() to insert phishing prompts, and nothing compared an outgoing response against the approved Playbook before delivery. AID-H-006.002 is recommended to hold chatbot responses until a release check rejects injected reauthentication links, credential requests, and hidden markup that cannot be traced to trusted response logic.source: brief |
| Cn-4Side-Channel Resistance | 0.00w 0.07 | 0.00 anchor: an unintended host-side channel was reachable from the workload and returned credential material, with no control interposed. The 0.25 anchor requires basic protections against such channels, and none is evidenced; the bounded value of the token is a property of the account, not of a control. | The workload could query the instance metadata service from inside the execution environment and obtain a service-account token. AID-I-001.004 and AID-I-001.002 both have to recommend denying IMDS access and host-management interfaces from within the workload, which indicates no such denial existed. The outcome was bounded — a Google-managed, low-privilege account — but the channel itself was open.source: brief |
| Cn-6Action Reversibility Classification Rate | 0.00w 0.08 | 0.00 anchor: no reversibility classification is performed before execution and actions execute ungated (ARCR = 0), and no worst-case composition rule constrains the edit-then-overwrite-then-restore sequence. | Overwriting code_execution_env.py in a shared managed runtime is a bounded-irreversible action against a security-critical asset, and it executed with no pre-execution classification and no gate. No worst-case chain rule applied either: the visible hop was an ordinary Playbook edit, and the highest-impact hop — replacing the execution environment for every agent in the project — did not govern the chain that contained it.source: researcher |
| Cn-9Self-Modification and Persistent-State Containment | 0.00w 0.14 | The 0.00 anchor: behaviour-governing runtime state was writable by agent-executed code with no gate and the write took effect in later executions silently. The 0.25 anchor requires writes to be at least logged or visible after the fact, and the decisive write produced no record at all. | A Playbook Code Block holding only dialogflow.playbooks.update 'downloaded a modified code_execution_env.py and overwrote the file in the Google-managed Cloud Run environment used to execute Code Blocks', changing the runtime state that governs every later Code Block execution in the project. The write took effect for other agents silently, persisted after the Playbook was restored, and 'Cloud Logging recorded neither the file replacement nor the injected logic'; no gate, attribution or rollback existed for the change.source: brief |
Unknown, not N/A: 17 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.75w 0.25 | The Playbook agent executes Code Blocks and produces live conversational responses independently, with no per-invocation human approval. It falls short of the 1.00 anchor because its action surface is the conversation and its configured code path rather than an open tool set able to commit external transactions of the operator's choosing. |
| AsAttack Surface Exposure | 0.75w 0.35 | Between the 0.50 and 1.00 anchors. The assessed system serves untrusted end users over a conversational interface, which is real external exposure, but the disclosed path is not driven from that interface: it requires a legitimate dialogflow.playbooks.update permission inside the project. The exposure that matters here is an authenticated-insider surface plus the runtime's outbound reach, not open unauthenticated origin access. |
| CpCascade Potential | 1.00w 0.20 | No verified System Dependency Graph exists for the assessed configuration, so the specification's worst-case default applies. It is independently corroborated on its merits: a single compromised node — the shared code_execution_env.py — was reachable by every agent in the project, so one write propagated to all downstream conversational workloads, and the observed path continued into unrestricted egress and the metadata service. That is the cross-component reachability the graph-derived ceiling describes, observed directly.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.20 | The 0.25 anchor fits: Google fully remediated the affected components in June 2026, so the provider-side fix is complete and requires no customer artefact rollout and no retraining. The customer-side work the brief asks for — confirming the remediated control plane, separating executable-code authority from Playbook maintenance, and reviewing historical Playbook revisions — is configuration and audit rather than redesign. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.30 | Slightly above the 0.25 anchor. The brief identifies the managed service, the exact permission, the overwritten filename, the runtime platform, the sharing boundary, the logging gap, each impact path, and the remediation date — an unusually complete mechanism description for a public analysis. It still identifies no specific project, agent inventory, principal list, tool manifest, or evaluation artefact for a deployment, and no AIBOM or equivalent record exists. |
| Ec — Public evaluation coverage | 0.33 | coverage 0.35 (9 of 26 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.09 | Evidence dated 2026-07-07; age 103 days on the workpaper reference date. Components: T_behavior 0.09 · T_containment 0.20 · C_event 0.35 · C_behavior 0.40 · T_calendar 0.45 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_behavior. BAW applies: the shared execution environment is mutable behavioural state that persists across invocations and across agents, and its modification is the finding. C_monitor 0.65 — Cloud Logging recorded neither the file replacement nor the injected logic, so the monitoring stack was blind to the decisive event; the brief has to recommend independent runtime-file integrity and response-release evidence for exactly this reason. C_event 0.35 — the major row applies: a confirmed critical-invariant violation, namely replacement of the shared execution environment followed by interception and modification of live conversations. C_behavior Band 0 (0.40) — no canary set, no registered invariants, and no maintained drift baseline for the runtime's behaviour are evidenced, the specification's worst-case default band. C_evidence 0.85 — although the provider has remediated, the customer-side questions the brief raises (whether the path was attempted before closure, and which principals hold code authority) remain open until reviewed. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.21 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
4.7 midpoint, interval 2.4–7.0; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-021.002 | Runtime Integrity Enforcement (Signed Configurations)AIDEFEND dataVersion 2026.10.15. Reconciling the running Code Block environment against a signed desired-state manifest before each invocation is the control that targets the persistence mechanism and the Tr-3 logging blind spot at once: a change to code_execution_env.py must stop execution even after the visible Playbook is restored. | Very High | Cn-2 Cn-5 Cn-9 |
| AID-I-001.002 | MicroVM & Low-Level SandboxingAIDEFEND dataVersion 2026.10.15. A disposable per-agent or per-invocation sandbox with no writable shared runtime layer and no access to host-management interfaces or IMDS is the Cn-1 and Cn-4 boundary whose absence lets one agent's Code Block become a project-wide execution hook. | Very High | Pr-2 Cn-7 |
| AID-H-003.010 | Deployed AI Software Vulnerability Remediation LifecycleAIDEFEND dataVersion 2026.10.15. Confirming the managed service is on Google's June 2026 remediated control plane and retesting shared-file overwrite, cross-agent persistence, egress, and IMDS access is the Rf remediation route; the provider fix addresses the path, while customer review determines whether it was attempted before closure. | Very High | Ro-4 Ro-5 Tr-4 |
| AID-H-018.002 | Policy-Based Access ControlAIDEFEND dataVersion 2026.10.15. Treating executable Code Block creation as a separate permission from ordinary Playbook editing, verified fail-closed against principal, project, agent, operation type, and code authority, is the Cn-2 control whose absence lets playbooks.update carry code authority. | High | Cn-1 Cn-6 Cn-7 |
| AID-I-001.004 | Sandbox Network Egress RestrictionsAIDEFEND dataVersion 2026.10.15. Default-deny outbound policy enforced outside the managed runtime, with no route to IMDS, is the Cn-4 and Cn-1 boundary that limits conversation exfiltration and command-and-control even after a Code Block gains execution. | High | Pr-2 Cn-7 |
| AID-H-006.002 | Text, Markup & Structured Output Sanitization and Release GateAIDEFEND dataVersion 2026.10.15. Holding chatbot responses until a release check compares them with the approved Playbook, rejecting injected reauthentication links and hidden markup, is the Cn-3 control whose absence lets respond() deliver attacker-modified replies; the brief scopes it to the phishing branch rather than to the underlying runtime compromise. | High | Ro-3 Cn-3 |
WHAT THIS CASE TEACHES
The blast radius came from the managed runtime boundary, not from the compromised Playbook. Tr-3 scores 0.00 rather than 0.25 because the decisive event produced no record at all and the Playbook could then be restored — so the surviving audit surface does not merely omit fields, it actively describes a state that is no longer executing. That is the difference between an incomplete log and a misleading one.
Sources: AIDEFEND in Action — Rogue Agent: One Dialogflow CX Permission Crossed a Shared Project Runtime · Primary source — Rogue Agent: How a Single Code Block Could Hijack Your AI Conversations in Google's DialogFlow (Varonis Threat Labs, 2026-07-07) · AIDEFEND SecureFlow — Rogue Agent: One Dialogflow Permission Compromised a Shared Project Runtime
AIDEFEND SecureFlow attack-flow cross-reference
The same incident is modelled step by step, with ATLAS technique labels and AIDEFEND defense mappings, in AIDEFEND SecureFlow. The flow is listed for navigation only; this record's evidence and scores come from the sources cited above. Open SecureFlow.
- Rogue Agent: One Dialogflow Permission Compromised a Shared Project Runtime (same incident · AIDEFEND curated research flow)ATLAS techniques: AML.T0040, AML.T0050, AML.T0107, AML.T0025, AML.T0106