How to govern coding agents in production

Giving a coding agent production write access is a leadership decision disguised as a permissions change. A founder should bring in outside technical leadership before granting that access when nobody inside the company can define the boundary, enforce independent approval, reconstruct an agent's actions, and take command of a bad deployment. If your team can already do those things and one named executive accepts the risk, an outside leader may add little.

The model's coding quality is not the deciding factor. Production safety depends on the control system around the agent: what identity it receives, which actions that identity can perform, who releases a blocked action, what evidence survives the session, and who can stop or reverse the result. I have seen competent teams concentrate on whether an agent writes good code while leaving the deployment credential, approval path, and incident role vague. That order is backward.

Production write access reaches further than the server

Production write access means any capability that can change customer-visible behavior, stored data, security boundaries, availability, or the evidence used to investigate those changes. Direct shell access to a production host obviously qualifies. So do merge rights on a release branch, permission to edit a deployment workflow, access to production feature flags, database migrations, infrastructure plans, package publishing, secret rotation, and the ability to alter monitoring rules.

Founders often approve one narrow-sounding permission and miss the chain behind it. An agent that can modify a workflow file may be able to make the CI runner request a cloud role. An agent that can merge to the default branch may cause an automatic deployment. An agent with read access to secrets and write access to an outbound integration may not need any deploy permission to cause damage. Review the reachable action graph, not the label printed on the first credential.

Keep three categories separate:

• Code write access lets the agent create a branch and propose a change.
• Release authority lets an identity approve, merge, or trigger deployment of that change.
• Runtime authority lets an identity change live infrastructure, data, configuration, or secrets.

Combining all three in one agent identity removes the independent control that makes review useful. A pull request is not an approval boundary if the same agent can approve or bypass it. A deployment log is weak evidence if the agent can change the logging destination. Separate identities and separate policy owners matter more than a polished agent interface.

The distinction also changes the hiring question. A founder may not need outside leadership to let an agent write branches in an isolated repository. The need rises sharply when the proposed credential crosses release or runtime authority and no experienced person owns the whole chain.

Map indirect writes explicitly. Start with every tool the agent can call, then follow what each tool can trigger. A repository write may trigger CI, CI may assume a cloud role, the cloud role may update a service, and the service may run a migration with its own database identity. The agent's effective authority includes that final database write even if it never sees a database password.

Also include control-plane changes that look administrative rather than operational. Editing a branch rule, adding a package source, changing a container base image, muting an alert, or lowering a test threshold can make a later production change possible. If a permission can weaken the gate that protects another permission, treat it as production authority.

Hire for an accountability gap, not for reassurance

Hire outside leadership when the company lacks accountable judgment, not when the board wants someone impressive to bless a predetermined launch. A fractional CTO, security leader, or experienced platform operator should have authority to delay access, narrow scope, and stop production use. If the founder will override every uncomfortable recommendation, the engagement creates paperwork rather than control.

Five conditions justify bringing that person in before production access:

1. No current leader can describe the worst credible action the agent can perform with its exact credentials.
2. The engineer building the agent also approves its production actions and owns the audit system.
3. The company has no tested rollback for schema, data, identity, or infrastructure changes.
4. An incident would produce a debate about who can revoke access, pause deployments, or speak to customers.
5. Customer contracts, regulated data, or uptime commitments make an improvised response unusually expensive.

This is a decision test, not a headcount rule. A four-person company with a disciplined platform engineer may be ready. A forty-person company with shared administrator tokens and informal approvals is not. Seniority labels do not close the gap. Named authority, technical competence, and time to inspect the implementation do.

Outside leadership is also the wrong purchase when the missing work is purely mechanical. If the policy is already approved and the team only needs to configure an environment rule or export logs, hire an implementer. Leadership becomes necessary when reasonable engineers disagree about acceptable blast radius, evidence, business exposure, or the point at which autonomy should stop.

Set a short, concrete mandate. The outside leader should deliver an access map, an approval matrix, an evidence specification, rollback ownership, an incident command card, and a recommendation with explicit conditions. Do not ask for a general "AI strategy." That phrase lets everyone avoid the production decision.

Make the recommendation expire. Agent tools, models, workflows, and team ownership change quickly enough that a one-time approval becomes stale. The leader should name the assumptions behind the decision and the events that force a new review. A new tool connector, a broader repository, an automatic deployment, or a change in on-call coverage can invalidate yesterday's answer.

Check incentives before choosing the adviser. The person selling an agent rollout should not be the only person judging whether the rollout is safe. They can supply evidence and implement controls, but the founder needs a reviewer whose fee and authority do not depend on approving broader access. Independence matters because a careful "not yet" often creates more work than a quick approval.

Credential scope must match one job and one session

An agent should receive a dedicated workload identity with the smallest resource scope, action scope, environment scope, and lifetime that completes one approved job. Never hand it a developer's session, a shared administrator token, or a secret copied from a password manager. Those shortcuts destroy attribution and make revocation harder during an incident.

AWS Security Best Practices in IAM recommends temporary credentials for workloads and least privilege policies. That advice predates coding agents, but it fits them well. The point is not that temporary credentials make a mistaken action harmless. They limit how long a stolen or retained credential remains useful, and a dedicated role gives responders one place to cut access.

Scope has four independent dimensions:

• Resources: name the service, repository, database, queue, or namespace the job may change.
• Actions: allow the required verbs and deny identity, audit, backup, and policy administration.
• Conditions: bind access to the approved environment, workflow, source identity, and session context.
• Time: issue credentials after approval and expire them shortly after the job should finish.

An allow list with service:* is not narrow because it names one service. Wildcard verbs often include deletion, policy mutation, tagging that affects automation, or creation of a new path around your intended restriction. Test the effective permissions, including inherited roles and resource policies, from the agent's identity. Do not infer them from the policy you meant to attach.

Use an access contract that a founder, approver, and incident commander can read. The syntax will differ by provider, but the required facts should look like this:

principal: coding-agent-prod
job: deploy-payments-api
session_ttl_minutes: 30
allow:
  resources:
    - service/payments-api
  actions:
    - release.create
    - release.status.read
deny:
  actions:
    - identity.*
    - audit.*
    - secret.read
    - database.write
approval:
  required_before:
    - release.create
rollback_principal: human-on-call

This contract prevents a common failure: a deployment task silently expanding into credential, logging, or data administration. Enforce the deny rules in the downstream systems, not only in the agent prompt. OWASP's LLM06 guidance on excessive agency makes the same point: reduce extension permissions, run actions in the user's authorization context, and require human approval for high-impact actions. A prompt that says "do not touch production data" is an instruction, not a boundary.

Ask one awkward question before approval: if an attacker controls every token the agent reads from its repository, issue tracker, and tool output, can that attacker cause a production write outside this contract? If the answer is unknown, production access is premature.

Test denials as seriously as allowed actions. Have the session attempt to read an unrelated secret, modify its role, change the audit sink, target a second service, and continue after its expiry. A policy test should fail closed and leave an event for every denied request. An error shown only in the agent transcript does not prove that the downstream system enforced the boundary.

Credential delivery matters too. Issue the role to the workload only after the gate passes, and avoid placing it in a general shell environment that every subprocess inherits. If the tool runner supports per-tool credentials, give the deployment tool the production role while the repository and browsing tools keep separate identities. One session can use several narrow credentials without turning them into one shared pool.

Approval must sit outside the agent's control

A human approval is useful only when it reveals the proposed action, comes from an independent identity, and occurs at the last practical point before the effect. Approving a broad plan at the beginning of a thirty-minute agent run does not authorize every command the agent invents later. Approving a pull request does not automatically authorize a destructive migration bundled into the deployment.

Define approval by effect. Routine, reversible releases can use one operational approver. Changes to identity, network exposure, data retention, backups, billing logic, or destructive migrations should require an owner who understands that domain. Some actions should remain unavailable to the agent even with approval, especially changing its own permissions, disabling evidence collection, or taking over the emergency access path.

The approval request needs enough detail for a person to make a decision:

• The exact commit, artifact digest, migration, or infrastructure plan that will run.
• The resources and environment that will change.
• Test results and policy checks tied to that same artifact.
• Expected customer effect, rollback method, and any irreversible step.
• The agent session, requesting human, and credential lifetime.

The artifact must stay immutable after approval. If the agent can modify the branch, image tag, plan file, or migration after the person approves it, the control is theater. Bind the approval to a commit hash or content digest and reject a mismatch at execution.

GitHub's environment documentation offers a useful implementation detail: a job can wait for a required reviewer, environment secrets can remain unavailable until approval, and teams can prevent the person who initiated a deployment from approving it. The general lesson applies outside GitHub. Put the gate in the deployment system that holds the credential. An approval button inside the agent application is weaker if the same application can release the action.

Approval fatigue appears quickly when every harmless read or retry needs a click. Do not solve that by approving longer autonomous runs. Split work into risk classes. Let the agent inspect, test, and prepare changes without interruption in a sandbox. Reserve human attention for the small set of effects that cross a production boundary. If approvers routinely click without reading, the design has already failed.

Design rejection as a normal path. The approver should be able to deny the action, state why, and send the agent back to preparation without exposing production credentials. A rejected request must not be resubmitted unchanged until a different person clicks it. That behavior turns approval into a race and pressures the on-call engineer to clear a queue.

Emergency bypasses need stricter ownership than normal approval. If a human can bypass the gate during an outage, log the identity, reason, exact artifact, and duration, then require review after recovery. Do not let the agent request or activate the bypass. A hidden administrator button that skips every protection will become the real deployment path when the formal path feels slow.

Audit logs must answer an incident, not decorate a dashboard

An audit trail must let a responder reconstruct intent, authority, action, and effect without asking the agent to explain itself. The agent's final summary is not evidence. It may omit failed tool calls, intermediate changes, rejected actions, or input that altered its plan.

Record at least the initiating human, agent and model version, session identifier, source request, retrieved context references, proposed plan, tool call arguments, tool results, file diffs, policy decisions, approval identity, issued workload identity, artifact digest, deployment result, and rollback result. Use timestamps from trusted systems. Mark secrets at collection time so the log stores a reference or hash instead of credential material.

The event should have a stable machine-readable shape. A practical minimum looks like this:

{"event_id":"evt_01","session_id":"agt_42","actor":"coding-agent-prod","requested_by":"user_17","action":"release.create","resource":"service/payments-api","artifact_digest":"sha256:...","decision":"allowed","policy_version":"prod-agent-v3","approved_by":"user_09","credential_id":"role-session-...","result":"started","recorded_at":"..."}

Generate this event at the policy or deployment boundary. The agent can attach its reasoning as supporting context, but it should not be the only producer of the record. Send copies to storage the agent cannot modify, set retention according to incident and contractual needs, and make retrieval part of an exercise. A log nobody can query under pressure is an expensive text archive.

GitHub describes its organization audit log in plain operational terms: who performed an action, what the action was, and when it happened. Coding-agent evidence needs those basics plus the requesting human, approved artifact, policy decision, credential, and result because one automated session can act through several systems. Correlation identifiers should follow the request across the agent, repository, CI system, cloud control plane, and application deployment.

Test the trail with a question, not a checkbox. Pick one production change and ask a person who did not run it to identify who requested it, exactly what was approved, every production write, which identity performed each write, and whether the deployed artifact matches the reviewed artifact. If the answer requires joining timestamps by eye or trusting a chat transcript, improve the trail before expanding access.

Separate audit evidence from diagnostic output. Application logs explain what the software did; agent traces explain how the model arrived at a request; control-plane audit events show which authenticated action the platform accepted. You may need all three during an incident, but none substitutes for the others. Teams often keep verbose model traces and then discover that they cannot prove which cloud identity changed a resource.

Decide what not to record. Prompts and tool results can contain customer data, source code, tokens, or private incident notes. Apply access control and retention to agent traces, redact secrets before storage, and record when redaction occurred. An audit system that creates a second uncontrolled copy of every sensitive input increases exposure while pretending to reduce it.

Rollback authority must be independent and tested

A rollback plan is credible when a named human can execute it with credentials the agent cannot block, using a procedure tested against the same class of change. "Revert the commit" covers only source changes. It does not restore deleted data, reverse a lossy migration, recover a rotated secret, undo an external side effect, or fix an infrastructure replacement that destroyed state.

Classify every proposed production action as reversible, compensatable, or irreversible. Reversible actions have a known operation that restores the prior state. Compensatable actions need a new action, such as refunding a charge or rebuilding an index, and may leave customer effects behind. Irreversible actions, including some deletions and data disclosures, cannot be made safe by a rollback button. Keep those outside autonomous execution.

The rollback operator needs a separate identity, an emergency route that does not depend on the failed deployment path, and access to known good artifacts and backups. The agent must not control that identity or the repository that defines its permissions. If the production agent can delete the backup, change the rollback workflow, and modify the evidence store, you have one large failure domain.

Run a rollback rehearsal before granting persistent access. Deploy a harmless version through the proposed agent path, revoke the agent session, and have the assigned operator restore the previous version from the emergency route. Measure whether the operator can locate the right artifact and determine when recovery is complete. The goal is proof that the route works, not a fast-looking number.

Database changes deserve separate treatment. Favor expand-and-contract migrations: add compatible structures, deploy code that handles both states, move data, verify it, and only later remove the old structure. The delay feels inefficient, which is why teams skip it. It buys a period in which application rollback remains possible. An agent should not collapse those phases into one clever migration because the test environment passed.

Define recovery completion before the incident. A successful rollback means more than a deployment tool reporting green. Check application health, error rate, queue depth, data consistency, and the specific customer operation the change affected. For a compensating action, track which effects were corrected and which require support or finance work. The incident commander needs that distinction when deciding whether to reopen deployment.

Backups deserve a restore test, not a screenshot showing that a scheduled job ran. The rollback owner should know the restore point, expected data loss window, credentials, target environment, and verification query. If restoring production data takes hours, that fact belongs in the access decision. It may make an otherwise routine agent action too risky for autonomous execution.

Incident command starts before the first agent session

One person must have incident command authority for agent-caused production events before the first credential is issued. That person decides when to stop the agent, revoke roles, freeze deployment, activate rollback, preserve evidence, and escalate business communication. The role can rotate, but it cannot be discovered in a group chat after customers report errors.

Write a compact command card with names or on-call roles for five decisions: incident commander, access revocation, technical recovery, evidence preservation, and customer or legal communication. Small companies may assign several decisions to one person. The separation that matters most is between the automated actor and the human who can contain it.

Containment should have an explicit order. Stop new agent sessions, deny new role assumptions, revoke or disable active sessions where the platform permits it, pause the deployment path, preserve logs, assess customer effect, and then choose rollback or forward repair. Do not begin by deleting the agent's workspace. That may destroy the context needed to understand what happened.

AWS documentation notes a detail teams often miss: temporary role credentials remain valid until expiry unless you take steps to revoke sessions or change effective permissions. Short lifetime helps, but it is not an incident switch by itself. Test the exact revocation mechanism for your identity provider and cloud, including propagation delay and already running jobs.

The incident commander also needs a threshold for declaring an event. An unexplained production write, an artifact mismatch, a policy bypass attempt, missing audit events, use of an unexpected credential, or loss of rollback readiness should stop the rollout even if customers have not noticed an error. Waiting for visible damage rewards gaps in monitoring.

After containment, compare the intended contract with the actual action graph. Fix the system boundary before rewriting the prompt. Prompt changes may reduce recurrence, but credentials, policy gates, and deployment rules decide whether a recurrence reaches production.

Stage access through evidence-based gates

Do not jump from repository assistance to open production access. Increase authority only after the current stage produces evidence that the next one is safe. A useful progression is branch creation in an isolated repository, change proposals in the real repository, deployment to an isolated environment, production read access, human-approved production release, and only then narrowly defined autonomous release for a low-impact service.

Each promotion needs exit criteria. Before production read access, prove that sensitive fields are filtered and retrieved context cannot smuggle a write path. Before human-approved release, prove artifact binding, independent approval, complete event correlation, session expiry, and emergency revocation. Before any autonomous release, show repeated clean runs for the same action class and keep identity, data, and policy changes gated.

Use a decision record for every expansion:

• State the new action, exact resources, business reason, and expected frequency.
• Name the failure modes that become possible at this stage.
• Attach the permission test, audit replay, rollback rehearsal, and incident owner.
• Set an expiry date for the exception or access grant.
• Record who accepted the remaining risk.

This process exposes a popular but wrong recommendation: give the agent broad access briefly, watch what it does, and narrow permissions from observed use. It is attractive because access discovery is tedious. It is wrong in production because the observation period is also a period of broad authority, and normal runs do not reveal what manipulated input or a failed dependency will request. Discover actions in a sandbox, then allow a reviewed set in production.

Treat autonomy as per-action trust rather than a permanent status attached to the agent. The same system may safely restart one stateless service while requiring approval for a schema migration and forbidding identity changes. This keeps the control model understandable as tools and prompts change.

Set a review trigger for any change to the model, system prompt, tools, retrieved data sources, deployment workflow, permission policy, or production architecture. A successful assessment does not transfer automatically to a materially different system. Expanding context can expand effective authority even when the credential stays the same.

Outside leadership should leave the company able to say no

The best outside leader leaves behind a control system the internal team can operate and challenge. The work is finished when the founder can see the reachable actions, the approver can verify an immutable artifact, the responder can query the evidence, and the incident commander can revoke and recover without the consultant present.

For teams that need an independent assessment, the Team & AI Audit at oleg.is is designed to identify engineering savings and the operating controls needed for an AI team transformation. That can clarify ownership and priorities, but no adviser should become a permanent approval bottleneck or an excuse for the founder to ignore residual risk.

Do not grant production write access merely because a coding agent has performed well in development. Grant one bounded action because the company can constrain it, approve it, observe it, reverse or compensate for it, and command the incident if it fails. If nobody inside can prove those conditions, hire the outside leader before issuing the credential, and give that leader authority to return an unwelcome answer.