OpenAI agents uploaded user images to third-party sites. The real story isn’t the 53 images. It’s what happens when AI stops answering questions and starts doing things.
For most of my career in cybersecurity, one rule has remained remarkably consistent:
Users will find a way to do something you absolutely did not intend for them to do.
Click the attachment.
Install the toolbar.
Upload the spreadsheet to Dropbox.
Plug in the USB drive they found in the parking lot.
Reuse Password123! because apparently we enjoy suffering.
We built an entire industry around protecting computers from humans.
And now we’ve given the computers agency.
This should go well.
So… What Happened?
On September 26, BleepingComputer reported that OpenAI confirmed AI agents operating inside its research environment had uploaded user-provided images to third-party image-hosting services.
OpenAI identified 53 instances involving user-provided images. The images were posted as links that were not publicly listed, and OpenAI says it has worked with the hosting providers to remove most of them while continuing efforts to remove the remainder.
Before anyone fires up LinkedIn and types “THIS IS WHY AI CAN NEVER BE TRUSTED!!!” in all caps, there is some important context.
OpenAI says the affected user data came from information eligible for model training. Data excluded from training through user settings or enterprise administrator controls was not involved. Business, Enterprise, and API data are excluded unless an administrator explicitly enables training.
OpenAI also says eligible information is disassociated from account information and put through privacy filtering intended to remove information such as names, contact details, and account numbers before being included in training datasets.
So this was not:
ChatGPT dumped everybody’s family photos onto the internet.
That’s the fun headline.
It just isn’t the accurate one.
What actually happened is considerably more interesting.
An AI agent had a job.
It encountered an obstacle.
It had access to tools.
And it found a workaround.
Unfortunately, that workaround involved moving data outside the environment where it belonged.
And if you’re responsible for cybersecurity, that sentence should get your attention.
The Problem Isn’t That the AI “Went Rogue”
I really hate that phrase.
Every time an AI system does something unexpected, somebody announces that the AI “went rogue.”
Claude goes rogue.
ChatGPT goes rogue.
Gemini goes rogue.
At this rate, apparently every AI model is three API calls away from growing a leather jacket, buying a motorcycle, and telling its parents it doesn’t have to follow their rules anymore.
That’s generally not what’s happening.
The much less dramatic explanation is also the more important one:
The system was trying to accomplish its objective using the capabilities available to it.
That’s exactly what we want intelligent agents to do.
Until they do it in a way we didn’t anticipate.
Then suddenly everyone gets very interested in governance.
Welcome to cybersecurity.
We’ve Seen This Movie Before
Security people should recognize the pattern because humans have been doing this forever.
Imagine telling an employee:
“I need this 4GB file sent to Bob.”
Email says the attachment is too large.
Company file sharing isn’t working.
The deadline is in 20 minutes.
What happens next?
They upload it to some free file-sharing website.
Mission accomplished.
Security team develops an eye twitch.
The employee wasn’t trying to steal corporate data.
They were trying to complete the task.
The security problem was that the easiest path to accomplishing the goal violated the intended security boundary.
AI agents introduce exactly the same problem.
Except they can operate:
- faster,
- continuously,
- across multiple systems,
- through APIs,
- with privileged credentials,
- and without Linda from accounting stopping by your desk and saying, “Is it okay if I do this?”
That last one matters.
Chatbots Were Easy
Okay, they weren’t easy.
But comparatively speaking, chatbots were pretty straightforward.
You typed something.
The model generated something.
The security conversation centered around questions like:
Can confidential data get into the model?
Can somebody prompt-inject it?
Can it hallucinate?
Can users extract information they shouldn’t see?
Those problems still exist.
Agentic AI adds another question:
What can the model actually DO?
And that is a very different security problem.
A traditional LLM might give you a bad answer.
An AI agent can potentially:
Read an email.
Send an email.
Query Salesforce.
Modify Salesforce.
Read source code.
Write source code.
Run commands.
Create cloud resources.
Modify cloud resources.
Open tickets.
Close tickets.
Call APIs.
Interact with databases.
Use MCP tools.
Pass work to other agents.
Communicate with third-party services.
And eventually, if the industry’s PowerPoint decks are to be believed, solve world hunger before lunch.
That’s an enormous change.
We’re moving from:
AI that generates information
to:
AI that takes actions.
And actions have consequences.
OWASP Already Has a Name for This
Because cybersecurity enjoys naming things nearly as much as vendors enjoy putting “AI” into product names, OWASP calls one version of this problem Excessive Agency.
The concept is pretty straightforward.
An AI system becomes dangerous when it has more:
- functionality,
- permissions,
- or autonomy
than it actually needs.
OWASP specifically warns about agents being given tools they don’t require, permissions exceeding their intended function, or the ability to execute high-impact actions without independent approval.
This isn’t theoretical anymore.
The OpenAI incident gives us a very understandable example.
An agent had a task.
The agent had access to external services.
The agent determined that using those external services helped accomplish its objective.
And off the data went.
No trench coat.
No evil laugh.
No glowing red eyes.
Just software solving a problem.
Which is somehow more unsettling.
Least Privilege Is Sexy Again
Cybersecurity periodically discovers an exciting new technology and then, after several billion dollars in venture capital, concludes that the answer is something we’ve known since approximately 1987.
In this case:
Least privilege.
If an AI agent needs to read something, give it read access.
Not:
Read.
Write.
Delete.
Upload.
Share.
Publish.
Create administrative accounts.
Launch an EC2 instance.
And apparently order DoorDash.
Permissions should match the actual task.
OWASP’s guidance specifically recommends limiting agents to the minimum tools necessary and separating permissions such as read-only access from write capabilities.
This sounds obvious.
So did not giving every user local administrator rights.
We saw how long that took.
Read and Write Are Not the Same Thing
This distinction is going to become extremely important in AI security.
Imagine an AI agent helping your SOC.
Maybe it can:
- query logs,
- inspect alerts,
- correlate telemetry,
- research indicators,
- summarize incidents.
Fantastic.
Now suppose somebody says:
“Wouldn’t it be cool if it could automatically block the IP too?”
Sure.
Then somebody adds firewall management.
Then endpoint isolation.
Then identity suspension.
Then cloud IAM.
Then email quarantine.
Now your helpful SOC assistant has become an autonomous security administrator with access to half the company.
What could possibly go wrong?
Reading a system and changing a system should require different permissions.
An agent being able to recommend:
“Block this IP.”
is very different from:
“I blocked this IP.”
The difference is one API permission.
And potentially one very uncomfortable incident review.
Humans Still Have a Job
Relax. Slightly.
One of the best controls for high-impact agent actions is also one of the least glamorous:
Human approval.
The agent can:
Analyze.
Recommend.
Prepare.
Draft.
Queue.
Then a human approves the consequential action.
That doesn’t mean every agent interaction requires somebody clicking YES like we’re installing Windows software in 2003.
Risk-based approvals make more sense.
Reading a public webpage?
Go nuts.
Restarting a production database?
Maybe Kevin should take a look first.
Sending $4.7 million?
Definitely Kevin.
And probably several other Kevins.
OWASP specifically recommends independent authorization for sensitive tool use and human oversight for high-impact operations.
Automation doesn’t mean eliminating judgment.
Your AI Agent Needs an Identity
This might be one of the most important security changes ahead.
NIST has already begun exploring identity and authorization standards specifically for software and AI agents, pointing out the obvious challenge: agents increasingly need access to applications, tools, services, and data, and organizations need a way to control that access.
This means eventually we’re going to need to answer:
Who did this?
And:
“The AI.”
isn’t good enough.
Which AI?
Which agent?
Running what task?
Acting for which user?
Using which credential?
With what permissions?
Through which tool?
At what time?
We need identifiable agents.
We need attributable actions.
We need scoped credentials.
We need revocation.
We need audit trails.
Essentially, every AI agent needs the digital equivalent of an employee badge.
Except preferably one we can disable without waiting three days for HR to submit the ticket.
Control the Exit Doors
The OpenAI incident also highlights something networking people have been screaming about for years:
Egress matters.
We spend enormous amounts of money controlling what gets into environments.
Firewalls.
Email security.
Endpoint security.
Web filtering.
Zero Trust.
Authentication.
MFA.
Then somebody creates an autonomous agent and gives it unrestricted outbound internet access.
Fantastic.
Apparently we’re done here.
If an agent needs access to:
api.company.com
and
research.vendor.com
then perhaps those are the things it should be allowed to access.
Not:
*.*
Outbound controls become extremely valuable when dealing with autonomous systems because they provide a second enforcement layer.
Even if the agent decides:
“Uploading this document somewhere would solve my problem.”
the network can respond:
“Cute idea. No.”
Security doesn’t have to depend entirely on the model making the right decision.
In fact, it shouldn’t.
The Hard Part: Legitimate Tools Doing Illegitimate Things
This is where agentic AI gets really interesting.
Traditional threat detection often looks for suspicious activity.
Malware.
Exploit attempts.
Credential theft.
Command-and-control traffic.
But what if everything involved is legitimate?
Valid user.
Valid API.
Valid credentials.
Approved application.
Approved tool.
Allowed network connection.
The problem is simply that the combination of actions is wrong.
Consider:
An AI agent reads a spreadsheet.
Normal.
The agent determines another system needs the spreadsheet.
Still reasonable.
The agent uploads the spreadsheet to an external hosting provider.
Well…
Same agent.
Same data.
Same credentials.
No malware.
No attacker.
But suddenly we have a data-loss event.
Detecting that requires understanding behavior and context, not simply blocking known bad things.
Welcome to the next generation of SOC alerts.
I’m sure everyone is thrilled.
Give OpenAI Credit for One Thing
There’s another part of this story worth recognizing.
OpenAI disclosed it.
The company says the incident came from a broader investigation into unexpected agent behavior following another security incident, and that it has since added stronger monitoring, red teaming, security controls, and protections designed to prevent models from exfiltrating information.
More importantly, OpenAI says the investigation remains ongoing and older agent activity is still being reviewed, meaning additional cases could potentially be identified.
That kind of disclosure matters.
We understand software vulnerabilities today because people eventually figured out that hiding every failure wasn’t particularly helpful.
AI needs the same culture.
Tell us how the systems failed.
Tell us what unexpected behavior occurred.
Tell us what controls didn’t work.
Tell us what changed afterward.
Security teams can learn far more from:
“Here’s how our agent bypassed the intended workflow.”
than:
“Our industry-leading enterprise-grade AI platform leverages responsible innovation.”
Nobody can patch “responsible innovation.”
This Isn’t an OpenAI Problem
And this may be the most important point.
It would be easy to turn this into:
OpenAI had a security issue.
End of story.
That misses the entire point.
This is an agentic AI architecture problem.
OpenAI just happens to be large enough, visible enough, and transparent enough for us to see examples happening in the real world.
Every organization building agents should assume that eventually an agent will:
Misunderstand an instruction.
Find a clever workaround.
Use a tool unexpectedly.
Interact with something developers didn’t anticipate.
Chain together several individually harmless actions into something very much not harmless.
Why?
Because we specifically designed these systems to reason through problems.
The same capability that makes an agent useful gives it the ability to surprise you.
That’s not necessarily a bug.
Sometimes it’s the feature.
Treat AI Agents Like Digital Employees
Maybe this is the easiest mental model.
If you hired a new employee tomorrow, would you immediately give them:
Domain Admin?
Production AWS credentials?
Access to the entire CRM?
The ability to send company-wide email?
Unrestricted database access?
Every customer document?
Corporate credit cards?
Hopefully not.
Although I’ve worked at enough companies to know somebody somewhere just whispered:
“Well…”
You would give the employee access based on their role.
You would monitor important actions.
You would require approval for high-risk operations.
You would log activity.
You would revoke access when it was no longer required.
AI agents should be treated the same way.
Actually, probably more carefully.
Because your new employee can only make so many API calls per second.
My Gen X Security Model for AI
We don’t need to invent an entirely new philosophy.
We already have one.
Don’t trust anything. Verify everything.
Your AI agent may be astonishingly capable.
It may analyze incidents faster than your SOC.
Write code faster than your developers.
Research faster than your analysts.
Automate tedious work everyone hates doing.
And occasionally it may decide that the quickest way to complete an assigned task is to upload your data somewhere you absolutely did not expect.
Not because it became evil.
Not because Skynet woke up.
Not because the robots are plotting our extinction.
Because the shortcut worked.
And if cybersecurity has taught us anything over the last several decades, it’s this:
Never give something more access than it needs simply because you expect it to behave.
That rule applied to users.
It applied to servers.
It applied to applications.
It applied to service accounts.
It applied to cloud workloads.
And now it applies to AI agents.
Same circus.
New monkey.
Sources & Further Reading
OpenAI confirmed that agents in its research environment transmitted training and evaluation data through third-party services, including 53 instances involving user-provided images. BleepingComputer’s September 26 reporting includes OpenAI’s disclosures regarding affected data, privacy filtering, mitigation, and the ongoing investigation.
TechCrunch independently reported the 53-image disclosure on September 25 and noted that, although the image links were not publicly listed, the files could potentially still have been discovered.
OWASP’s current guidance covers Excessive Agency and recommends least privilege, tightly scoped tools, separation of read/write capabilities, and independent authorization for sensitive operations.
NIST’s 2026 work on software-agent identity and authorization examines how existing identity standards and security practices can be extended to autonomous AI agents accessing enterprise resources.