SECURITY.md is not a new artifact. For years, repositories have used it to tell researchers and maintainers how to report vulnerabilities, what is in scope, and where disclosure should happen. That role remains important. What is changing is the architectural significance of the file in repositories that are increasingly reviewed by both people and security agents.Current OpenAI repositories show a pattern worth paying attention to: the repository security policy can now point directly to a canonical threat model, define what should be considered reportable, and tell security analysis which trust boundaries, attacker capabilities, objectives, exclusions, and severity assumptions govern the review. [1][2][3][4]
Our interpretation is simple: SECURITY.md is beginning to function as more than a disclosure notice. In agentic software, it can become a machine-discoverable entry point for security intent.
1. The Familiar File
The established role of SECURITY.md is straightforward. OpenAI’s current Node SDK policy directs vulnerability reports into OpenAI’s coordinated disclosure process, prohibits undisclosed vulnerabilities from being posted through public issues or pull requests, and asks reporters to identify the affected product or release, impact, reproduction steps, and relevant runtime context. [1] OpenAI’s coordinated vulnerability disclosure policy provides the broader reporting framework behind that repository-level instruction. [6]
That is the familiar pattern: a repository carries a security policy close to the code so a researcher does not need to guess how a security issue should be handled.
The pattern remains visible elsewhere. Anthropic’s Claude Code repository, for example, uses SECURITY.md to direct validated vulnerabilities into Anthropic’s security reporting process. [8] That is useful corroboration, but the more interesting development for this Dispatch is what OpenAI is doing beyond disclosure.
2. Something Is Changing
In the OpenAI Node SDK, .github/SECURITY.md explicitly identifies itself as the repository’s canonical security policy and points Codex Security scans to docs/architecture/security-model.md as the canonical detailed threat model. It tells the scan to load that model from the exact scanned revision when deciding scope, trust boundaries, attacker capabilities, security objectives, exclusions, reportability, and severity. [1]
The referenced security model then does what the policy says it will do. It describes the repository’s architecture, data and authority paths, trust assumptions, threat scenarios, security objectives, and severity calibration. It also says that the scenarios are hypotheses and calibration examples rather than findings. [2]
The Python SDK uses the same separation. Its SECURITY.md remains authoritative for coordinated disclosure, while a separate repository-owned threat model carries the trust boundaries, reportability guidance, and severity calibration used by Codex Security scans. [3][4]
This separation is subtle but consequential. The policy file does not need to become a giant threat-model document. Instead, it can serve as the repository-level authority that tells a reviewer—or an agent—where the real security model lives and which revision governs the analysis.
SECURITY.md can remain the repository’s security-policy entry point while directing reviewers and agents toward a deeper canonical security model. Discoverable intent informs review; independent controls still enforce the boundary.3. Why Agents Change the Significance
A human security engineer can infer context from architecture documents, issue history, source code, CI configuration, and team convention. An automated reviewer cannot safely rely on the same amount of tacit organizational knowledge.
It needs explicit context.
OpenAI’s Agents SDK security policy shows the direction clearly. Reports are expected to identify who controls the input and which trust boundary is crossed. The policy also separates prompt injection or an unsafe application-defined tool from an SDK defect unless an SDK-enforced boundary is actually bypassed. It tells reviewers to examine credentials, tool approvals, sandbox boundaries, resource ownership, CI authority, and publication paths as concrete security properties. [5]
OpenAI’s Codex Security policy sharpens the same distinction: a reportable flaw requires a less-privileged attacker to bypass an enforced security restriction. Prompt injection or a model misusing access it already possesses does not qualify by itself; there must be a separate failure in an enforced control. [7]
That distinction matters for agentic security because agents can reason over repository content. A security agent that can discover the repository’s policy, then follow it to the correct threat model, begins its review with substantially better context than an agent operating from generic vulnerability heuristics alone.
The repository is no longer carrying only code and contribution instructions. It can also carry the security assumptions required to interpret that code correctly.
4. Machine-Discoverable Security Intent
This is where we move from documented repository behavior to architectural interpretation.
We see SECURITY.md becoming a practical entry point for machine-discoverable security intent.
The phrase is ours. OpenAI does not describe the pattern in those words. What OpenAI does document is enough to support the underlying architecture: a canonical repository security policy can identify the authoritative threat model; that model can define trust boundaries, attacker capabilities, security objectives, exclusions, reportability, and severity; and Codex Security can be instructed to consume that model from the relevant repository revision. [1][2][3][4]
That creates a useful hierarchy:
SECURITY.md establishes security-policy authority. The canonical security model explains what the repository considers a meaningful boundary and security failure. Human and automated reviewers consume that context. Independent controls remain responsible for preventing or containing the effect.
The value is not that Markdown becomes a control plane. It does not.
The value is that security intent becomes discoverable in the same environment where code, agent instructions, CI workflows, and release mechanics already live. Instead of forcing every reviewer to reconstruct the security model from scratch, the repository can declare where authoritative security reasoning begins.
5. The Enterprise Implication
For enterprises building agentic software, the pattern suggests a clean separation of responsibilities.
The security policy should establish scope, ownership, disclosure expectations, and the authoritative path to the security model. The canonical security model should define trust boundaries, attacker assumptions, protected assets, security objectives, exclusions, reportability criteria, and the conditions that should trigger re-review. The enforced controls should remain independent: authorization, runtime containment, repository protections, resource-side policy, network boundaries, approvals, and other mechanisms that actually constrain effects.
Those three layers should connect, but they should not collapse into one another.
That distinction becomes increasingly useful as enterprises introduce coding agents, security agents, automated pull-request review, and other repository-aware systems. If the repository can expose not just what the software does but how its security boundaries are meant to be interpreted, agents can operate against an explicit architectural frame rather than an inferred one.
For us, that is the larger signal in the current OpenAI pattern. SECURITY.md is still a disclosure file. It is also becoming a natural place to declare where the repository’s security authority starts.
Limits and Boundaries
This pattern should not be overstated. A SECURITY.md file does not prove that the documented threat model is complete, current, or correctly implemented. A threat model does not prove that runtime controls are healthy. A security scan does not prove that all consequential paths were examined. OpenAI’s own repository guidance preserves those distinctions, including the difference between model behavior and failure of an enforced security boundary. [5][7]
Nor should every enterprise copy OpenAI’s repository structure mechanically. The exact file layout is less important than the architectural property: an authoritative, versioned, discoverable path from repository security policy to the security model that governs review.
Machine-discoverable intent is therefore an input to assurance, not assurance itself. Enforcement still has to happen at the boundary where an effect can occur.
As software becomes increasingly reviewed and modified by agents, security architecture needs a repository-native way to declare its own interpretive boundaries. SECURITY.md can become that entry point: not by enforcing security, but by making the authoritative security model discoverable to the humans and agents expected to reason about the system.
The durable principle is straightforward: discoverable security intent should guide review; independent controls should govern execution.
SECURITY.md