TL;DR
- OpenAI released Codex Security, a public CLI and TypeScript SDK for finding, validating and fixing vulnerabilities in your own code, with scan history kept locally and the tool designed to run inside CI.
- A frontier lab shipping public hardening infrastructure signals the agent access problem is now treated as serious enough to carry a company’s name.
- Readers can run
npx codex-security scan .against a repository, authenticating with a ChatGPT login or an API key, and get findings before a vulnerability ships. - The gap is acknowledged: the tool scans code an agent might touch and says nothing about the agent’s own credentials, write access or blast radius while it runs.
In plain English
A CLI is a command-line tool; an SDK is a code library another program can call. CI, or continuous integration, is the automated pipeline that runs checks every time code is committed, so putting a scanner there means vulnerabilities get flagged before the code reaches production. Codex Security does static work of this kind: it inspects a repository and reports weaknesses in it.
The problem that stays separate is standing access. An authenticated agent holds credentials, can write to particular files and can reach particular systems, and the “blast radius” is how much damage follows if it goes wrong mid-task. Least privilege is the principle of granting only what the immediate job requires. Scanning a codebase does nothing to constrain a running agent’s reach, and two distinct problems currently share the single word security.
The question I keep returning to in this newsletter is what an agent can reach once it’s already authenticated and working, and whether anything in its design gives it a sense of should versus can. Whether an agent can be tricked into leaking a password is well understood at this point and mostly guarded against. OpenAI’s Codex Security release this week is a direct answer to that question, and it’s worth taking seriously precisely because it reads as an admission.
Codex Security is a public CLI and TypeScript SDK for finding, validating, and fixing vulnerabilities in your own code, with scan history kept locally in a workbench directory and the whole thing designed to slot into CI. Run npx codex-security scan . against a repository, authenticate with either a ChatGPT login or an API key, with explicit precedence rules for which one wins when the run is noninteractive, and get findings back before a vulnerability ships rather than after. The mechanics are straightforward. What’s notable is who’s publishing them.
Plenty of tools find vulnerabilities in code, and have for years. The new part is a frontier lab building and shipping public hardening infrastructure aimed squarely at the failure mode that gets discussed constantly and solved rarely: an agent operating with more standing access than a given task requires, with no built-in instinct for restraint. Wiring Codex Security into a pipeline doesn’t fix that problem directly. It fixes a narrower one, code that ships with known vulnerabilities, but it’s a tell that the broader problem is now considered serious enough to justify a company’s name on public tooling around it.
There’s a real gap left uncovered, and it’s worth being specific about where. Codex Security scans the code an agent might touch. It says nothing about what the agent itself can do once it’s actually running: which credentials it holds, which files it can write to, what the blast radius looks like if something goes wrong mid-task. Two different problems that get discussed under the same word, security, and only one of them has a public tool built for it now.
Still counts as forward motion. A year ago the entire conversation was about whether a model could be prompted into revealing a secret. Now a lab is shipping CI infrastructure for the code an agent touches on its way somewhere else. Slow and unglamorous, which is usually what it looks like once a problem stops being interesting and starts being someone’s actual job.