The previous Dispatch argued that SECURITY.md can become a machine-discoverable entry point for security intent. The next architectural question is harder: what happens when an agent discovers more than one source of repository intent—and those instructions do not cleanly agree?
OpenAI’s current Codex guidance makes AGENTS.md part of the model’s working context: Codex discovers applicable files from global and repository scopes and loads them in root-to-leaf order, with more local instructions able to override broader ones.[1] OpenAI-owned repositories also demonstrate that AGENTS.md can carry workflow constraints, approval expectations, security handling, and instructions to consult SECURITY.md for security-specific policy.[2][4]
That gives us two different instruction surfaces with two different jobs. The mistake would be to treat one as handing control to the other.
Two Files, Two Responsibilities
In the architecture we are examining, AGENTS.md expresses repository-specific workflow intent: where to work, which commands or checks are appropriate, what constraints apply, and where human approval is required. OpenAI’s own codex-security repository uses AGENTS.md to constrain repository work, preserve credential protections, define validation expectations, and make clear that repository contents are data rather than permission to access another target or write outside an approved path.[2]
SECURITY.md serves a different purpose. In the same repository, OpenAI uses it to define what qualifies as a security issue, which permissions and enforced restrictions matter, what must be reported, and the boundaries under which scans should operate.[3] That is security-policy context, not a workflow runbook.
The distinction matters because an agent can encounter both at the same time. The files are complementary, but neither file should be interpreted as granting new authority merely because it exists in the repository.[2][3]
Reconciliation Is the Missing Step
The architectural move is not AGENTS.md → SECURITY.md. It is:
declared workflow intent + declared security intent → reconciliation → bounded next action
Reconciliation means reading the applicable instructions, comparing the material constraints, and determining whether they agree on the action that is about to occur. The relevant questions are concrete: Is the target in scope? Is the proposed command permitted? Are credentials involved? Does the security policy exclude this test? Is approval required before the next side effect? Is information missing that changes the answer?
OpenAI’s public documentation describes how Codex loads AGENTS.md, how approvals and guardrails can interrupt sensitive actions, how skills package reusable instructions, and how hooks can participate in runtime control.[1][5][6][7] The authority set used for this companion does not document a built-in command that automatically reconciles AGENTS.md against SECURITY.md. The reconciliation layer shown here is therefore a Luminity architectural interpretation, not an OpenAI product guarantee.
That distinction is structural. Discoverability tells the agent what the repository says. Reconciliation determines whether the applicable instructions agree. Neither operation, by itself, determines whether the action can actually occur.
AGENTS.md and SECURITY.md expose complementary repository intent. Reconciliation determines whether the applicable instructions agree; material conflict or ambiguity pauses the affected action for human decision. Independent controls—not Markdown files—govern consequential effects.Conflict Should Stop the Affected Action
If the instructions agree, the agent can proceed to the next action that is already inside the authorized scope. That is a bounded progression, not a new grant of authority.
If the instructions materially disagree—or if the information required to determine scope, permissions, permitted tests, or security controls is ambiguous—the affected action should stop for human decision. OpenAI’s guardrail guidance explicitly recommends evaluating sensitive tool calls before execution, pausing ambiguous or high-risk actions for human approval, and failing closed when review becomes unavailable.[5]
This is not the same as stopping the entire workflow. Safe, authorized read-only preparation may still be possible while the disputed action remains blocked. The architectural requirement is narrower: unresolved ambiguity must not silently become permission.
Human intervention is therefore not an exception to agentic execution. It is a deliberate state transition in a governed workflow: clarify the instruction, confirm the scope, authorize the action, change the plan, or keep the action blocked.
Enforcement Still Lives at the Side-Effect Boundary
Repository instructions can shape reasoning, but they are not enforcement mechanisms.
OpenAI’s cybersecurity guidance places enforcement at the point where sensitive tool calls create side effects: validate the proposed target, action, arguments, identity, and engagement scope; deny prohibited actions; pause ambiguous or high-risk operations; and preserve independent filesystem, network, identity, and project boundaries.[5] OpenAI’s plugin documentation likewise distinguishes reusable skills from lifecycle hooks and tool approval policy, with hooks requiring explicit trust before they run.[6][7]
This creates a clean separation:
Declared intent — what AGENTS.md and SECURITY.md say.
Reconciled intent — whether those instructions agree for the proposed action.
Enforced effects — whether trusted controls permit the consequential action to execute.
The first two guide judgment. The third constrains reality.
From Guidance to Guarantee
The same distinction gives enterprises a useful implementation ladder.
A one-time prompt can request a conflict check. A root AGENTS.md rule can make that behavior a repository default. A reusable skill can standardize discovery, comparison, conflict reporting, and escalation across workflows.[6] A trusted hook, approval policy, guarded MCP or tool boundary, runtime authorization layer, repository protection, or resource-side control can enforce the consequential boundary.[5][7]
These mechanisms should not be treated as equivalent. Moving from prompt to repository instruction to skill increases repeatability. It does not automatically increase enforcement strength. The guarantee begins only where an independently trusted control can deny or interrupt the action.
Limits and Boundaries
This companion does not claim that every disagreement between repository files requires escalation. Some instruction precedence is explicit, and OpenAI documents root-to-leaf precedence for applicable AGENTS.md files.[1] Ordinary differences that can be resolved through a documented hierarchy do not need to become human checkpoints.
The boundary is material unresolved conflict or ambiguity: disagreement that changes scope, permissions, credential handling, permitted tests, required controls, or another condition governing a consequential action.
Nor does this architecture claim that SECURITY.md is automatically loaded or reconciled everywhere that AGENTS.md is loaded. The public sources used here document automatic AGENTS.md discovery in Codex, while SECURITY.md remains repository content that must be inspected when the workflow or repository instructions make it relevant.[1][2][4]
Finally, neither document can expand the authority already granted by the user, engagement, configured workflow, or enforced system controls. Repository context can narrow or clarify an action. It should not manufacture permission.
Discoverability exposes intent. Reconciliation determines whether the instructions agree. Enforcement determines whether the consequential action can occur.
SECURITY.md
