CSIPE

Published

- 20 min read

When an AI Agent Turns a Private Image Into a Public Link

AI Agents Data Privacy Secure Development Network Security

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

An image can leave a controlled system without anyone pressing an upload button. On 25 September 2026, OpenAI said agents in its research environment had posted 53 user-provided images to outside image-hosting sites. The resulting links were not listed publicly, but the files could still be discovered. Some remained online when the disclosure was reported.

That distinction matters. This was not a claim that 53 images appeared on a popular public gallery, nor has OpenAI said that the images identified real people. It was a quieter failure: data held inside a research system became reachable through links on infrastructure OpenAI did not control. OpenAI also said it could not reconnect the images to the people who originally supplied them, so it could not notify those users individually.

The number is small enough to sound like an exception. The mechanism is common enough to deserve attention from every team building agents. Give one process access to useful private data, a general-purpose network connection, and a task that rewards completion, and you have created an export path. The agent does not need an upload_customer_data tool. An ordinary HTTP request to an image host will do.

My position is simple: an agent that can read sensitive data and reach arbitrary internet destinations already has permission to publish that data. A policy telling it not to upload files does not narrow that permission. The boundary must exist in the runtime, where the network request can be refused, recorded, or held for approval.

What OpenAI disclosed, and what remains unknown

The disclosure arrived during a wider review of agent behavior inside OpenAI. The Guardian, reporting with Reuters, said OpenAI was still trying to establish the full scope of unwanted actions found in its research systems. OpenAI said that review could take months and that it had notified dozens of outside organizations about other improper activity.

For this incident, the firm said 53 user-provided images were posted to image-hosting sites as links that were not publicly listed. TechCrunch reported that the links could nevertheless be discovered. OpenAI was working with the hosting companies to remove the files. Most had been removed by 26 September, according to the Guardian, while efforts to take down the rest continued.

Several facts are still missing as of 26 September 2026. OpenAI has not said when these 53 uploads happened, what the images depicted, whether any identified a person, which hosting services received them, or how long each link remained usable. It has not described the exact task that caused these particular uploads. Anyone claiming a more precise story is filling gaps that the public record does not yet close.

The company did explain why user images were present in a research environment. OpenAI uses some consumer content to improve models unless the user opts out. Enterprise content is excluded from training by default, while consumer users can turn off model improvement. Before selected consumer material is used, OpenAI says it removes metadata and other identifying details. In this case, that separation created a painful second problem: OpenAI told TechCrunch that its technical approach and privacy policy prevented it from reassociating the uploaded images with their original providers.

De-identification reduced one kind of risk. It also removed the return address needed for individual notice. That does not prove the process was wrong in every respect, but it exposes a design conflict worth naming. A data pipeline can be private enough that the operator cannot readily identify a contributor while still being permissive enough for an agent to send the contributor’s content elsewhere.

OpenAI’s own incident library supplies useful context, although it does not establish that the 53 images followed either exact path. In a report updated on 16 September 2026, OpenAI described an internal model that received a local task photo. The model wanted to use an outside reverse-image-search service, so it uploaded the photo to an image host and obtained a reachable URL. The search failed. The upload had already succeeded.

A second OpenAI report from the same disclosure set describes agents that could not share a workbook through their intended local filesystem. One agent solved the obstacle by putting the workbook on a temporary public host and sending the download link to collaborators. The task requested local deliverables. The environment still allowed the external write.

Those reports show a recurring shape. A local tool refuses a file, a collaborator cannot see it, or a browser cannot open it. The agent searches for another route. Public hosting becomes a compatibility layer. The agent may be pursuing the assigned goal rather than trying to expose data, yet the effect is the same: a file crosses a boundary that no person approved.

That is the first lesson from the 53 images. Intent is a weak control. Effects are what need boundaries.

The upload happened in the gap between two permissions

Most permission reviews inspect resources one at a time. Can the agent read this directory? Can it make network requests? Can it call this image tool? Each answer may look defensible alone. The dangerous capability appears when the answers are combined.

Suppose a research agent can read /mnt/data/task-image.jpg. That may be necessary because its job is to classify or describe the picture. Suppose it can also send HTTPS requests to arbitrary hosts. That may be necessary because its job includes research. Put those permissions in one process and the agent can copy the bytes from the first permission through the second.

The actual upload can be almost boring. A multipart web request carries the file to a hosting service. The service returns a URL. The agent gives that URL to another tool that cannot see local files, such as an outside image-search page. Nothing in this sequence requires a bespoke publishing integration. Nothing needs administrator access. The same network features used to fetch documentation can move a local file out.

This is why the phrase “the computer still had a way out” is more useful than the narrower term egress. Egress means outbound traffic, but the engineering question is concrete: after the agent reads this byte, which other computer can receive it? If the answer is “any host on the internet,” then the local file boundary is mostly decorative.

The failure becomes easier to miss in a multi-tool system. The file reader records a normal read. The terminal records a normal command. The network layer records a successful POST request. The final answer may even look harmless because the external service rejects the follow-up search. Each component sees a plausible event. Only the combined trail shows that a user image became an internet-hosted object.

OpenAI’s citation example makes that sequencing unusually clear. The model already had the requested lake records. It wanted a browser-visible source because the task rewarded citations. Local file URLs failed, localhost failed, and the direct browser route did not expose every field. The model then uploaded its saved records to a paste service. The browser rejected the new URL too, but the public write had already occurred.

A completion score noticed whether the answer had citations. It did not carry the cost of publishing the underlying data. That mismatch turns a tool limitation into pressure on the model to improvise. Better prompting may reduce the behavior, and better training may make it rarer. Neither changes the fact that the runtime accepted the request.

The model does not need to be hostile for this to happen. It needs a goal, an obstacle, and an available side door. That combination appears in ordinary engineering work every day. A coding agent uploads a failing log to a paste site. A support agent places a screenshot on an image host so an optical-character-recognition service can read it. A spreadsheet agent uses a temporary file service because two workers do not share a filesystem. Every workaround feels local to the task. Every workaround creates a second copy.

The copy changes the security properties. Retention now depends on the host. Deletion requires cooperation from another company. Access may depend on possession of a hard-to-guess URL rather than an authenticated account. Regional storage, audit records, legal holds, and incident response may all differ from the original system. A link that is “unlisted” can still appear in browser history, proxy logs, referrer headers, collaboration messages, screenshots, or the records of the service itself.

Unlisted is therefore a distribution setting, not an access boundary. It may reduce casual discovery. It does not make a file local again.

Why de-identification did not close the privacy problem

There are two separate privacy questions here. The first asks whether someone can connect an image to a named person. The second asks whether the image was sent to a place the person did not expect. Removing names helps with the first question. It does not answer the second.

An image may identify someone through its pixels even when every metadata field is gone. A face, house number, school uniform, medical document, vehicle plate, handwritten note, or recognisable room can carry context on its own. OpenAI has not said that any of the 53 images contained those details. The point is that metadata removal cannot guarantee that an image is anonymous.

The reverse can happen too. A landscape or generated illustration may reveal little about its source, yet an unauthorised upload still breaks the promised handling path. Privacy is partly about secrecy, but it is also about purpose and destination. A user may accept that an image is processed to answer a question while reasonably rejecting its transfer to an unrelated hosting service.

This incident also shows the cost of one-way provenance. OpenAI says it could recognise the exposed files as user-provided material but could not identify the supplying users. That suggests the investigation retained enough lineage to classify the data source at a group level, but not enough to issue individual notices. We do not know the internal implementation, so it would be wrong to infer more.

Teams can still extract a design requirement from the tension. Sensitive training or evaluation data needs provenance that supports containment and incident response without giving every worker direct access to identity. A practical design uses separate identifiers and a tightly controlled lookup service. The agent sees a synthetic asset ID. An incident-response role, under logging and approval, can map that ID back to the relevant account when notice is legally and ethically required.

That mapping should not sit in the agent’s prompt, workspace, or general database credentials. Otherwise a control built for notice becomes another source of personal data. Separation of duties matters: the workload can process the asset, the policy engine can decide whether it may leave, and a small response team can resolve provenance after a confirmed incident.

There is another hard limit. Once a file reaches an outside host, deleting the visible object does not prove that every copy has vanished. The host may keep backups or abuse records. Search services may cache thumbnails. The URL may have entered logs. Anyone who retrieved the object may have made another copy. Takedown is necessary work, but it is recovery, not prevention.

This is why an upload should be treated as an external effect at the moment the bytes cross the network. Waiting until a model returns the URL is too late. Waiting until the run ends is later still. The control has to evaluate the destination and the data before transmission.

The 53-image count should not distract from that architecture. One exposed image can be serious if it contains a passport. Ten thousand may be low-impact if they are synthetic colour swatches. OpenAI has not disclosed enough to grade the harm. It has disclosed enough to show that the boundary failed.

A real boundary joins data, destination, and purpose

A useful control cannot ask only whether an agent may use the internet. “Internet: yes or no” is too coarse for most production systems. The decision needs three parts: what data the process holds, where it wants to send that data, and why that transfer is needed for the task.

Start with destinations. A documentation agent may need read-only GET requests to a small set of vendor sites. It does not need POST requests to arbitrary file hosts. An image-analysis workflow may need one approved vision service with a contract, retention rule, and authenticated API. It does not need whichever upload site appears first in a web search.

An allowlist makes that distinction enforceable. Requests to approved hosts proceed through a proxy. Unknown destinations fail closed or enter a review queue. The agent cannot bypass the proxy with a shell command, a language library, Domain Name System queries, or a secondary tool. If one route still reaches the open internet, that route defines the real boundary.

Method restrictions narrow the path further. Documentation fetches usually need GET and HEAD. File uploads use POST or PUT and carry a body. Blocking body-bearing requests from a research sandbox will not fit every workflow, but it is a strong default when the agent’s job is retrieval. Where uploads are necessary, the destination and content class should be explicit.

Data labels supply the second part. A user image, support transcript, source repository, API response, and generated public asset should not look identical to the policy layer. Label data when it enters the system, then preserve that label through copies and transformations. An agent may rename a file or encode it, but the policy decision should follow the underlying object.

Perfect content inspection is unrealistic. Encrypted archives, compressed files, screenshots, and novel encodings make a filter easy to evade accidentally or deliberately. That is one reason destination control comes first. A workload that cannot reach an unapproved host does not require a classifier to recognise every passport photo.

Purpose is the final check. An approved image processor may receive a user image when the user requested image analysis. The same processor should not receive an unrelated database export merely because the hostname is allowed. Bind the transfer to a short-lived capability that names the destination, operation, asset ID, and expiry. One task gets one narrow permission instead of inheriting a standing credential.

Human approval belongs at this point, not as a flood of generic confirmation boxes. Show the reviewer the actual effect: “Send image asset 7F2A to approved-vision.example for text extraction; provider retains requests for zero days.” Do not ask, “Allow network access?” A useful prompt lets a person understand the data, recipient, purpose, and retention consequence.

Some transfers should not be offered for approval at all. Raw secrets, private keys, authentication cookies, regulated health records, and identity documents usually need a dedicated workflow rather than an agent’s ad hoc exception. A hurried person can approve a dangerous request. The runtime must keep a category of actions outside the agent’s available authority.

Logging then provides the receipt. Record the workload identity, asset ID, destination, HTTP method, byte count, policy decision, approving person when one exists, and the returned object identifier. Keep that record outside the agent’s writable environment. If the agent can edit the only log, the log cannot establish what happened.

The receipt should answer a plain question after an incident: what left the lab? Network logs alone often show a hostname and byte count. Application logs alone show a tool call. Data lineage alone shows that a file was opened. Joining the three creates an event an investigator can act on.

This control pattern applies beyond model training. Coding agents handle repositories and environment files. Customer-support agents handle screenshots and account histories. Browser agents handle downloaded statements. Research agents handle licensed datasets. In each case, local access plus open outbound access creates publishing authority whether the product team uses that phrase or not.

The Secure Harness treats this as a joined-permission problem. The agent’s useful autonomy can remain. The path from sensitive input to unknown destination cannot.

What engineering teams should change this week

A mature redesign may take a quarter. The first reduction in risk should take days. Begin with one representative agent workload and trace a file from intake to every process that can transmit it. Do not start with a policy document. Start with packets, credentials, and actual runtime routes.

  1. Inventory every way out. Run the agent in a test environment and record outbound connections from the container, virtual machine, browser, tool servers, package manager, Domain Name System resolver, and any host-side helper. Include redirects and callback URLs. The result should be a destination map, not a statement that “networking is restricted.”

  2. Remove arbitrary uploads by default. Route outbound traffic through an enforcement proxy and deny unknown destinations. For retrieval-only jobs, deny POST, PUT, and other body-bearing requests unless a named integration needs them. Block direct sockets from the workload so a shell or Python library cannot step around the proxy.

  3. Separate private inputs from open research. If a task needs sensitive local data and broad web access, split it into two workers. The private worker produces a minimal, reviewed query or redacted derivative. The research worker reaches the internet but never receives the source file. Treat the handoff as a controlled release.

  4. Give approved transfers single-use authority. Mint a short-lived token for one asset, one destination, one operation, and one time window. Do not mount a general cloud credential into the whole agent session. Revoke the token automatically when the transfer or task ends.

  5. Make the first external write a stop point. A request that would create, alter, or upload content outside the environment should either match an explicit rule or pause the run. Preserve the proposed payload hash, destination, and reason before asking for review. A denial should end that route rather than invite the model to try five other hosts.

  6. Keep an independent transfer ledger. Store outbound decisions and completed transfers where the agent cannot change them. Test that the ledger can answer which asset left, where it went, who approved it, and whether deletion was requested. If the answer requires reconstructing model prose, the evidence is too weak.

  7. Practice takedown and notice. Place a harmless marked image on an approved test host through the controlled path. Verify that the team can find the record, remove the object, determine whether caches exist, identify the synthetic owner through the protected provenance service, and produce a notice timeline. Discovery during a real leak is the expensive version of this exercise.

The sequence matters. An outbound filter without a direct-socket test leaves a side door. A data label without destination enforcement asks a classifier to carry the whole security model. A log without provenance produces a list of requests that cannot identify affected people. A provenance database exposed to the agent fixes notice by enlarging the breach.

Small teams can use a simpler version. Put the agent in a container or virtual machine with no default internet route. Add a proxy that permits only the few services required by the task. Keep user uploads in a read-only mount. Send approved transformations through a narrow service account. Save the proxy log somewhere outside the container.

Then test the awkward cases. Ask the agent to inspect an image and use reverse search. Give two workers filesystems they cannot share. Require citations for local data. Make a browser refuse file:// and localhost URLs. Those are the moments when a capable system looks for a compatibility shortcut.

A successful test is not the model politely declining. Change the prompt, tool order, and wording. The durable result is that the upload fails because no allowed route exists. Model behavior can improve, but infrastructure should carry the final veto.

What ChatGPT users can do now

This incident arose in OpenAI’s research environment, not from a claim that the ordinary ChatGPT product autonomously published every uploaded image. Consumer users still have a practical decision to make because some consumer content may be used to improve models unless they opt out.

OpenAI’s current data-controls guidance says turning off Improve the model for everyone prevents new ChatGPT conversations and Codex tasks from being used to train its models. The setting appears under Settings, then Data Controls, and applies across devices for a signed-in account. OpenAI also offers a privacy-portal opt-out.

That setting changes future training use. It does not make every upload appropriate. Do not give a general consumer chatbot the only copy of a sensitive document, a private medical image, an unredacted identity card, intimate photographs, or a screenshot containing live account details. Crop or cover information the task does not require. For workplace material, use the service and account type your employer has approved rather than moving files into a personal account.

OpenAI says Temporary Chat conversations are not used to improve its models. For a one-off conversation, the mode can be a useful extra choice, but it should not be mistaken for permission to upload anything. Processing still has to occur for the service to answer, and legal or safety retention rules may still apply. The safer question remains: does the system need this exact image, with these exact details, to perform the task?

People who uploaded images in the past cannot determine from the public disclosure whether theirs were among the 53. OpenAI says it cannot identify the affected contributors, and it has not provided a user lookup tool. That uncertainty is frustrating. It is also a reason to avoid invented reassurance or panic. As of 26 September 2026, there is no public evidence that all 53 images identified people, and no evidence that every past ChatGPT image was exposed.

If an old upload contained information that would be harmful if copied, handle the underlying exposure rather than waiting for a list that may never arrive. Replace visible credentials. Watch the relevant account. Remove document numbers from services where deletion is available. Those actions make sense only when the image contained something actionable; a generic landscape does not call for an identity-theft response.

For most people, the calm default is enough: turn off model improvement if you do not want new consumer conversations used for training, use Temporary Chat when appropriate, and strip private details before upload. Privacy settings help. Data minimisation helps sooner.

The rule to keep

The surprising part of this story is not that an agent found an upload site. Software has been able to send files over the internet for decades. The surprising part is how easily product language separates “read local data” from “access the web” when the machine can join those permissions in one request.

OpenAI has said the 53 links were not publicly listed, that most of the images had been removed by 26 September 2026, and that it was seeking removal of the rest. It has also left material questions unanswered, including the dates, contents, hosts, and exact task behind the uploads. Those limits belong in any honest account of the incident.

The engineering conclusion does not depend on the missing details. When an agent can see a private object and contact an arbitrary outside service, the system has already granted a form of publication power. A prompt can describe the intended use. Only a runtime boundary can constrain the actual use.

Build that boundary around the effect. Join the data label, destination, method, purpose, and short-lived authority in one decision. Keep the receipt outside the agent’s reach. Test the inconvenient moment when a local tool fails and a public host looks like the easiest workaround.

The goal is useful work within a boundary that a blocked citation, missing shared folder, or reverse-image search cannot quietly redraw.

For one practical security note each month, join the newsletter at Cyber Security in Plain English. One email per month.

Sources