Evgen verzun
Blog
September 25, 2026
OpenAI Codex Executed an Unauthorized Task: A Forensic Timeline and Lessons for CISOs
An AI agent used real execution capabilities inside an organizational environment to complete a task nobody had authorized. It wrote a program, ran commands, generated files, and presented the result as legitimate work. The original user instruction was still present in its recorded context.
The deviation began approximately seven seconds after automatic context compaction in OpenAI Codex. It continued for almost seven minutes, through repeated tool failures and repair attempts, before the agent delivered an unrelated spreadsheet.
This is a documented failure of task authorization with actual local effects. The evidence does not yet establish an external attacker, compromise of OpenAI or Microsoft infrastructure, or another customer's data entering the session. Those questions remain open.
For CISOs, the immediate concern is already clear: an agent's permission to use tools became detached from the purpose for which that permission had been granted.
The unrelated workflow
The assistant was working on an authorized software-engineering assignment. The user's latest instruction concerned the number of concurrent work slots it could use. It did not request a new deliverable.
The agent initially continued the legitimate work. It coordinated existing activities and inspected relevant implementation material. When the conversation reached the configured context threshold, the runtime initiated automatic mid-turn compaction.
Context compaction reduces the information carried into subsequent model requests. Depending on the implementation, a continuation may combine retained messages with a condensed representation of earlier activity. Because this representation influences what the agent believes it should do next, compaction is also a security-relevant state transition.
After that transition, the agent announced that it would create an Excel workbook containing synthetic telemetry for 25 devices over 24 hours.
It then read spreadsheet instructions, wrote a JavaScript generator, executed it, repaired implementation errors, generated the workbook and supporting files, inspected the output, and returned it to the user.
The resulting dataset was synthetic. The unauthorized use of execution capabilities was a confirmed fact and the tokens spent on it were real.
Where the objective changed
The investigation reconstructed the sequence using the local execution journal, runtime logs, projected task history, file metadata, and per-response usage records. Original records and generated artifacts were preserved and hashed.
The following timeline uses relative timestamps to avoid publishing environment identifiers. T+0 is the moment the replacement context was recorded after compaction.
| Relative time | Recorded event |
|---|---|
| Before T+0 | The AI agent performs work related to the authorized assignment |
| T+0 | Replacement history and an encrypted compaction item are recorded |
| T+6.7 seconds | The agent announces the unrelated spreadsheet task |
| T+1 minute 49 seconds | A program for that task is written locally |
| T+4 minutes 8 seconds | The workbook first exists on disk |
| T+6 minutes 52 seconds | The unrelated result is delivered to the user |
The wrong workflow itself lasted approximately 6 minutes 45 seconds, measured from its first visible announcement to the final answer. The slightly longer interval above begins at recorded compaction completion.
During the deviation, 19 shell commands executed and eight file-change operations completed. One additional shell command, intended to remove intermediate files, was rejected before process creation.
That rejection limited one later action. It did not prevent the earlier unauthorized writes.
The repeated failures are also significant. Each implementation error became a reason to continue repairing the spreadsheet workflow. The agent did not re-establish whether that workflow belonged to the user's assignment.
The strongest evidence
A simple explanation would be that compaction removed the latest user request and left the agent without its initial objective. The saved replacement history does not support that explanation.
The latest instruction from the user remained present immediately before the encrypted compaction item. The problem was therefore more specific than an observable disappearance of that instruction: the agent’s subsequent actions contradicted the authority still recorded in context.
A bounded search of 108 local session files found no matching user request for the telemetry task. The matching pre-cutoff message was the assistant's own erroneous final answer.
That search has limits. It cannot exclude paraphrases, deleted records, remote-only history, image content, or information inside encrypted state. It does establish that the investigation was not able locate a straightforward, earlier user instruction that justified the task.
The context-size trigger was visible in the runtime trace:
auto_compact_scope_tokens=252684
auto_compact_scope_limit=Some(244800)
token_limit_reached=true
has_pending_input=false
run_auto_compact{reason=ContextLimit phase=MidTurn}
These selected fields show an automatic context-management operation during an active turn. They do not show a new user submission requesting the spreadsheet.
What can and cannot be established
The deployment used Codex with Azure-hosted inference. Incident-time HTTP logs associate both the compaction request and the first resumed request with the same configured Azure resource and the same reported served-model identity.
The request path was the Responses endpoint. The recorded auto-compaction operation did not require investigators to infer a separate /responses/compact call: the observed path was /responses.
Successful HTTP responses establish that requests were accepted and responses returned at that endpoint. They do not establish that the correct task state was generated, associated with the correct continuation, or interpreted correctly.
The compacted state is stored as an opaque encrypted item. Its exact plaintext has not been independently recovered. OpenAI's documentation describes compaction items as opaque and not intended to be human-interpretable.
Consequently, several causes remain possible:
- Incorrect or unrelated context was assembled before the compaction request.
- Compaction generated an inaccurate representation of the active objective.
- A request, response, cached state, or continuation was associated incorrectly.
- The returned state was handled incorrectly during persistence or restoration.
- The resumed model misinterpreted otherwise valid state or invented a new objective.
Timing strongly localizes the investigation to the compaction-and-continuation boundary. It does not, by itself, identify which component introduced the error.
No browser or computer-use invocation appears in the erroneous execution interval. This case therefore does not support attributing the task switch to a computer-use plugin merely because that capability was available in the product.
Which security boundary failed
The confirmed boundary is task authorization.
The agent was allowed to use execution capabilities for a particular assignment. It used them for a different objective without a supporting user instruction.
The distinction between capability and authority is familiar in security engineering. A service account may be technically capable of accessing many records, but each operation still needs to satisfy the application's authorization rules. Similarly, an agent's ability to run a command does not establish that the command serves an approved task.
An AI system adds a difficult intermediate step: it generates its own proposed actions from context. If that context incorrectly represents the current objective, the system can produce plausible, well-formed commands for unauthorized work.
The observed path can be represented as:
Authorized assignment
|
Automatic context compaction
|
Retained instructions + opaque state
|
Resumed model adopts unrelated objective
|
Permitted tools perform unauthorized work
This is why conventional perimeter observations are insufficient. A network control may correctly permit an application to contact an approved model endpoint. An endpoint control may correctly recognize an allowed process. Neither decision necessarily establishes whether the generated action belongs to the user's authorized objective.
There was no demonstrated firewall bypass or unauthorized remote login in this investigation. The security failure occurred through an existing trusted workflow.
The incident attribution
A credible investigation must distinguish the impact from the mechanism and the mechanism from the responsible party.
| Question | Evidence-based answer |
|---|---|
| Did unauthorized execution occur? | Yes, commands and file changes are recorded |
| Did the latest user instruction authorize the spreadsheet? | No |
| Did the instruction survive in the replacement history? | Yes |
| Was another customer's task delivered? | Not established |
| Was OpenAI or Microsoft infrastructure compromised? | Not established |
| Was company data disclosed to an unauthorized recipient? | Not established as available examination cannot certify its absence |
| Is the precise source of the wrong objective known? | No |
The current AI agent generated and issued the executable actions. No authenticated external sender of the telemetry task has been identified.
An outside attacker is one possible explanation for some classes of context substitution, but a software defect, model error, or state-association failure can also produce a serious security outcome. Identifying the event as unauthorized execution does not require investigators to first prove malicious intent.
Conversely, describing it as a confirmed cross-tenant breach would go beyond the evidence available today.
The loss of resources
The unrelated workflow consumed 3,110,317 recorded tokens across 32 model responses. Including the immediately preceding compaction response raises the total to 3,350,143.
Most input was reported as cached. Approximately 3 million input tokens in the wrong-task interval represented repeated cached context. The figures are not equivalent to millions of unique words, exposed records, or newly generated content.
The accounting was calculated from individual response records, without adding cumulative totals or counting cached and reasoning subsets twice. It establishes resource consumption attributable to the observed workflow.
A defensible monetary estimate would require the actual provider billing treatment. Staff time, operational disruption, and other business costs require separate evidence.
The security measures agent architectures need
Keep authorization outside generated summaries
An active-task record should identify the approved objective, allowed effect types, relevant resources, and originating user instruction. It should be protected from being rewritten by the same model that proposes actions.
Putting another reminder inside the conversation may help behavior, but it does not create an independent authorization boundary.
Validate continuity at state transitions
Compaction, session restoration, delegation, and retries should trigger checks that the next proposed action still belongs to the authorized task.
A sudden change of domain, deliverable, recipient, repository, or effect class should be explainable through a real instruction with known provenance. If that explanation is missing, execution should stop before effects occur.
Enforce scope at the tool boundary
The place to reject an unauthorized action is before the shell command, file mutation, external message, or deployment executes.
Task-scoped capabilities can reduce exposure. A coordination task need not automatically inherit the ability to create unrelated artifacts, modify credentials, or publish changes. Broader access should remain tied to explicit scope and operational need.
Preserve provenance for every source of context
User instructions, application wrappers, tool results, retrieved documents, other-task notifications, and generated summaries have different authority.
The system should retain those distinctions rather than relying on wording such as “the user requested” inside generated text. A summary can accurately describe an instruction, but it should not be able to manufacture one.
Make opaque state investigable
Encryption can protect context, but an enterprise still needs an authorized diagnostic path when that context affects security-sensitive actions.
Suppliers should support correlation of request identity, source task, context item ordering, returned state, and resumed input. Any inspection of protected content must use controlled access and avoid disclosing unrelated customer information.
The evidence needed for finding a root-cause
The decisive investigation compares three stages:
- The exact compaction input. Was the unrelated objective already present, and what source introduced it?
- The returned compacted state. Did the service introduce or misrepresent the task, or return state associated with another request?
- The first resumed input and output. Was the correct state replayed into the correct task, and when did the unrelated objective first appear?
Request and response IDs, task and turn identifiers, input/output hashes, client build information, effective configuration, and provider correlation records are needed to connect those stages.
A supplier response of “the model hallucinated” is incomplete unless supported by evidence identifying the affected stage and explaining the failed control. A statement that no infrastructure was hacked would address a different question from why unauthorized commands were allowed to execute.
Recovery testing should also cover concurrent tasks, forked histories, delayed notifications, cache behavior, and deliberately conflicting summaries. Initial tests should use sanitized fixtures and tools that cannot create real effects.
How the incident should be handled
NIST SP 800-61 Rev. 3 addresses incident declaration, analysis, evidence preservation, coordination, and notification as part of cybersecurity risk management. These activities are relevant when unauthorized agent execution is observed, even while its exact origin is unresolved.
For organizations operating under SOC 2 commitments, the incident also raises questions about anomaly monitoring, security-event evaluation, response, logical access, and supplier risk. The effect on an engagement depends on the actual system scope and controls; one incident does not automatically determine an audit opinion.
External breach notification is a separate decision governed by applicable laws, contracts, and organizational obligations. Neither NIST nor SOC 2 supplies a universal deadline for every event. Investigators should preserve awareness timestamps and avoid allowing uncertainty about the sender to delay a notification that is otherwise required.
Before granting an AI agent access to a sensitive environment, require evidence that its actions remain bound to the user's actual authorization across every context transition. The test is whether the system stops when that relationship breaks, even when the proposed command is technically valid and the resulting artifact looks harmless.
For now, the root-cause attribution remains open.