PUBLIC-EVIDENCE AI SECURITY CASE STUDY

A Shared Package Service Let One ChatGPT Account Run Tasks Inside Another

Check Point reproduced cross-account data relay through a shared JFrog Artifactory reachable from two otherwise isolated ChatGPT code containers. The attacker-controlled shared conversation induced victim ChatGPT to read connected Gmail and write data into cross-account item…

Tool-Calling LLM / Connected GenAITier 2Indicative ERS 4.0 (1.1–6.9)Evidence source date 2026-09-15

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.

Check Point reproduced cross-account data relay through a shared JFrog Artifactory reachable from two otherwise isolated ChatGPT code containers. The attacker-controlled shared conversation induced victim ChatGPT to read connected Gmail and write data into cross-account item metadata.

ASSESSED SYSTEM

The two-account researcher-controlled ChatGPT code-container and connected-Gmail configuration described by Check Point, specifically its shared Artifactory metadata boundary.

OUT OF SCOPE

Unrelated live victims, every ChatGPT container, active post-report exposure after Artifactory decommissioning, and production prevalence are outside scope.

Architecture: Tool-Calling LLM / Connected GenAI (decision tree Q3) — The assessed assistant invoked code and connected Gmail tools; independent longer-horizon autonomy is not established. Tier 2: Tier 2 representative public-facing service scenario; the original source does not establish every operator tier.

Documented attack or failure path

  1. Two researcher-controlled ChatGPT code containers under separate accounts could not communicate directly or reach the public Internet.
  2. Both reached a shared JFrog Artifactory with credentials that permitted mutable/readable item properties across accounts.
  3. The victim-side model followed a shared-conversation instruction, read connected Gmail, and relayed data through Artifactory metadata.

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.

  • Direct container-to-container communication and public Internet egress were blocked; OpenAI said the shared Artifactory instance was decommissioned by report completion.

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-metricScoreRubric basisEvidence
Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate
Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate
Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate
Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate
Containment (Cn) — scenario interval 0.03–0.91 (midpoint 0.47), Tier 2 MVT 0.55 indeterminate
Cn-1Scope Enforcement0.25w 0.12A basic isolation boundary existed yet a documented shared service let the model-controlled data path leave its intended account scope, matching Cn-1 0.25.Network/container isolation held, but the shared Artifactory credential and metadata surface permitted cross-account relay.source: primary report

Unknown, not N/A: 25 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

DimensionScoreJustification
AaAutonomy Amplification0.50w 0.25Representative activity level for the documented bounded AI path; deployment-specific autonomy was not measured.
AsAttack Surface Exposure0.75w 0.35Representative exposure of the documented entry path; this is a scenario assumption and not a census of all operators.
CpCascade Potential1.00w 0.20No verified System Dependency Graph or DGC is published, so framework worst-case Cp default applies.GDCP: worst-case default — no verified dependency graph published elevated
RfRemediation Feasibility0.50w 0.20A specific patch or configuration change is documented; repair feasibility is an inferred representative scenario, not measured recovery time.

Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.

Layer 3 — Public-evidence confidence diagnostic

ComponentScoreBasis
Pc — Public provenance evidence0.25Minimal public provenance identifies the affected path but supplies no operator assessment pack, signed configuration inventory, or repeated metric battery.
Ec — Public evaluation coverage0.03coverage 0.04 (1 of 26 applicable sub-metrics) × independence 0.80 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article.
Tf — Public-evidence freshness0.60Evidence dated 2026-09-08; age 40 days on the workpaper reference date. Components: C_monitor 0.60 · T_calendar 0.73. Binding term: C_monitor. Evidence reference is 2026-10-18, 40 days after earliest substantive public evidence (2026-09-08). C_monitor uses the conservative Tier 2 public-evidence default because usable monitoring-coverage evidence is unavailable; it does not assert no deployment telemetry. No C_event cap is asserted from research or an advisory without a dated victim incident. No generic C_evidence cap is assigned from missing public inputs. Indicative ERS uses normalized ACI = 1.00 for comparison only.

Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.16 — 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

Worp · ORP0.25(0.50) + 0.35(0.75) + 0.20(1.00) + 0.20(0.50) = 0.688
CRMNelevated = 1 → 1.00
ORPeffective0.688 × 1.00 = 0.688
Wivp · IVP midpoint0.25(0.50) + 0.30(0.50) + 0.15(0.50) + 0.20(0.50) + 0.10(0.47) = 0.497
IVP mitigation0.15 + 0.85(1 − 0.497) = 0.578
Scenario assuranceACI fixed at 1.000 for cross-case comparison; public-evidence ACI 0.164 is diagnostic only
Indicative ERS midpointmin(10, 0.688 × 0.578 × 1/1.000 × 10) = 4.0
Unknown-input interval1.1–6.9; 25 unknown applicable sub-metrics set to 1.00 / 0.00 at the bounds

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.0 midpoint, interval 1.1–6.9; 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.

No published CVSS score matching this exact assessed path was 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.

TechniqueDefence PriorityEvidences
AID-D-005.004Specialized Agent & Session LoggingExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routeTr-3 Cn-7
AID-H-018.002Policy-Based Access ControlExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routeCn-1 Cn-6 Cn-7
AID-H-018.003High-Impact Independent Validation & Approval GateExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routeCn-1 Cn-6 Cn-7
AID-H-018.004Intent-Based Dynamic Capability ScopingExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routeCn-1 Cn-6 Cn-7
AID-H-018.005Value-Level Capability Metadata & Data Flow Sink EnforcementExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routeCn-1 Cn-6 Cn-7
AID-I-001.004Sandbox Network Egress RestrictionsExact upstream page defense ID, verified against AIDEFEND dataVersion 2026.10.15. Presence supplies no score credit.Candidate evidence routePr-2 Cn-7

WHAT THIS CASE TEACHES

Check Point reproduced cross-account data relay through a shared JFrog Artifactory reachable from two otherwise isolated ChatGPT code containers. The attacker-controlled shared conversation induced victim ChatGPT to read connected Gmail and write data into cross-account item metadata.

Sources: Official AIDEFEND in Action brief · Check Point original controlled research, 2026-09-08

AITBM sub-metrics referenced