GPT-5.1-Codex-Max system card is worth reading, but trust it in proportion to its limits specificity

A system card is dry reading. But for coding agents that can propose changes to production repositories, dry reading with specific limits is exactly what you need before deployment.

The GPT-5.1-Codex-Max system card describes two safety layers: model and product

The document covers safety at two levels. At the model level: specialized safety training for harmful tasks and protection against prompt injection. At the product level: agent sandboxing and configurable network access. This distinction matters: model alignment is not enough if the product around it has overly broad permissions. Configurable network access means an operator can set what the agent is allowed to call and what it is not, which is a basic requirement for enterprise deployment.

For enterprise security and DevSecOps teams, this is the first document checkpoint before a POC

A company considering deploying GPT-5.1-Codex-Max needs answers to specific questions: what are the known limitations, how does indirect prompt injection work in a repository context, what are the default sandbox settings. A system card is where these answers should be. If they are vague, that is a signal for further questions before signing a contract.

A vendor-issued system card is not an independent audit, and the known limitations section is what actually matters

A system card issued by the vendor is not an independent audit. OpenAI has an interest in making the document look thorough; the interest in publishing serious limitations is naturally weaker. The most important part of the document for security evaluation is known limitations and residual risks, not the list of mitigations. The source page returned 403 during verification.

How specific the known limitations are and whether a third party has verified them determines whether this is an operational document or PR

Watch the specificity of evaluations, the list of known limitations, and protection against indirect prompt injection. If the system card is vague and contains no sharp limits, it is a PR document. If it describes where the model fails and what guarantees are missing, it is an operational document you can plan a deployment from.

Lilith's verdict

A system card is trustworthy to the degree it is specific about its limitations. A document with more mitigations than known limitations tells you more about the PR team than about the model.