Singapore's First AI-Linked Breach Was a Missing Bracket and an Unread Test Email
The PDPC's Bee Cheng Hiang case is mundane, which is exactly why teams shipping AI-written scripts should read it.
Singapore's Personal Data Protection Commission has disclosed the first AI-related data breach it has been notified of, and it is not the kind of incident AI-safety discussions usually focus on. On 25 April an employee at Bee Cheng Hiang, the bakkwa maker, used a generative AI tool to write a Python script that would send a marketing email to the company's mailing list in batches. The script had a missing bracket. As a result, every address in each batch of 1,000 went into the "To" field as a single entry, so each of 95,364 members could see up to 999 other members' addresses. The Straits Times reported the case on 30 September, and Mothership set out the details on 1 October.
Only email addresses were exposed. The company noticed the error, notified the PDPC on 27 April, stopped the sends, fixed the script and told affected members. The PDPC accepted a voluntary undertaking from the company on 2 September. The Edge, citing The Straits Times, reports that this was the company's first use of AI tools.
What "AI-related" means here
The label needs care. The PDPC itself pointed out that the exposed data was not handled or generated by any AI-powered process. The AI tool wrote a script; a person ran it. This is the oldest bulk-mail mistake there is, putting everyone in To instead of sending individually or using BCC, and the code just happened to come from a model.
The useful detail is how it slipped through. According to Mothership's account, the prompt never asked for recipients to be hidden from each other, and the employee checked the script's activity logs but never opened an actual test email. The logs said the emails were sent. They could not say what the recipients would see.
The lesson is about review, not models
A lot of AI-written code now runs in small businesses, written by people who are not developers, for tasks that feel too small to need review: a mailing script, a CSV clean-up, a one-off data export. The model writes plausible code quickly, and the author's confidence comes from the fact that it runs without errors. That is the gap this case exposes. A script can run perfectly and still do the wrong thing with personal data.
For engineering teams the takeaways are practical:
- Test what the recipient sees. For anything that sends data to people, send to a seed list of several internal addresses and inspect the received message and its headers. Logs tell you what happened on your side, not what arrived.
- State privacy requirements in the prompt and in the review. The model did what it was asked. Requirements like "each recipient sees only their own address" have to be written down by someone.
- Prefer a mail platform to a raw SMTP script. Email service providers send to each recipient individually by design. A hand-rolled loop over SMTP is where this class of mistake comes from.
- Use two-person checks for bulk sends. That is the control Bee Cheng Hiang adopted, and it is cheap. Most bulk-mail incidents would have been caught by a second person looking at one test message.
What to watch
The PDPC's handling is sensible. It treated this as a failure of the organisation's process, not something to blame on the tool, and resolved it through an undertaking instead of a penalty. That framing is likely to spread. Regulators in Singapore and elsewhere in the region are unlikely to accept "the AI wrote it" as a mitigating factor, and nor should they. Accountability stays with whoever runs the code.
Expect more cases like this, not fewer. The first AI-linked breach in many jurisdictions will look like this one: an ordinary mistake, made faster, by someone who did not know what to check. Clear guidance on reviewing AI-assisted scripts that touch personal data would do more good than another framework about model risk.
Sources