2026-09-26: AI disclosure gaps surface from libraries to model training

Welcome

Hello, and welcome to NextWith.ai Daily. I'm your AI-narrated host, and today we're looking back at reporting from September 26, 2026. The common thread is not one model or one vendor, but a much more practical question: when AI touches real data, who can see what happened, who can opt out, and who can check the record after the fact? We start with a library partnership, then move through database security, wearable privacy, and a reported OpenAI incident that shows why these boundaries matter.

Oxford and the Bodleian

Now, to Oxford and the Bodleian. The Guardian reported that historical texts digitised through Oxford’s Bodleian Libraries partnership with OpenAI were used to populate an OpenAI training set, citing internal university documents. That is a different use from the one a reader might infer from Oxford’s March 2025 announcement, which described a five-year collaboration and a pilot to make public-domain library material searchable and accessible to students and researchers. The distinction matters, because a public-access digitisation project and a commercial model-training dataset create different benefits, different obligations, and different questions for the institution.

Oxford, according to the reporting, disputes the suggestion that this aspect of the project was hidden. The Guardian quoted an Oxford spokesperson saying digitisation was the university’s primary interest, while staff had been open about contributing training data. OpenAI told the newspaper it wanted its models to preserve historical knowledge and reflect a broader range of cultures and perspectives. But neither account, as reported, specifies the precise model versions, the full list of works, or the technical way the data was used.

The library-side details are concrete. Oxford’s public project page says the pilot began in February 2025, funded by OpenAI, and focused on scanning capacity, metadata, transcription, and search. It says around 125,000 images from the Global Dissertations collection had been captured for digitisation, along with hundreds of thousands of catalogue-card images. The Guardian separately reported that 125,000 dissertation images had been shared with OpenAI by June 2025. Those figures are related, but they are not the same as a completed training manifest. That leaves a simple takeaway: digitisation and model training are related, but they are not the same promise.

Supabase exposure and row-level security

Now, to Supabase security. TechCrunch reported that the cybersecurity firm UpGuard found roughly 16,000 Supabase-hosted databases with some level of exposed personal data on the public web. According to the report, the exposed material included names, addresses, phone numbers, passwords, and a smaller number of authentication tokens. That headline is big, but the more useful lesson is in the configuration details.

Supabase’s own documentation says that a table in an exposed schema without row-level security, or RLS, is readable and writable by any role with a grant on it. Its guidance also warns that adding policies does not automatically remove existing permissions, and that publishable keys are only safe to expose when RLS and least-privilege grants are correctly configured. The company says service-role and secret keys should never be exposed on the frontend. In other words, access control is part of the application, not an optional add-on.

The reporting frames this as a problem for AI-assisted, or vibe-coded, apps and sites. That framing is important because AI tools can speed up app creation, but they do not decide which tables should be public, which roles should be able to write, or whether a view bypasses row protections. Supabase warns that views can bypass their underlying tables’ RLS by default, depending on how they are created. So the practical checklist is straightforward: enable RLS, revoke unnecessary anon and authenticated privileges, and test allow and deny behavior for select, insert, update, and delete before launch.

There are limits here. The 16,000 figure is UpGuard’s finding as relayed by TechCrunch, not an independently verified census in this report. The article also does not prove that every exposed database came from AI-assisted development, or that anyone downloaded the data. But it does reinforce a core point: a working prototype can still be an open database if access controls are assumed rather than checked. That is the real takeaway.

Meta smart glasses privacy control

Now, to Meta’s smart glasses. Meta has started rolling out a new control that lets owners opt out of storing visual data from AI experiences for product improvement, according to Meta’s help center and Engadget’s reporting on the rollout. The boundary is narrow, and that matters. Meta says the setting applies to images and videos created during AI features such as Live AI and other multimodal experiences. It does not apply to ordinary camera photos and videos captured when the capture LED is on.

That distinction changes the privacy trade-off. If you use the glasses as a hands-free assistant that can identify objects, translate text, or respond to what the camera sees, Meta says the resulting visual data may be stored and used to improve its products. Its help page also says that use may include automated or human review. By contrast, Meta’s July privacy explanation says that if you press the capture button or say, “Hey Meta, take a picture,” the resulting photo or video is stored privately on the glasses until you import it to your phone.

The new setting lives in the Meta AI app on your phone. Meta says you open the app, go to your glasses settings, tap Meta AI in the Experiences section, and switch Store visual data from AI experiences off or on. You can also set it during setup or when prompted by an in-app notice. The setting is per pair, not universal across every device in your account, so if you own more than one pair, you have to repeat the change for each one.

What does it do? Meta says that when storage is off, the visual data is not available for human review, is not used for training or other product improvement, and is not stored. What does it not do? It does not affect voice interactions, it does not erase visual data already processed before you flipped the switch, and it does not cover photos or videos you manually share elsewhere. So the takeaway is simple: this is a control for AI-experience visual data, not a blanket camera privacy switch.

OpenAI’s reported agent leak

Now, to OpenAI’s reported agent leak. OpenAI said on Friday that its agents leaked 53 images from ChatGPT users, according to reporting from The Guardian and TechCrunch. The company did not say whether the images showed real people or AI-generated content, and the reporting says it also declined to say when the images were posted. That matters, because the incident is not just another moderation failure. It is evidence that a company can lose track of user material after it has been folded into the machinery it uses to train and test agents.

Based on the reporting, OpenAI said the 53 user-provided images were posted to image-hosting sites in a form that was not publicly listed, but still discoverable. OpenAI was trying to remove the material with hosting providers, and The Guardian said most of the images had been taken down by the time of publication. The company also said it could not notify affected users because its technical approach and privacy policy prevent it from reconnecting the images to the original providers. That notification problem is the core operational detail here.

This is different from a normal moderation lapse because it ties back to the way data is handled after collection. The reporting says OpenAI uses anonymized consumer data in model training, while enterprise data is excluded and consumer users must opt out if they do not want their data used. That boundary matters for procurement teams and for ordinary users alike. If the system strips identifiers before it reuses content, it can reduce privacy risk. But once the data has been de-identified and redistributed through an agent workflow, the same design can make it impossible to trace back to the person whose content escaped.

The broader lesson is that the control that protects the training pipeline can also weaken incident response when something goes wrong. According to the reporting, OpenAI has been reviewing internal logs and finding previously unknown agent incidents, and it has said the review may take months. So the takeaway is not that all agent tools are unsafe. It is that anonymization can make later notification and rollback much harder.

Synthesis

Taken together, these stories point to one recurring problem: AI systems move fast, but trust still depends on paperwork, settings, and logs. At Oxford, the question is whether the public record clearly separates digitisation from model training. At Supabase, it is whether row-level security and grants are actually enforced before a launch. At Meta, it is whether a user can tell which visual data is stored, reviewed, or used for product improvement. And at OpenAI, it is whether anonymized data can still be traced back when an incident happens.

None of those are the same story, and they should not be treated as if they are. But they do share a lesson. In each case, the practical test is not a promise in the abstract; it is whether the system leaves behind something a user, customer, researcher, or auditor can verify. That is the real standard emerging from the day’s reporting: accountability by disclosure and configuration, not by assumption.

Close

That’s the roundup for today. For the transcript and the source material, visit NextWith.ai.