What happened

WotNot is an Indian AI startup that sells a chatbot-building platform. The pitch is the familiar one: businesses use WotNot to stand up customer-facing chatbots that answer questions, collect information, and shuttle people through support and intake flows without a human on the other end. WotNot has advertised a customer roster that includes recognizable names such as Merck, the University of California, and Amneal Pharmaceuticals, and it reports serving thousands of companies.

When a company builds a chatbot to talk to its customers, the chatbot inevitably becomes a place where people upload things. A pharmaceutical or healthcare-adjacent bot asks you to attach your medical records. A travel bot wants your itinerary and your passport. A recruiting or onboarding bot asks for your resume and your ID. So as end users interacted with chatbots built on WotNot, they handed over exactly the documents you would least want sitting on the open internet: passport and national ID scans, detailed medical records, resumes, and travel itineraries.

All of those uploaded files landed in a Google Cloud Storage bucket. And that bucket was configured to allow public access.

Researchers at Cybernews discovered the open bucket on August 27, 2024. Inside were 346,381 files. No login, no authentication, no special tooling required - the kind of access where if you had the URL, you had the data. The exposure was reported publicly in early December 2024, after the researchers' attempts to get it closed.

What actually broke

It would be easy, and a little dishonest, to file this purely under "AI gone wrong." It is more accurate to say the AI was the collection layer and a plain old cloud misconfiguration was the malfunction.

The actual root cause is one of the most boring and most common failures in all of cloud computing: a storage bucket whose access policy was left open to the public internet. WotNot's own explanation, as reported, was that the bucket's policies had been modified to accommodate a specific use case - reportedly for free-tier customer support - and that the company missed verifying whether the change had left the data accessible. That is not a story about a hallucinating model or a rogue agent. That is a story about someone changing an access rule and not checking what it exposed. The same mistake has leaked data out of buckets belonging to companies that have nothing to do with AI.

So why does it belong in a graveyard of AI failures at all? Because the AI is what made the bucket worth caring about. A chatbot platform's entire function is to sit in front of customers and collect what they type and upload, across thousands of client deployments. That is a sensitive-document funnel by design. WotNot's chatbots aggregated passports, medical files, and IDs from end users of many different companies into one place, and then that one place was left open. The misconfiguration is generic; the concentration and sensitivity of what got concentrated is a direct product of building an AI chatbot intake layer. The model did not break. The model's job was to gather exactly the material that the broken bucket then exposed.

This is a distinction worth keeping straight, because "AI did it" and "AI made the consequences worse" are different claims, and only the second one is true here.

Two months to close an open door

The timeline is the part that turns this from an unfortunate slip into a genuine failure of operations.

The bucket was discovered open on August 27, 2024. According to the reporting, Cybernews moved to notify WotNot, and the company then took more than two months to actually secure the misconfigured bucket, despite repeated notifications. For most of that window, hundreds of thousands of passport scans, medical records, and resumes belonging to other people's customers remained readable to anyone who looked.

Closing a public bucket is not a hard engineering problem. It is a configuration change, the same kind of change that opened the bucket in the first place. The fix is, at most, hours of work and usually minutes. So the two-month gap is not a story about technical difficulty; it is a story about an organization that either did not treat "we are leaking customers' passports" as an emergency or did not have the internal process to act on the notification quickly. Either way, the delay multiplied the exposure window for data that, once copied, cannot be un-copied.

WotNot has indicated that the exposure primarily affected its free-plan deployments, and that enterprise customers receive private, more tightly controlled instances. That is a meaningful mitigation for the named enterprise logos. It is also cold comfort to the actual human beings whose passports and medical records were in the open trove: they were end users interacting with some chatbot somewhere, almost certainly with no idea what "WotNot" is or that their uploaded ID was sitting in a publicly readable bucket.

Confirmed harm versus exposure

What is confirmed: a bucket containing 346,381 sensitive files was publicly accessible, the files included passports, national IDs, medical records, resumes, and travel itineraries, the open state was discovered on August 27, 2024, and it remained open for more than two months afterward. Those facts are documented across independent reporting.

What is not confirmed: that any malicious actor found and exfiltrated the data before it was secured. There is no public evidence of confirmed exploitation. This is an exposure-and-near-miss case, not a proven theft.

But that uncertainty should not be read as reassurance, and here is why. Data left readable on the open internet can be scraped, copied, and redistributed without leaving any trace on the source system. The bucket owner sees no break-in, because there is nothing to break into. So "no evidence of malicious access" and "the data was definitely safe" are not the same statement, and with a two-month-plus open window on a trove of government IDs, the prudent assumption is that anyone affected should treat their exposed documents as potentially compromised. For passports and national IDs specifically, that is not a "rotate your password" situation. You cannot reissue your face, your date of birth, or your passport number as easily as you can change a leaked password.

What it teaches

Two lessons fall out of this one, and they pull in slightly different directions.

The first is the unglamorous, perennial one: your cloud storage buckets are public until you have actually verified they are not, and "we changed a policy for one use case" is exactly the moment those verifications get skipped. This has been true since long before AI, and it will keep mattering long after. The novelty in 2024 was not the misconfiguration. It was the size and sensitivity of what a misconfiguration could now spill.

The second lesson is the AI-specific one, and it is the reason this story sits here rather than in a generic breach roundup. When you build a chatbot platform, you are building a machine whose purpose is to get people to hand over information easily, including the most sensitive documents they own, and to do it across many customers at once. That machine is a honeypot whether or not you intended to build a honeypot. The security obligations of operating it are correspondingly heavier than for an ordinary app, because the consequence of one careless access-policy change is not your own data leaking but your customers' customers' passports and medical records leaking. WotNot built the funnel and then, for over two months, left the bottom of it open.