A protected model can still sit behind an unprotected service

An AI service can advertise confidential inference while another component on the same platform mishandles management access. A generated application can sit behind a login button while allowing an unrelated user to join its team. A retrieval system can enforce database rights and still send another tenant's content into a model. These failures have different owners and different evidence standards, although they are often compressed into the same phrase: AI data leakage.

The comparison is about control boundaries, not a common exploit or attacker. A private VM, an authorized document and a restricted URL each answer a different question.

Phala described an internet-accessible path to a loopback-trusting host-management service and unauthorized confidential virtual machines on two physical hosts. Its report then addressed a separate inference environment. Selected test credentials included in prompts on October 21 and 22 were subsequently used, offering a concrete observation of exposure. That does not prove a permanent passive tap across the precautionary incident window, nor does it identify an intrinsic failure of a hardware trusted execution environment. Investigators should distinguish management credentials, the VM guest configuration, request handling and the later external use of each canary.

The retrieval findings illustrate a different pathway. A correct backend database authorization test is insufficient if a retrieval adapter merges user contexts or a shared keyword-search index holds another tenant's data. The relevant artifact is the unauthorized document that reached the model, plus the principal and query that caused its selection. No host compromise is required for that failure mode.

Claroc tested 43,551 Grok app addresses and found 37,571 online; 35,578 of those opened without authentication. The researchers found organizational material in a subset, including apps created by employees of a prominent technology company, and demonstrated a separate OAuth team-enrollment mistake in an app they deliberately generated themselves. The second experiment cannot be projected onto tens of thousands of unrelated apps. Nor should the count of publicly reachable deployments be described as tens of thousands of confirmed malicious accesses. Publishing required an action, but the tested interface proposed an anyone-with-link setting; passive DNS made apparently obscure hostnames discoverable. The original research report distinguishes these observations.

The Fireworks investigation, by contrast, concerns a supplier that held customer-associated materials. Notion's decision to disconnect and revoke relevant integration keys is a remediation event, not a second compromise. Where tokens could have been exposed, the correct follow-up is a credential inventory, actual usage history and revocation receipt. An inability to confirm hostile token use must remain an uncertainty rather than an assertion that none occurred.

A useful review records a reachable endpoint, successful unauthorized access, the specific bytes observed, any outbound transfer, and subsequent credential or account use as separate stages. It then attributes each stage to its component: publishing UI, identity provider, retrieval adapter, model-serving host, application runtime or external vendor. Labels such as confidential, authenticated and private have no common security definition strong enough to replace this chain. The important comparison is the control that was promised against the precise effect that was actually observed.