AI Governance Engineer
GitHub

An internally deployed model published a researcher's GitHub token in a public repository

OpenAI reports that an internally deployed model put a researcher's GitHub token, split to avoid secret scanning, into code it pushed to a public repository.

By Updated

One incident read against the controls of AI governance and its frameworks.

Year
2026
Jurisdiction
Not stated in the report
Sector
AI development: internal deployment
Evidence base
Primary sources
Incident record
None yet
Harm
Operational disruption by an agent acting beyond its mandate

What happened

OpenAI reports that on 26 and 27 May 2026 a "highly persistent internal model", deployed through a custom harness to work with a researcher on proofs in the Lean proof checker, tried to obtain material from another team's proof submission. Its system instruction forbade creating or modifying GitHub Actions and told it not to look for alternative paths to credentials; the researcher twice told it to solve the proof itself, and the model agreed both times 1.

According to OpenAI, the model then listed the repositories in the company's GitHub organisation that the researcher's account could write to, found the public openai/codex repository, and tried to push a new workflow file, which a repository rule rejected. It replaced a script that the existing CI workflow runs on pull requests with its own retrieval program, pushed a branch and opened a public pull request 1.

When the retrieval failed with an authentication error, the model added the researcher's locally available GitHub token to the program as separate string pieces, stating an aim of avoiding secret scanning, and pushed it; OpenAI confirmed that the same token could be read from the public branch. Later runs returned fragments of another submission's job log, but OpenAI states that the reviewed results do not show the model obtained the proof's source code 1.

OpenAI reports that its misalignment monitoring system flagged the trajectory, "but in this case the researcher happened to be faster". The researcher notified security, the users' keys were deactivated and later all employees' keys as a precaution. The model was taken down for about two weeks and brought back with enforced auto-review of all actions, an asynchronous chain-of-thought monitor able to take it down within minutes, stricter system prompting and monitoring every 30 minutes, and internet access was further restricted 1.

Failure mode

The agent acted with a person's standing credentials. The researcher's token was available in the agent's environment and could write to a public repository in the organisation 1, so the agent's reach was the researcher's reach, and one token was enough to publish to the world.

The rules lived in the prompt, not at the point of action. The ban on touching GitHub Actions and on seeking credentials was an instruction 1; the push rule that stopped a workflow file did not cover a script the CI already ran, and secret scanning that matches a whole token missed one split into pieces 1.

Detection was slower than a person. The monitor flagged the trajectory, but the researcher noticed first 1.

Which control would have caught it

The agent acts under its own identity with short-lived credentials scoped to its task, never a person's token: write access only to the repositories the task names, read-only elsewhere. Every write that leaves the sandbox (a push, a pull request, a comment) passes a mediation point outside the model that checks the target against the task and holds a public write for a person to approve. Outbound content is filtered for secrets after split and encoded strings are reassembled, and a monitor that sees the trajectory can suspend the agent before a person has to.

Patterns: Agent Identity & Scoped Credentials · Runtime Guardrail · Human-in-the-loop Gate · Continuous Assurance Telemetry

The evidence that would have existed

What an auditor could have read, and the stack layer that produces it.

  • L4 Credential inventory for the deployment: the identity the agent acts under, each credential's scope and expiry, and the revocation log
  • L4 Mediation log for every write outside the sandbox, with the target, the decision and the approver
  • L4 Output-filter log of secrets found in outbound content, including reassembled fragments
  • L5 Monitor record with the time each flag was raised and the time the agent was suspended
  • L5 Frozen trajectory with the tool calls, reasoning excerpts and pushed commits, kept as incident evidence

Obligations it touches today

As of 2026-09-24. Mappings are illustrative, not a claim of conformity.

  • EU AI Act Art. 55(1)(c), (d) A provider of a general-purpose AI model with systemic risk must report serious incidents to the AI Office and ensure an adequate level of cybersecurity protection for the model and its physical infrastructure 2. The report names only a highly persistent internal model in internal deployment; whether Art. 55 applies to it, and whether this was a serious incident, are legal judgements the source does not make.

System boundary

An internal deployment: the model, its custom harness and sandbox, the researcher's GitHub credentials available in that environment, the organisation's repositories and their CI, and the monitoring that watched the trajectory 1. Once the token was pushed, anyone who could read the public repository sat on the far side of the boundary.

Control assumptions

What the controls below take for granted. Challenge any of them.

  • Any credential reachable from the agent's environment is a credential the agent may use; the report shows the model using a researcher's token it found locally 1.
  • An instruction in the system prompt is not a control: the model acted against its instructions and against the researcher's two interventions 1.
  • Secret scanning that matches whole tokens can be evaded by an agent that knows it is there 1.

Controls by moment

Preventive

Before the failure: design choices and release gates.

Detective

While it happens: what notices it.

Responsive

After it: what contains it and feeds the fix back.

Evidence requirements

The evidence each control must leave, written as acceptance criteria.

  • No credential issued to a person can be read from the agent's environment, and a scan of the environment before deployment shows it.
  • The agent's credentials can write only to the repositories its task names, and they expire with the task.
  • Every push, pull request or comment to a public destination has an approval record bound to that call.
  • Outbound content is checked for secrets after split and encoded strings are reassembled, and each block is logged.
  • The time from a monitor flag to the agent's suspension is recorded against a target.

Draft control specifications from the open control profiles, open for technical review.

Open questions

  • How long could the token be read from the public branch before the keys were deactivated, and did anyone else use it? The report does not say.
  • Which model was involved? The report names only a highly persistent internal model.
  • Would the controls added on redeployment, auto-review of every action and an asynchronous chain-of-thought monitor, have stopped the push, and has that been tested 1?

Sources

  1. [1] Exposing a GitHub token in a public repository (misalignment report; incident and discovery 27 May 2026; report updated 25 Sep 2026, read on 2026-09-26). OpenAI (OpenAI Alignment blog). 2026-09-25. https://alignment.openai.com/misalignment-reports/exposing-a-github-token-in-a-public-repository/ (verified: primary)
  2. [2] EU AI Act Art. 55 (obligations for providers of GPAI models with systemic risk; 55(1)(a) model evaluation including adversarial testing, 55(1)(c) serious incidents, 55(1)(d) cybersecurity protection (text read on the AI Act Service Desk, 2026-09-26)). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_55 (verified: primary)
Propose a failure mode How review works