Production approval as a system boundary

A production gate is enforced by identity, credentials, branch protection, and the deployment platform—not by a sentence in a prompt or an environment variable an agent can set. The agent may prepare code, tests, review evidence, a release plan, and rollback instructions. A named human approves the protected production job, and the deployment audit links that decision to an immutable revision.

Scorecard question: What controls stop an agent from deploying unvetted changes directly to production?

Maximum-score answer: The agent environment has no standing production credentials; protected branches and a restricted CI environment require named human approval and preserve an audit trail.

Four independent controls

1. Identity: agent commits and CI jobs use distinct service identities.
2. Credentials: local sessions and general agent runners never receive production secrets. A protected job obtains short-lived credentials only after approval.
3. Repository: direct pushes and bypasses are blocked; required checks and code-owner rules apply by path and risk.
4. Deployment: the production environment requires an authorized approver and records revision, evidence, actor, time, and result.

Hooks can block obvious local commands as defense in depth. They are not the authorization boundary: aliases, wrappers, alternate clients, or compromised scripts can bypass prefix matching.

Tool-specific local containment

Use the strongest mode supported by the current surface, then rely on the external controls above:

• Claude Code: configure permissions and hooks from the current official hook schema; keep production credentials absent.
• Cursor CLI: use --sandbox enabled where appropriate and do not use --force to bypass approvals in governed work.
• Codex CLI: prefer --sandbox workspace-write for implementation; set approval policy separately and do not treat deprecated --full-auto as a production policy.
• All tools: run in an isolated worktree with local or ephemeral dependencies, never a checkout wired to live production state.

Release evidence contract

Before the human sees an approval button, the job should expose:

• linked intent.md, spec.md, plan.md, and exact revision;
• deterministic test, lint, type, security, and migration results;
• focused agent-review findings with dispositions;
• deployment scope, blast radius, observability queries, and rollback procedure;
• missing checks, exceptions, and their owners;
• artifact signatures or provenance where the platform supports them.

The approver must be able to reject without revealing production credentials to the agent.

Prompts to copy

Prepare a production-readiness report for this exact revision.
Link intent.md, spec.md, plan.md, CI results, security findings,
migration and rollback evidence. Separate passed, failed, skipped,
and manual checks. Do not deploy, approve, or access production.

Review the release evidence as a skeptical operator.
List blockers, missing rollback proof, unowned manual checks,
and any mismatch between the approved plan and the revision.
Return a recommendation only; the named human owns the decision.

Do not use RELEASE_APPROVAL=true as proof

A shell variable is not an authenticated human decision. Use the deployment platform’s protected environment and identity audit.

Failure modes

The local hook is the only barrier. Remove production credentials from the environment and enforce the boundary at the forge and deployment platform.

The bot can bypass branch protection. Remove administrative bypass and test with the actual service identity.

Approval happens before evidence is complete. Make evidence checks prerequisites of the protected environment.

Emergency access becomes permanent. Time-bound break-glass credentials, log every use, and require post-incident review.

Verify the boundary

• A local and cloud agent cannot enumerate or use production credentials.
• Direct push and self-approval fail under the real agent identity.
• The protected job cannot start without an authorized named approver.
• The approval references one immutable revision and its evidence.
• Rollback is rehearsed without granting the implementation agent production access.
• Audit logs distinguish author, reviewer, approver, deployer, and result.

Keep the gate in the lifecycle

Apply the layered review from Deploy and the action tiers from Governance and autonomy.

Official references

• Claude Code hooks
• Cursor CLI parameters
• Codex developer commands

Q21 · Rollback pipeline Rehearse recovery without weakening production access.

Artifact chain Attach release evidence to accepted intent.