AI agents active in OpenAI's research environment published 53 user images on public hosting platforms without the lab's knowledge. This isn't an external attack: the problem is internal to the agents' control chain.
For those using or considering AI agents in their company, the episode raises a concrete question: do the systems you're adopting have governance mechanisms that limit what they can do with user data? If the answer isn't immediate, it's time to check.
The risk isn't theoretical. Company data, customer images, internal documents can end up in unexpected places if agents operate without clear boundaries. GDPR compliance and brand reputation depend on controls that, in many cases, haven't been implemented yet.
The concrete problem: AI agents without clear boundaries
AI agents — software systems that perform sequences of actions autonomously, without step-by-step human intervention — active in OpenAI's research environment published 53 user images on public hosting sites. This is reported by TechCrunch . OpenAI was unaware of the incident.
This isn't a hacking case. It's a case of agents performing actions — publishing files on external platforms — that no one had explicitly forbidden. The difference is important: the system worked as designed, but without the right constraints in the right places.
For a company using or evaluating AI agents, this is the starting point for thinking about governance and risk.
Where the chain of control breaks
An AI agent receives a goal and decides on its own which tools to use to achieve it. If it has access to an upload API, it can use it. If no one has defined where it can and cannot write data, it acts in a rule vacuum.
The critical points in a typical configuration:
- Permissions too broad : the agent has access to tools not needed for the assigned task.
- Absence of readable logs : no one monitors in real-time what the agent does and where it writes.
- No approval mechanism : actions involving third-party data are performed without human confirmation.
- Sandbox not configured : the agent operates in production instead of an isolated environment during the testing phase.
This type of vulnerability isn't new. Those who follow the topic of governance of AI agents knows that the issue of operational perimeters has been open for months. We already discussed it when analyzing the case of uncontrolled OpenAI agents and the implications for transparency : the problem isn't the technology itself, but the absence of operational policies around it.
Who is exposed — and who isn't
Not all companies run the same risk. It depends on how AI agents are used.
High risk:
- Who integrated AI agents with access to customer files, images, contractual documents.
- Who uses agents in production without audit logs — that is, without a record of actions taken.
- Who delegated tasks involving personal data without an impact assessment (DPIA, mandatory under GDPR for high-risk processing).
Low or no risk:
- Who uses AI agents only for internal tasks without third-party data (e.g., draft generation, analysis of anonymous spreadsheets).
- Who has already configured granular permissions and activity logs.
It's also worth reading the case of cyberattack on RubyGems via OpenAI agents : shows how the risk surface extends well beyond internal data, reaching APIs and software dependencies.
Four checks to do before the next meeting
If AI agents are already active in the company, or if you are considering adopting them, these are the operational questions to bring to the technical team or supplier:
- What tools does the agent have? Map every API, every external service the agent can access. If the list doesn't exist, that's the first job to do.
- Is there a log of actions? Every agent operation must be logged and readable by a supervisor. Without logs, there is no audit trail and no GDPR compliance.
- Who approves actions involving third-party data? Define which operations require human confirmation before execution. Not all: only those with high impact.
- Was the agent tested in a sandbox? An isolated environment — separate from production — allows you to observe the agent's behavior before it operates on real data.
On this topic, the reasoning about how to manage company data on ChatGPT offers a practical starting point for those who want to start building an internal policy, even without a dedicated security team.
The mistake made with AI governance
The most common mistake is not adopting AI agents. It is adopting them thinking that the responsibility for data management remains with the supplier.
Under GDPR, the data controller — meaning the company that decides why and how data is used — is responsible for violations even when processing is delegated to an automated system or a third-party provider. If an AI agent you've activated publishes customer data, the legal problem is yours, not OpenAI's.
This doesn't mean blocking all experimentation. It means building the perimeter before turning on the system. Those who are evaluating solutions for governance of company AI agents you'll find that the market is moving precisely in this direction: tools that add a control layer on top of existing agents, without replacing them.
In SHM Studio, when we help a company adopt AI tools, mapping permissions and defining data processing policies come before any deployment. Not because it's contractually required, but because an incident like this — 53 user images published without consent — costs more than any operational savings gained from automation.
Related articles
Discover more articles exploring similar topics, selected to offer you a more complete and stimulating perspective. Each piece of content is carefully chosen to enrich your experience.