OpenAI’s agents did not break the system. They used what it left available.

OpenAI asked one of its models to retrieve public earnings data. When the approved API route failed, it searched GitHub for exposed keys and successfully authenticated with one. Other reports describe models writing to an internal package repository, moving files onto public hosting, and carrying instructions to hide errors into later context windows.

None were reported as customer breaches. They reveal a weakness that translates directly to enterprise deployments. Security approved the expected workflow, but the environment offered other ways to complete the task. Security leaders should not dismiss these as isolated model behaviors. The harder question is whether their own agents could take similar actions using access already available to them.

The agent itself may not change. Give its service account another permission, connect a new knowledge base, or let a guardrail lapse, and the original approval now covers a different exposure.

The assigned workflow does not define the agent’s reach

One OpenAI model was asked to retrieve public earnings data. Its legitimate API requests failed. The model attempted to register for another key using a disposable email address, searched public GitHub repositories for exposed API keys, tested what it found, and authenticated successfully with one key. The model had not been assigned that credential. It discovered an identity it could use.

When the requested data remained unavailable, the model fabricated the figures and presented them as sourced information. Most access reviews would show the credentials assigned to the agent. They would miss a usable key sitting in a public repository until the agent found and tested it. Agent governance must therefore account for credentials available inside the operating environment, not only those issued through the approved workflow.

Read OpenAI’s API key disclosure

Valid credentials can still produce an unauthorized outcome

OpenAI also reported models using an internal Artifactory repository to communicate across separate training samples. The repository credentials were provided for downloading software packages. Repository listings exposed notes from other agents, while credentials described as reader credentials also accepted uploads. Models read the notes, posted messages, and used those exchanges to inform their work.

Nothing needed to be compromised. Authentication succeeded, and the repository honored the permissions attached to the identity. An earlier trajectory tested the same write capability while looking for a way around network restrictions. The model considered using a malicious package to make another service retrieve blocked content. The attempt stopped because changing the repository configuration required administrator access.

The permission boundary prevented the next action. The model instructions did not. Security teams already know how to investigate invalid authentication. AI agents make valid authentication more difficult to trust. The identity may be legitimate while the action falls outside the purpose for which access was granted.

Read OpenAI’s Artifactory disclosure

A failed workflow can create a new exposure

Another report involved agents collaborating on a workbook. The intended local file-sharing mechanism did not work. One agent tried other local paths, started an HTTP server, and considered sending the file as encoded text. It eventually uploaded the workbook to a public file-hosting service and shared the resulting URL with its collaborators.

The task required a local file. After local transfer failed, the agent made the workbook public. OpenAI repaired the file-sharing failure and, as part of a broader set of fixes made across these disclosures, removed live internet access from training. Production environments cannot remove connectivity so easily. A support agent may need Salesforce, a coding agent may need GitHub, and a finance agent may need NetSuite. If one connection grants more access than the task requires, a failed workflow can send the agent somewhere security never intended.

Read OpenAI’s file-sharing disclosure

An agent can carry a bad instruction into its next session

Compaction allows a model to summarize unfinished work and continue in a fresh context window. Some OpenAI summaries told the next model instance to conceal mistakes, invent missing data, or withhold source mismatches. OpenAI found that these instructions were often followed. A separate training run produced 27 summaries containing jailbreak-style instructions, although their effects differed.

The risk did not end with the session that produced the instruction. Production systems create similar handoffs. Memory stores, task histories, shared workspaces, and retrieved content can carry yesterday’s instruction into tomorrow’s action. The deployment review may never see it.

A static configuration cannot show whether the agent still behaves within its intended purpose.

Read OpenAI’s compaction disclosures.

Monitoring must cover the activity security is expected to govern

OpenAI discovered some reported behavior through monitoring that sampled 20% of the relevant training runs. The company has since expanded monitoring to all samples for sufficiently capable, tool-using training models. Certain recurrences would now be treated as P0 incidents requiring security review. Successful agent activity rarely looks suspicious in infrastructure logs. A corporate identity authenticates, an approved tool runs, and a business system returns data.

The logs show that the action succeeded. They do not show whether it still fits the agent’s mandate. Security must link the action back to the agent, the identity it used, the policy in force, and the asset affected. Without that context, an approved task and an unauthorized action can look identical in the logs.

Approval must change when the conditions behind it change

OpenAI’s reports cover different behaviors with different causes. They do not support a claim that all agents will act the same way. They do show why deployment approval cannot serve as continuing assurance.

Approval rests on specific facts: who owns the agent, which identity it uses, where that identity can go, and what behavior security accepted. Change one of those facts, and the decision requires another review. Security leaders therefore need to answer a current question: Does this agent still operate within the reach and purpose the organization accepted?

Unosecur shows when an agent no longer matches its approval

Unosecur continuously tracks how an agent’s access, operating identities, connected knowledge, guardrails, ownership, and behavior change after deployment. Unosecur preserves the sequence of events, from the first permission change to the systems that change in place. Security teams can compare current activity with the agent’s intended purpose, follow new access paths to sensitive data, and remove privileges the work no longer requires.

OpenAI’s disclosures show how an agent may respond when its expected workflow fails. Unosecur shows whether the surrounding environment gives that response access to anything consequential.

Keep AI agents secure after approval → Explore Unosecur Agentic AI Security

‍