More context does not give a coding agent more control.
Control comes from the system around the model.
OpenAI and GitHub preserve agent activity for review.
Neither treats an agent's completion message as release authority.
Save this six-gate contract for your next repository setup.
Last verified against OpenAI, GitHub, and NIST guidance. Version-specific details drift — check the vendor docs before relying on an exact flag or limit.
Why a longer system prompt fails as a control plane
A system prompt can describe desired behavior. It cannot revoke a cloud credential, block an outbound connection, or restore a database.
That distinction matters because coding agents operate through tools. The model proposes an action, but the shell, filesystem, network, browser, and connected services determine what can happen.
OpenAI describes its internal Codex deployment in the same terms: bounded environments, easy access for low-risk actions, and explicit review for higher-risk actions.
Its telemetry covers prompts, approvals, tool results, MCP use, and network decisions. OpenAI's operating account treats control as an engineered system rather than a better paragraph.
GitHub's coding-agent design also preserves session logs, signed commits, CI state, and human review before merge. GitHub's responsible-use documentation separates traceability from authority: a visible trail helps a reviewer decide, but it does not make the decision.
The wrong frame is "How do I make the agent obey?"
The useful question is "Which actions can this run take, which evidence must it return, and who can accept the result?"
By the end you will have
- A six-gate model for coding-agent control.
- The Six-Gate Coding-Agent Control Matrix for one repository.
- A copyable standing protocol for every agent run.
- Failure signals that show which gate broke.
- A product path for installing the files or learning the full method.
The Six-Gate Control System makes agent work reviewable
The gates run in order. A later gate cannot repair an earlier omission.
1. Authority bounds the job
Define the requested outcome, allowed paths, forbidden paths, permitted tools, network access, credential scope, and approval owner before execution.
"Fix checkout" is not a boundary. "Change the purchase button and checkout-session route; do not change price records, fulfillment, email delivery, or production data" is reviewable.
Prefer enforcement over prose. Give the run a read-only credential when it only needs to inspect. Restrict write access to the named repository. Require approval before deployment or payment changes.
2. Capability admission controls what enters the runtime
Skills, MCP servers, plugins, hooks, and repository scripts extend what an agent can read or do. Treat each one as code entering a privileged execution path.
Record its source, version or digest, requested permissions, network behavior, install steps, and review owner. Re-vet it when the content, permissions, or upstream owner changes.
Use the Skill Trust Gate when the capability arrives as a third-party skill. It turns provenance and privilege into a pre-install record.
The purpose is not to label every extension safe forever. It is to preserve the decision that allowed a specific revision into a specific boundary.
3. Isolation limits the blast radius
Run untrusted or broad tasks in an ephemeral branch, worktree, container, or sandbox. Use scoped environment variables and deny network access unless the job needs it.
Isolation does not prove the code is correct. It makes a wrong action cheaper to contain.
A useful rule is proportionality: the more irreversible the side effect, the smaller the agent's initial authority. Reading source and drafting a patch can be automatic. Publishing, migrating data, rotating secrets, or spending money should stop for a named human decision.
4. Evidence makes the result challengeable
Require exact commands, exit codes, relevant output, changed files, skipped checks, and artifact locations. "Tests passed" hides which tests ran and what they did not cover.
OpenAI recommends reviewing agent work before production changes and exposes terminal logs, test results, and citations to support that review. GitHub links agent-authored commits back to session logs. Both patterns preserve evidence without pretending the evidence is approval.
Independent checks matter. If the same model writes the patch, selects the tests, runs them, and explains why the result is safe, one mistaken assumption can survive every step. Add deterministic linters, tests, policy checks, or a second reviewer that does not inherit the agent's conclusion.
If a run keeps failing after a model change, use the Harness Failure Matrix to isolate state, environment, tool, grader, and reconciliation failures before changing the control policy.
5. Release authority stays separate from execution
Name the person or policy allowed to merge, deploy, publish, spend, or mutate production data.
The agent can prepare the release case. It should not silently promote its own work because its local checks are green.
This is a decision-rights problem, not a model-intelligence problem. NIST's AI Risk Management Framework organizes risk work around govern, map, measure, and manage, with governance running across the lifecycle. NIST describes the framework as continuous rather than a one-time checklist.
6. Recovery closes the loop
Record the rollback trigger, exact reversal action, data-restoration step, owner, and post-rollback verification.
"Revert the commit" is enough only when the commit is the entire side effect. A schema migration, webhook replay, customer email, or rotated credential needs a different recovery action.
After a failure, write the lesson back into the boundary, test suite, admission record, or runbook. Recovery without learning restores service but leaves the system ready to repeat the incident.
Magnet: Six-Gate Coding-Agent Control Matrix
Use one row for each gate. Keep the cell short enough that a reviewer can challenge it in a pull request.
| Gate | Question | Repository evidence |
|---|---|---|
| Authority | What may this run change or call? | Task contract, allowed paths, tool and credential scope |
| Admission | Which external capabilities are trusted? | Source, digest, permission review, re-vet trigger |
| Isolation | Where does the run execute? | Branch or sandbox, network policy, secret scope |
| Evidence | What must prove the result? | Exact commands, exit codes, artifacts, known gaps |
| Release | Who may accept the side effect? | Named approver and protected action |
| Recovery | How does the change come back out? | Trigger, rollback command, data action, owner |
Start with one repository and one recurring job. Do not build a platform before the matrix exposes a real repeated need.
You should see: every gate has an owner or artifact, and a reviewer can reject the run without reconstructing the agent's conversation.
A standing protocol keeps the six gates attached to every run
Put the stable rules in AGENTS.md or the repository's equivalent. Keep task-specific facts in the task itself.
Use this compact protocol as a starting point:
CODING-AGENT CONTROL PROTOCOL
Before work:
- Restate the outcome, allowed paths, and exclusions.
- List required tools, network access, and credentials.
- Stop if a required capability is not admitted.
During work:
- Work in the assigned branch or sandbox.
- Do not expand scope without approval.
- Preserve commands, results, and unexpected changes.
Before completion:
- Run the named deterministic checks.
- List changed files, known gaps, and skipped checks.
- State the release approver and rollback action.
- Do not deploy, publish, spend, or mutate production data.Pair this with a task template that names the acceptance criteria and verification commands. Stable policy and temporary task context age at different speeds. Mixing both in one giant prompt makes every update harder to review.
Failure modes identify the missing gate
Prompt-only safety: the instructions say "do not touch production," but the run holds a production token. Fix the credential boundary.
Capability drift: an installed skill or MCP server changes after review. Preserve a digest and define a re-vet trigger.
Self-certified completion: the agent writes the test and treats the passing result as merge authority. Add an independent check and a named approver.
Evidence dump: the run saves a full transcript but no decision-grade summary. Require exact checks, results, gaps, and artifact links.
Rollback fiction: the plan says "revert" after an irreversible external action. Test the actual recovery path before granting that authority.
Control theatre: every gate exists as prose, but no technical mechanism or owner enforces it. Test one denied action and one recovery action.
When not to build a full coding-agent control system
Do not install a large control layer for a throwaway local experiment with no secrets, shared repository, external side effect, or production path.
Use the smallest boundary that matches the risk. A disposable branch, no network, no credentials, and one verification command may be enough.
Do not automate a job you cannot review manually. First run the work yourself, record the evidence you used to decide, and then automate the stable portion.
Do not confuse governance with guaranteed correctness. These gates improve containment, traceability, and decision quality. They cannot prove that every requirement, threat, or production condition was covered.
Frequently asked questions
Is a coding-agent control system the same as an agent framework?
No. A framework helps the agent plan or act. A control system limits authority, admits capabilities, preserves evidence, assigns release rights, and defines recovery around any framework.
Does this require a multi-agent setup?
No. One coding agent benefits from the same boundary. Add more agents only when their roles and handoffs reduce a measured bottleneck.
Can CI be the release authority?
CI can enforce deterministic policy. A protected branch may allow an automated merge after all required controls pass. The decision is still encoded by a human-owned policy, not invented by the agent during the run.
How often should the matrix be reviewed?
Review it when the repository, credentials, tools, side effects, approvers, or recovery path changes. A calendar review can catch neglect, but change is the stronger trigger.
Agent extraction record
- Objective: keep coding-agent changes bounded, reviewable, and recoverable.
- Inputs: task contract, repository policy, admitted capabilities, environment scope, verification commands, and recovery procedure.
- Process: bound authority, admit capabilities, isolate execution, collect evidence, obtain release approval, and preserve recovery.
- Outputs: changed files, verification record, known gaps, approval state, and rollback plan.
- Guardrails: no silent scope expansion, no unreviewed capability, no self-approved production side effect, and no release without a credible recovery action.
The Production Agent OS Kit provides editable operating contracts for these gates. The Production Agent Systems Course teaches the full method through modules, labs, and a capstone. Use the Six-Part Release Receipt when the immediate problem is one agent-authored release.
Control is not more text around the model. It is a boundary before the run, evidence after the run, and authority at the decision.
Your next action: copy the Six-Gate Coding-Agent Control Matrix into one active repository and fill the authority and recovery rows before the next agent run.
