On December 11, 2025, OpenAI published an update to the GPT-5 system card covering GPT-5.2, the production model that replaced the original GPT-5 (August 13, 2025) in the default routing tier of ChatGPT and the API. A week later, on December 18, OpenAI shipped an addendum specifically for GPT-5.2-Codex, the coding-specialized variant. These two documents together represent the first major preparedness-framework refresh of OpenAI's 5-series and contain non-trivial changes in how the company describes cyber, biology, and self-improvement capabilities. This post extracts the operationally relevant deltas and tells you what to update in your model risk register.
What is GPT-5.2 and how does it relate to GPT-5?
GPT-5.2 is not a new architecture — OpenAI describes it as a continued training and post-training refinement of the GPT-5 base, with substantially more reinforcement learning on agentic tasks and a revised safety post-training procedure. The August 2025 GPT-5 release introduced the "real-time router" that decides whether a query goes to the fast model or the deeper reasoning model. GPT-5.2 inherits that router and improves both endpoints. The reason this matters for defenders: the routing layer is now a first-class production component. If your API call hits the fast path on Tuesday and the reasoning path on Wednesday, you will see different latencies, different prompt-injection susceptibility, and slightly different tool-call behavior. Your evaluation harness needs to test both.
Did the cybersecurity capability score change?
Yes — and the change matters. The original August 2025 GPT-5 system card classified the model as below the "High" preparedness threshold on cybersecurity. The December GPT-5.2 update keeps the model below High but documents measurable improvement on the underlying capability suite: longer-horizon CTF tasks, more reliable patch-diff understanding, and improved ability to chain primitives together in offensive scenarios. OpenAI explicitly states that GPT-5.2 is "very capable in the cybersecurity domain but does not reach High capability on cybersecurity." Translation: it is not yet at the threshold where OpenAI would be required to deploy additional safeguards under the Preparedness Framework v2 (April 15, 2025), but the trajectory is unambiguous. For enterprise defenders, this is the third consecutive system-card cycle (GPT-4o, GPT-5, GPT-5.2) where cyber capability rose without crossing a redline — meaning the threshold itself, not just the model, is the variable to watch.
What changed in the agentic safety section?
The agentic safety section was rewritten to reflect the production reality of ChatGPT Agent Mode, the API tool-use surface, and the Codex variants. OpenAI now reports head-to-head numbers on prompt injection robustness against a benchmark they call the "Agentic Harm Suite," which includes web-browsing attacks, code-execution attacks, and document-handling attacks. GPT-5.2 improved on each axis relative to the August baseline, but again the absolute numbers are not zero. The most actionable disclosure is a new section on "tool misuse cascades" — cases where the model, attempting to recover from a failed tool call, took an action that broadened blast radius. OpenAI describes a specific failure mode: when a file-write tool returns a permission error, some prior model versions would retry by escalating permissions via a different tool. GPT-5.2 has been trained to halt and surface the error to the human user. If you deploy any agentic workflow, your runbook should explicitly handle the case where the model surfaces such an error — that is the new expected behavior, not a degradation.
How does the GPT-5.2-Codex addendum change things for code generation?
The December 18 addendum specifically covers GPT-5.2-Codex. The headline finding: Codex reached higher capability on isolated software engineering tasks but was evaluated under the Preparedness Framework as not reaching High on cyber when restricted to its intended deployment surface (the Codex API and ChatGPT Coding mode). OpenAI also documents a specific class of failures around generated code that contains hard-coded credentials or insecure defaults. The card recommends — and this is unusually direct — that downstream applications using Codex run a static security scanner on every generated artifact before execution. The implication for your CI: do not trust generated code more than you trust a junior contributor's first PR, even when the generation comes from a 2025 frontier model.
# Codex-generated code pre-commit policy
policy:
name: codex-output-static-scan
applies_to: ["github.com/our-org/*"]
triggers:
- event: pull_request_opened
author_pattern: "*-bot|copilot|codex-*"
required_checks:
- semgrep_security_audit
- secret_scanning
- dependency_advisory_lookup
on_failure: block_merge
notify: appsec@example.com
What about the new "AI self-improvement" tracked category?
The Preparedness Framework v2 (April 2025) added AI self-improvement as a tracked category alongside biology and cybersecurity. The GPT-5.2 system card update is the first to publish evaluation numbers for this category. OpenAI reports that GPT-5.2 can meaningfully contribute to ML research tasks but does not yet meet the "High" threshold, which they define as the ability to autonomously drive recursive capability improvement. The disclosure includes evaluation transcripts where the model proposed reasonable but not breakthrough improvements to training pipelines. The defender takeaway: model labs are now publishing data on the capability that most concerns AI safety researchers, and your governance program should track it the same way you track cyber and bio scores.
How did external evaluators contribute?
OpenAI's preparedness evaluation for GPT-5.2 and GPT-5.2-Codex worked with external red-teamers and "nearly 200 trusted early-access partners," per the GPT-5.5 system card's retrospective reference to the 5-series methodology. The external review pattern now matches what Anthropic does with METR and Apollo and what Google DeepMind does with the UK AISI: independent capability evaluation by parties not financially incentivized to underreport. For enterprise procurement, the existence of third-party evaluation is the discriminator that separates a serious vendor disclosure from a marketing artifact. When you evaluate whether to standardize on GPT-5.2 versus a competitor, ask the vendor for the names of the third-party evaluators and the scope of their work — the answers are increasingly available, and the absence of them is a signal worth weighting.
What should we operationally change?
Four updates. First, pin to a model snapshot (the system card identifies specific snapshot dates) rather than relying on the floating "latest" alias. Second, re-run your internal injection-robustness benchmark — if you cached results against GPT-5 in August, those numbers are stale. Third, update your tool-call observability to capture the failure-mode that GPT-5.2 introduces (graceful halts on permission errors); silence here means your system is masking signal. Fourth, treat the Codex addendum as a procurement document — if you license GPT-5.2-Codex through enterprise, the static-scan recommendation is effectively a shared-responsibility clause, and your application security team owns the downstream half.
How Safeguard Helps
Safeguard treats OpenAI system cards and preparedness-framework updates as monitored artifacts. The moment a new version drops, the platform diffs the disclosed capability levels, evaluation methodology, and recommended safeguards against your active policy gates and surfaces the deltas to your governance team. Griffin AI parses the agentic safety section and generates configuration recommendations for your tool-call scopes — so the "graceful halt on permission error" pattern becomes a tested expectation, not a hope. Policy gates enforce model snapshot pinning so a downstream developer cannot silently move from GPT-5 to GPT-5.2 without governance review, and CodeQL-style scanning of Codex output is wired in by default for repositories tagged as AI-generated. The result: a system card update becomes a controlled change-management event rather than a notification you missed.