AI coding environments are turning repositories into more than collections of source code. Repositories can now contain instructions for agents, tool definitions, MCP configuration, hooks, workflows, skills, environment settings, and persistent context.
That creates a sequencing problem: when does repository-controlled material become operational?
The answer should be before execution only after its authority standing has been established.
A trust prompt can arrive too late
Security vulnerabilities in AI coding tools have demonstrated the danger of processing repository-controlled configuration before the user has completed a trust decision. If an untrusted workspace can redirect an endpoint, activate a hook, invoke a tool, or otherwise influence execution before the trust boundary is resolved, the later approval is not truly a pre-execution control.
The consequential effect may already have occurred.
That suggests a general enterprise invariant: authority-sensitive context must not become operational before its standing is established.
An AI agent may inspect untrusted material as data. It should not automatically treat that material as instructions with authority.
Repositories cannot authorize themselves
This matters because agent instructions increasingly live alongside code. Files such as AGENTS.md, CLAUDE.md, MCP manifests, workflow definitions, generated task files, and tool descriptions can materially influence what an AI agent does.
Their presence in a repository proves only that the content exists. It does not prove who authorized it, what scope it governs, whether it is current, or whether it should be allowed to influence a consequential action.
The repository can contain instructions. It cannot authorize those instructions.
An enterprise authority layer therefore needs to qualify the source and standing of instruction-bearing artifacts before they are allowed to change the operational behavior of an agent.
The GitHub implication
This distinction is particularly important in pull requests and external contributions. A malicious or simply over-broad change can introduce an instruction, workflow, dependency, MCP server, hook, or configuration file that alters how an AI coding agent behaves.
Native GitHub controls remain essential. Branch protection, required reviews, workflow permissions, environment protections, and application permissions should continue to enforce technical boundaries.
Authrizd addresses a different question: does legitimate enterprise authority exist for the exact influence or effect crossing that boundary?
A pull request may be readable by an agent without being authorized to rewrite the agent's operating instructions. A repository may be approved for code changes without being approved to add a new external MCP server. A developer may be allowed to modify application code without being authorized to weaken deployment controls.
Proof Before Execution is an ordering rule
Proof Before Execution is not simply a slogan. It implies an ordering constraint.
First establish the authority standing of the principal, instruction, resource, purpose, and proposed effect. Then allow the consequential action.
If the system asks for trust only after untrusted context has already executed, the order is reversed.
As AI coding agents become more autonomous, this sequencing becomes more important, not less. Agents will ingest more context, use more tools, and operate across more repositories and systems. The enterprise cannot assume that everything reachable by the agent is entitled to govern the agent.
Trust after execution isn't a control.
Sources
https://www.incibe.es/en/incibe-cert/early-warning/vulnerabilities/cve-2026-21852
NEXT STEP