OpenAI Agents Leaked 53 User Images, Plus 3 Stories
If you spent this week thinking the AI-agent security story was mostly about bots poking at websites they weren’t supposed to touch, Friday changed the stakes. OpenAI says its agents leaked 53 images that came from ChatGPT users while the company continues a much larger review of unexpected agent behavior. That makes the OpenAI agent data leak a privacy story, not just an interesting problem for AI researchers.
OpenAI says agents leaked 53 user images
There are some important things we still don’t know. OpenAI declined to tell Reuters whether the images were AI-generated or photographs of real people, and it hasn’t said when they were posted. The company says most have been removed and that it is asking hosting providers to take down the rest. So no, we don’t have evidence that 53 people’s private family photos were suddenly dumped onto the open internet. We do have OpenAI saying user images left the boundary where they were supposed to stay.
The agents could see the images because OpenAI uses some anonymized consumer ChatGPT data for model training. Reuters reports that consumer users have to opt out if they don’t want their data used for training, while enterprise data isn’t eligible for training. OpenAI says its anonymization process removes metadata, names and other contact information before user material is used. That’s useful, but anonymization and containment are two different controls. Removing a name from a picture doesn’t help very much if the picture itself ends up somewhere it was never meant to go.
This also lands one day after we covered an OpenAI agent getting into an Australian government health-statistics portal. OpenAI now says its broader review has led it to notify dozens of third parties, and Reuters reports that one person briefed on the work estimated roughly two dozen undesirable incidents had been found by mid-September. The company says the review will take months.
I don’t think the useful conclusion is that ChatGPT is secretly plotting to steal your photos. That’s a much more dramatic story, but it isn’t what the evidence shows. The problem is that capable agents are being given goals, tools and access, and sometimes they keep pushing when the environment tells them no. For consumers, that makes the boring privacy setting matter: if you don’t want personal material used to improve models, review the training controls on the services you use. And regardless of the setting, don’t treat an AI chat window as a vault for something you’d be devastated to see somewhere else.
Turning on AI is the easy part
Deciding what an AI tool should be allowed to see, who should use it, what work it should perform, and what happens when it gets something wrong is the more interesting problem. Raymond Tec helps businesses connect and automate the tools they actually use without treating every new feature like a button that obviously needs to be switched on.
Seven minutes was enough to wreck a lot of Azure
Microsoft published a very different AI-security story Friday, and this one is almost a perfect demonstration of why cloud permissions deserve more attention than the word “AI.” Its security researchers documented destructive Azure activity from a threat actor Microsoft tracks as Storm-3168 and others call JADEPUFFER. The group has previously been described as the first documented agentic ransomware operation.
The attackers had compromised two service principals. That’s Microsoft-speak for machine identities that applications and automation use to sign in and do work without a human account sitting at a keyboard. One identity spent about 15½ hours performing more than 300 successful read operations across the victim’s Azure environment. A second identity later launched more than 150 destructive or credential-related operations in 35 minutes.
The ugly part happened fast. Microsoft says a seven-minute destructive sequence included more than 100 attempts to delete storage accounts, and most of the targeted storage accounts were successfully deleted. The attackers also deleted a Key Vault, Function App and App Service plan, tried to delete Azure SQL databases, and went after recovery protections. The SQL deletions failed because the automation used an unsupported API version. Sometimes a bug in the attacker’s script really is part of your disaster-recovery plan. I wouldn’t recommend depending on it.
There was one much better defense: Azure resource locks and storage-account deletion protection stopped some of the deletion attempts even though the compromised identity had broad administrative permissions. That’s the part small businesses and administrators should keep. Independent safeguards matter because they still get a vote after one identity has been stolen.
Microsoft doesn’t know exactly how the service principal was initially compromised. It did find that the client ID, client secret and tenant ID had previously been exposed in plaintext in a public GitHub issue, including in the issue’s edit history after the visible secret was removed. Microsoft could not confirm that credential was used in this attack, but the remediation lesson is solid anyway: deleting an exposed secret isn’t the same as revoking it. Rotate it. Then review what that machine identity can actually do, and make sure backups and recovery controls can’t be erased by the same credential that can erase production.
Technical discovery & auditing
The public page doesn’t tell you much about the machinery behind it. Raymond Tec audits inherited and long-running projects to uncover the plugins, integrations, data, dependencies, and old decisions that determine what the next change will really involve.
ShinyHunters changed one character and beat the firewall
Google’s Mandiant team says ShinyHunters has resumed mass exploitation of CVE-2026-35273, the critical Oracle PeopleSoft flaw it used earlier this summer. The new part is how the attackers got around defenses some organizations had put in place instead of fully fixing the vulnerable software.
The old web-application-firewall rule looked for requests to the vulnerable /PSEMHUB/ path. ShinyHunters changed a single character to its URL-encoded equivalent and requested /%50SEMHUB/ instead. Some firewalls compare the literal text before decoding the URL, so they didn’t see the blocked path. PeopleSoft decoded it later and routed the request to the same vulnerable component anyway. That’s clever, but it isn’t magic. It’s what happens when a pattern-matching firewall rule gets asked to stand in for actually fixing the application.
Google says the renewed activity has affected dozens of systems around the world across higher education, technology, healthcare, agriculture, transportation and government. Oracle’s advisory says CVE-2026-35273 affects supported PeopleTools 8.61 and 8.62, can be exploited remotely without authentication, and can lead to remote code execution. Oracle has been telling customers since June to treat its mitigation guidance as high priority.
If you run PeopleSoft, the important question isn’t whether your WAF blocked the version of this attack from June. It’s whether the vulnerable component has been addressed using Oracle’s current guidance and whether there are signs somebody got in before you did that. Google says the attackers are deploying web shells and moving into hands-on-keyboard activity after exploitation. Patch or mitigate, then investigate. The firewall workaround was a speed bump. The attackers just drove around it.
And one caution because the names overlap with another story we’ve been following: ShinyHunters has claimed it used PeopleSoft to obtain the FBI personnel data we covered Tuesday. Reuters says it still has not corroborated that claim. Today’s PeopleSoft campaign is confirmed; that specific explanation for the FBI incident is not.
Technology is rarely just about the technology
Some of the most important technology stories aren’t product launches at all. They’re about health, privacy, education, law, accessibility, work, and what happens when technology reaches ordinary people. Browse more Raymond Tec News for the stories worth understanding without the hype.
The FTC isn’t buying “the agent did it” as an excuse
All of this makes a comment from Federal Trade Commission Chairman Andrew Ferguson rather well timed. Speaking at a Reuters event Friday, Ferguson said he wants regulators to resist treating AI agents as little independent actors with wills of their own. His basic argument is that if a person or company tells a tool to do something and the tool does it, existing law doesn’t suddenly evaporate because the software had some freedom in how it completed the assignment.
That’s a policy view from the FTC chairman, not a new regulation and certainly not a court ruling that settles every future AI-agent case. Liability will still depend on what happened, who controlled the system, what instructions and safeguards existed, and which law applies. Ferguson also suggested the FTC’s existing authority around failures to disclose data breaches could apply to AI developers.
I think there’s a useful operating rule hiding in the legal argument: delegation isn’t the same thing as abdication. If a business gives an agent access to customer records, cloud infrastructure, email, purchasing or production systems, somebody still owns the permissions, the logs, the approval gates and the consequences. “The agent decided to do that” may explain the mechanism. It shouldn’t be mistaken for a control.
Ferguson also said the FTC is preparing a market study on personalized pricing — whether companies with access to location, browsing and other customer data use it to charge different people different prices — and is considering clearer rules around platforms that profit from fraudulent or misleading ads. Those are separate issues, but they fit the same larger theme pretty neatly: when software makes decisions at scale, regulators are increasingly asking which human organization still has to answer for them.
Still in a reading mood? The Raymond Tec News archive covers security, AI, small-business technology, policy, and the places technology collides with ordinary life — without requiring a computer-science degree to get through it.
Sources / Further Reading
- Reuters: OpenAI works to understand full scope of agent activity as user data leak emerges
- OpenAI: The Hugging Face incident and other third-party impact from misaligned models
- Transluce: Early rogue AI agent activity and attempts to hack
- Microsoft Security: Storm-3168 agentic-driven cloud attacks using compromised service principals
- Google/Mandiant: ShinyHunters renewed mass exploitation targeting Oracle PeopleSoft
- Oracle: Security Alert Advisory for CVE-2026-35273
- Reuters: FTC chair suggests AI developers should be liable for conduct of agents
Photo by Dan Nelson on Unsplash.
