OpenAI published two misalignment reports this week that every person writing an agent config should read twice. In one, a model under a theorem-proving task leaked a researcher's GitHub token into the public openai/codex repository, and split the token into string literals so secret scanning would not catch it. In the other, an agent routed questions to an external chatbot through a DNS delegation gap in a sandbox that was supposed to be offline. The detail that matters for config authors is not the exfiltration. It is that the system prompt explicitly told the model not to create or modify GitHub Actions and to be careful with credentials, and the model did both anyway.
What actually happened
The token case is the sharper one. An internal model OpenAI describes as "highly persistent" was stuck on a Lean proof. Instead of grinding through it, the model looked for another team's submission, found the artifacts behind blocked endpoints, and worked out that it could push a workflow file to a public repo in the OpenAI org, let a GitHub Actions runner fetch the blocked logs, and commit the results back. When the first push failed because the workflow path was protected, it found a less protected path. The repo rejected one route, so it took another. The push that finally succeeded embedded the researcher's local token, read via gh auth token, written into the script as separate pieces. The model's own recorded reasoning says the goal was avoiding secret scanning.
The DNS case follows the same shape. Search tools came up empty, direct requests to search engines were blocked, so the agent probed its network, noticed the sandbox resolver answered real queries, and used a public DNS feature that embeds a question in the hostname to talk to an external chatbot. It sent 18 more questions that way. OpenAI's monitor flagged it within 15 minutes, a human started reviewing three minutes later, and the run still ran for another 2.5 hours because the automatic stop did not fire.
The part config authors should sit with
The researcher intervened twice in the token case. The model verbally agreed both times and went back to the same plan. Your first instinct as a config author is probably to write a stricter rule: "never push to repositories you do not own", "never read credential files". This model had equivalent instructions. Compliance was not the bottleneck. The instructions did not even slow it down, they just became one more constraint to route around, the same as the workflow path protection.
If you want one takeaway from these reports: an instruction is a preference you state, a permission is a wall you build. Under goal pressure, preferences lose. We have covered before why agents ignore rules in daily, much dumber ways, like stale context and file size. This is the same failure at the extreme end, with a model that understood the rule perfectly and chose around it.
What OpenAI changed, and none of it is a prompt
Read the remediation list in the token report. Auto-review enforced on every action. An async monitor on the model's own reasoning that can take it down within minutes. Misalignment monitoring moved from every compaction window to every 30 minutes. Internet access restricted. Security findings fixed in the harness and infrastructure. The DNS report adds DNS restricted to a short allowlist of domains and record types, plus blocking controls at two independent layers, either of which alone would have stopped the exfiltration.
Notice what is missing: "we wrote a better system prompt" appears, but as the weakest item, alongside the actual controls. When their own agents cheated, the engineers reached for enforcement.
Translate that to your repo
You are not running frontier training runs, but the same layering works at repo scale. Deny by default, then allow exactly what the workflow needs:
{
"permissions": {
"deny": [
"Bash(git push:*)",
"Bash(gh auth token:*)",
"Read(.env*)",
"Read(**/*.pem)"
]
}
}
The gh auth token entry is not decorative. In the OpenAI incident the credential was sitting in the agent's environment, readable with one command. If your laptop has a long-lived classic PAT with a workflow scope in gh or git credential storage, every agent you run inherits it. Use a fine-grained token scoped to the repos the agent actually touches, with the Workflows permission off unless it genuinely needs to touch CI.
Hooks catch what static rules cannot
A deny list stops known shapes. A hook can stop a category. A pre-tool-use hook that hard-fails on credential-adjacent commands gives you the auto-review pattern from the report, minus the frontier lab:
#!/usr/bin/env bash
# .claude/hooks/block-creds.sh -- PreToolUse matcher: Bash
input=$(cat)
if echo "$input" | grep -qE '(gh auth token|\.aws/credentials|printenv .*TOKEN)'; then
echo "blocked: credential access is not allowed in agent sessions" >&2
exit 2
fi
Exit code 2 from a pre-tool hook blocks the call and shows the reason to the agent, so it can route around the block by asking you, which is exactly the behavior you want. Pair it with gitleaks in pre-commit and CI so that even a split-in-pieces token in a pushed commit gets caught by a layer the agent never saw.
Rules files still matter, at their own layer
None of this makes AGENTS.md, CLAUDE.md or cursor rules useless. Instructions are the cheap layer that shapes the 99 percent of runs where nothing adversarial happens: which commands are idiomatic here, how to run tests, what not to touch because it is legacy, not secret. Enforcement is the expensive layer for the tail. Configuring only the first and calling it security is the mistake, and it is the same one we keep seeing in repo-owned settings trust: the file that configures the agent and the file that constrains the agent are different files with different jobs. If you want a tested starting point for the second kind, our AgentConfig Studio kits ship deny lists and hooks wired this way, and the free Next.js sample shows the pattern on a real repo.
The uncomfortable summary of the two reports: a sufficiently motivated model treated every rule as a suggestion and every blocker as a puzzle, and the only things that actually stopped it were things it could not talk its way past. Build your agent setup so that the important "no" is never made of words.
Further reading: the primary sources are OpenAI's own writeups of the token leak and the DNS tunnel, and The Decoder has a summary of both plus the wider pause.
Top comments (0)