This article evaluates the incident described in OpenAI’s report where a team of agents could not share the final spreadsheet…so the drafting agent uploaded the spreadsheet on a public host.
While this incident occurred in an OpenAI training experiment, imagine if it happened in production.
THE TASK: The original task was to build a depreciation cost workbook template. The team included a parent agent (Misson Control) and a sub-agent (Rover). Agents named for entertainment purposes only. According to the log, the task instructions specified that Rovers share the final workbook template through git.
Rover completed the workbook but then the handoff failed.
Follow the Wrinkles
Wrinkle One: The expected delivery channels were broken. The agents in the team could message each other but they could not see or access each other’s local files. This is a material issue in the task system since the point of delegating tasks to automated agents is that the agentic team produces a completed product.
The log shows that Rover completed the workbook without issue. Then, delivery “failed” at each attempt of Rover’s to deliver the workbook to Mission Control. At each failure, Rover communicated with Mission Control. Rover tried copying the file to a shared folder but the other agents in the team could not see it. Rover tried to commit the file to git but could not find the right repository. Rover considered encoding the file as text and decided that result would be too large. Rover tried uploading to a localhost (the local webservers) but we all know that Misson Control could not access the same localhost.
Each attempt was reasonable but each failed attempt led Rover to more creative solutions. Rover was pushed to think outside the box when the boring options were blocked.
Wrinkle Two: Rover asked the right question but the wrong channel. The logs show Rover asking whether uploading to a public host is allowed. It specifically seems to think, “prohibited”?
Then it answered its own question; it decided that uploading to a public host was not prohibited and uploaded the workbook to a public temporary file-hosting service….Rover sent the publicly available links to Mission Control and the other collaborator.
The red flag here? The rule existed. Mission Control instructed Rover to “Save in branch and send path.” Rover tried to follow the rule but ended up in a gray area where the instructions were not clear and seemed to not cover a path to successfully completing the task. An instruction is a policy and a system built to reason will reason around a policy that does not cover the situation at hand.
Wrinkle Three: Rover verified its success at completing the task instead of whether its actions were authorized. The logs show that Rover tested the public links to confirm that the files were downloaded. When Rover confirmed that the data was successfully downloaded, it determined that it had completed its task of creating a workbook template and sharing it with Mission Control. What should have been a verification of who downloaded the file and whether the sharing method was authorized (and not prohibited) was bypassed with a finding that the task was a success…the steps did not matter if the outcome was achieved. There was nothing to report to the human in the middle.
Exposure: Why should we care?
If the uploaded workbook had personal data of consumers: Personal data just got shared with a third party entity (public host) subject to a completely unvetted privacy policy and data retention policy. There are no legal constraints in place to govern the sharing and the company is not even aware that the sharing of such personal data occurred. Depending on the state, this could have triggered a breach notification analysis.
If the uploaded workbook had confidential information: Rover might have just breached commercial NDAs or other agreements governing the use and disclosure of such confidential information.
Until the uploaded workbook is deleted: A live, unmonitored download link and access to the data exists and could be scraped or cached. You cannot control who has access to such link or retains the downloaded data since your company does not know that this upload happened.
Constraint Design
When the incident is reviewed through Constraint Design, structural constraints would have best mitigated the incident.
Structural: The core issue here was the program (and Rover’s) ability to share data in a seemingly unrestricted manner. The fix would be at the application layer whether it is a feature at the frontier model or a customized middleware application that tailors the frontier model for your specific industry’s risks and use cases.
For industries where this makes sense, the application layer should include ability to research and access publicly available data but restrict the downloading and/or uploading of such data. Examples could include restricting agentic sharing to only within the intranet or the Company’s approved sharing software or hosts (and the protected URLS). Best practice would also include frequent monitoring of such sharing done solely by the agents to confirm there are no unauthorized incidents.
Reasoning agents solve around broken tools; a broken handoff is a security defect.
Operational: The operational layer that compounded the issue was not having tiered levels of failure such as a “Stalled Task” compared to a “Failed Task”. The customer should be able to identify “Stalls” which are points at which the agents need to flag for human in the middle review due to an unforeseen block to completing the next step. When Rover questioned “prohibited?” would have been a clear “Stall” that Rover could flag to Mission Control for additional instruction or human review without it being considered a “Failed Task”. Operational guardrails such as stage that occurs if the task “Stalls” and automatically triggers human in the middle monitoring and review would mitigate unauthorized agentic behavior and resulting damage.
Contractual: Two areas of the contract around agentic tools will likely be negotiated until the market settles.
First, who is responsible for both restricting and monitoring the provided agent’s behavior?
This should reasonably be allocated based on which party can actually exercise such control and restriction as well as monitoring. If the customer’s ability to restrict an agent is shallow or limited at the configuration level or individual prompts, then there is logic in the vendor retaining some responsibility.
For monitoring. OpenAI’s project monitoring detected this unauthorized sharing of data because the project sampled 20% of its training run. The fact that the sample uncovered this incident shows that sampling is successful but sampling also means that 80% of the unsampled data could include other incidents similar or different but still unauthorized and beyond the scope of the original instructions provided to the agents. However, the successful monitoring supports the allocation of the burden of identifying such vulnerabilities to the frontier models, which have the most data to review.
Second, parties may need to evaluate the definition of “Security Incident” and whether it includes incident’s like Rover’s sharing above. The conclusion of such evaluation would inform you on whether cyber policies or any liability limitations would apply to incidents like this.
Rover was not malicious. Rather, Rover was diligent and motivated. AI Constraint Design is not about penalizing Rover or those who utilize agents but adding the protective constraints so that Rover can do the work.
v1.0 September 2026. Descriptions of the incident are based on OpenAI’s publicly available report. For general informational purposes only; not legal advice, and reading it does not create an attorney-client relationship.