When AI Chat Logs Become the Breach

What happened

302.ai is an AI aggregator. It sits between chatbot makers and users and gives access to a range of large language models (LLMs). Public reports identify its operator as Univerads Technology Limited, a Hong Kong company founded in 2020.

A publicly accessible Azure storage bucket held 17.6 million files totalling 22.72TB, according to research published by Cybernews. Roughly 9TB was images, 7.7TB video and 5.6TB audio.

The critical part was over 144,000 chat logs stored as JSON files. These contained prompts, replies the model used, token costs and timestamps, and in some cases personal details that users had typed in, such as birth dates, addresses and contact information. The bucket also held more than 26,000 ZIP files of conversation data, including summaries, inputs, outputs and attached files.

Additionally, the storage exposed chat logs from a customer support chatbot belonging to an unnamed adult products manufacturer. Other files ranged from LLM development research to private documents users had asked the service to analyse.

What 302.ai says it does, and what the bucket held

302.ai's own help pages, as documented in 2024 (the pages were last modified in late September 2024), describe a local-first design. Chat data is kept locally. Cloud sync exists but is manual: it is enabled by default as a feature, each upload is triggered by the user, and it is protected by a generated 4-digit password that can't be changed. The same help material describes sharing chats as text, images or JSON, and via links that let others continue the conversation. Marketing copy on the site says robot information is stored locally, with no data retention on the server side.

Set that beside a bucket holding 144,000+ chat logs and 26,000+ conversation archives. Whether this constitutes a direct contradiction depends on how 302.ai defines 'robot information' versus synced archives, API payloads, or shared links. Still, the gap between the documentation and the storage footprint raises three direct engineering questions:

1. Where did the logs in the bucket come from, and which product features wrote them there?
2. Why were conversation archives retained at that scale if server-side retention is described as absent?
3. If synced chats were stored in that bucket, how does a 4-digit password (at most 10,000 possible values) square with the claim that records can't be viewed without it? We have no evidence that this link exists. It is a question, not a finding.

What Azure requires for a container to be public

Per Microsoft's documentation, anonymous access to Blob storage is prohibited by default, and new storage accounts have disallowed it by default since the 2023 rollout. Existing accounts were not changed. There are two separate settings: an account-level switch that decides whether anonymous access is possible at all, and a per-container access level. The account setting overrides the container setting.

The practical reading is that data is not anonymously reachable unless someone sets a container's access level to allow it. Whichever way the account setting ended up, a person or an automation made a deliberate change to that container. Public reporting can't tell us whether the account was an older one with the permissive setting, or whether someone enabled it recently. It also doesn't say which level was used.

That difference changes how easily the data could have been found.

What we don't know

• When the exposure started, and whether anyone else found it first.
• Which Azure access level was set, and who at the company managed the bucket.
• Whether 302.ai or Univerads has made any statement or notified customers. As of our last check we found none, and the researchers said they had reached out and would update on a reply.
• Whether any regulator in Hong Kong or elsewhere has taken action.
• Whether 302.ai's current privacy policy still matches the version dated 22 September 2022, and which company operates the service.

How a company can limit the damage

A gateway that masks personal data before a prompt leaves the customer's network shrinks this exposure at the source. The comparison below assumes a company routed its staff's AI traffic through such a layer before it reached an aggregator, and asks what that same bucket would have held.

Mask identifiers before they leave

The 144,000 chat logs would still have existed, because masking doesn't stop a vendor from storing conversations. But the birth dates, addresses, and contact details that users typed in would have been replaced by placeholders, with the real values in a separate, access-controlled vault. Someone browsing the bucket would have seen conversation structures without the direct identifiers that make them harmful. That holds only for what detection catches: structured identifiers and names in free text are caught more reliably than implicit context, and images, audio, and attached files require their own inspection rules.

Keep a record of what was sent

The second change is knowing what was actually at risk. A gateway records what it allowed, masked or blocked, so after an incident a customer can answer the question defenders are told to start with: what did our staff send, and what reached the vendor unmasked? Without that record, working out what staff submitted means reconstructing it from whatever they remember.

What would not have changed

If the aggregator applied the same masking before storage, the bucket would have held less for every user. That depends on the vendor choosing to do it, which no customer controls.

What to take from this

The incident itself is ordinary: a storage bucket was left open, researchers found it, and it was closed. What makes it worth writing about is what was in it. AI intermediaries don’t just pass prompts along. They keep them as chat logs, summaries and archives, and once the door is open anyone can read them.

You can’t control a vendor’s storage settings. You can control how much a vendor receives in readable form, and whether you can say afterwards what you sent.

If your team has used 302.ai, start with three steps:

1. Work out what staff submitted.
2. Ask the vendor for the exposure period and access logs.
3. Rotate any credentials found in what was sent.

Longer term, treat every AI intermediary as a place your data will end up stored, and decide what it may hold before it gets there.

Sources

• Cybernews · original research on the 302.ai exposure, October 2026
• TechRadar · coverage of the incident
• eSecurity Planet · coverage of the incident and guidance for defenders
• Insurance Business · coverage of the incident and related cases
• Microsoft · Azure documentation and announcement on anonymous access to storage
• 302.ai · help center, website and privacy policy (dated 22 September 2022), as documented in 2024

Control what reaches your AI vendors.

Auvis intercepts data before external AI systems see it. It enforces your access rules, masks private fields in real time, and records every transaction in an audit log.

Read the docsStar on GitHub