AI incident ownership stays with a human commander

An AI agent can write the patch, run the tests, open the pull request, and trigger the deployment. It still cannot own the production incident. AI incident ownership must stay with one named human incident commander who has the authority to stop work, choose a mitigation, assign responders, and accept the consequences of those choices.

That rule is not ceremonial. When an automated change breaks production, teams lose time arguing about whether the prompt author, reviewer, service owner, platform engineer, or agent "caused" it. Causation matters later. During the incident, one person must control the response while separate people and agents investigate, roll back, communicate, and preserve evidence.

The agent belongs inside the response structure as a fast but untrusted operator. Give it bounded tasks, observable tools, and an explicit human approver. Never give it command, because command requires judgment about business harm, incomplete evidence, and who may take which risk.

Ownership does not follow authorship

The accountable owner is the person authorized to make incident decisions, not whoever produced the faulty lines. Software has always separated authorship from operational responsibility. A library author does not command every outage involving the library, and a junior engineer who typed a bad migration should not automatically direct a company-wide recovery.

AI makes this distinction harder to ignore because the apparent author is not a legal or organizational actor. The agent cannot be paged, disciplined, trained through lived experience, or held to a commitment. It cannot decide that losing five minutes of accepted orders is preferable to exposing customer records. A person must carry that authority.

Four labels help prevent the usual argument:

• The change author produced the patch. That may be a human-agent pair.
• The approver accepted the change for deployment.
• The operator executed a production action during the response.
• The incident commander owns decisions and coordination until a documented handoff.

Those labels can point to different people. The engineer who prompted the agent should join the investigation because they know the intent and the session context. The service owner should supply system knowledge. Neither automatically becomes commander. Choose the commander from the on-call or leadership rota according to impact, experience, and availability.

Do not use a RACI matrix as a live command system. RACI helps design responsibilities before an incident, but five people marked "accountable" means nobody can settle a contested rollback. During an incident, use one name. Afterward, the wider responsibility map can explain which process owners must repair review rules, tests, access, or training.

The incident commander controls the response, not the terminal

The incident commander's job is to maintain a trustworthy picture of the incident and direct the response. They should usually avoid typing mitigation commands. A commander buried in a shell stops noticing that two responders are changing the same database, the support team is repeating stale information, or the agent has expanded its search beyond the affected service.

Google's Site Reliability Engineering guidance separates Incident Commander, Operations Lead, and Communications Lead. It also says the commander owns every role that has not yet been delegated. That last point matters for a five-person startup: you do not need three people waiting in labeled boxes, but you do need to know who owns an unassigned duty.

The commander should record five facts near the top of the incident channel or document:

• current customer impact and when it began;
• the named operations, investigation, and communications owners;
• the mitigation now in progress;
• the next decision time;
• which production write paths are open to humans or agents.

The role starts when someone declares the incident, not when the cause is proven. If two alerts, a support report, and a recent agent-written deployment point in different directions, command is already useful. Early declaration creates a place to compare evidence and prevents an eager responder from treating a plausible theory as a verdict.

A handoff must be explicit. The outgoing commander states the current impact, active hypotheses, actions in flight, frozen actions, and the next update deadline. The incoming commander accepts in the same channel. An unspoken handoff during a video call leaves every participant with a different answer to "who decided that?"

Split the work into four controlled lanes

Assign investigation, mitigation, communication, and follow-up separately, even when one person fills two lanes. This prevents the investigator's strongest theory from becoming an unauthorized production change and stops the person restoring service from composing customer prose between commands.

Investigation

The investigation lead builds and ranks hypotheses. They compare the agent-written diff with telemetry, earlier deployments, feature flags, dependency changes, and user reports. An agent can search logs, correlate timestamps, summarize a diff, or generate queries. It must return evidence and uncertainty, not a confident root-cause sentence.

Ask the agent for falsifiable output: "List the three code paths changed by commit X that can alter checkout latency. For each, give the log field or metric that would disprove involvement." That request produces work a human can inspect. "Find the root cause" invites the model to collapse ambiguity too early.

Mitigation and rollback

The operations lead is the only lane allowed to alter production during the incident. They can delegate a specific command to a human or agent, but the lane owns sequencing and collision avoidance. If the team permits an agent to act, the operations lead approves the exact target, action, and rollback boundary before execution.

Prefer the smallest action that reduces customer harm: disable the new path, route traffic away, roll back the deployment, pause a queue consumer, or apply a narrow data correction. Root cause can wait. A broad refactor generated during the outage is not mitigation, even when its explanation sounds convincing.

Communication

The communications owner publishes verified impact, action, and timing. They do not speculate about the agent, the engineer, or the cause. An agent may draft updates from the incident record, but a human checks every statement and releases it.

Follow-up

The follow-up owner captures deferred work as it appears: repair a test, reduce a token scope, add a deployment gate, preserve a session transcript, or schedule a review. They do not interrupt mitigation to design the permanent fix. This lane prevents useful findings from disappearing when the incident channel goes quiet.

Small teams can combine investigation with follow-up and let the commander handle communication. Keep mitigation separate from command whenever possible. The aim is not bureaucracy. It is to ensure that each production action has one operator and each public statement has one human editor.

Agents may execute tasks but cannot receive authority

An agent gets a capability, a scope, a deadline, and a reporting contract. It does not get a role whose meaning depends on organizational accountability. You can delegate "compare these two manifests" or "run this read-only query." You cannot delegate "decide whether the revenue loss justifies a failover."

Use an action envelope for every agent task during an incident:

task_id: INC-482-investigate-03
requested_by: maya
approved_by: leon
mode: read_only
systems:
  - checkout-api
allowed_tools:
  - logs.query
  - git.diff
expires_at: 2026-07-27T15:30:00Z
output:
  channel: incident-482
  include:
    - commands_run
    - evidence
    - uncertainty
stop_conditions:
  - request_requires_production_write
  - query_scope_exceeds_checkout-api
  - credentials_or_personal_data_appear

This artifact prevents a common failure: the agent begins with a log query, notices a suspicious deployment, opens the deployment tool, and proposes or performs a rollback under the same broad credential. The scope boundary forces a new human decision when the task changes class.

For a write action, change mode, name the exact resource, include the approved command or API operation, state the expected effect, and define a timeout. Require a fresh approval. Do not let approval of an investigation silently authorize its suggested remediation.

GitHub's deployment documentation makes a useful distinction between initiating and approving a deployment. Protected environments can require reviewers and can prevent self-approval by the initiator. The same separation should apply when an agent creates the change: neither the agent nor the person running the agent session should be the sole production approver for a high-impact service.

Some teams appoint the agent as "incident copilot" and assume the friendly title limits it. Titles do not limit credentials. Tool permissions, resource scopes, approval gates, rate limits, and expiration do. If the agent can write to every cluster because the prompt says "be careful," the control exists only in prose.

Approval binds a human to one exact action

An approval is useful only when it proves which person accepted which action against which production target. A thumbs-up in a busy channel does not do that. Neither does a generic "allow for this session" control that remains valid after the agent changes its command, resource, or reason.

Bind the approval to an immutable request. The request should include the incident ID, agent session, tool, operation, normalized arguments, target environment, expected result, expiration, and evidence the approver reviewed. Store the approval separately from the agent transcript so the agent cannot edit the record it relies on.

This creates two identities in every write: the agent or human who executes, and the person who authorizes. The executor answers "what process touched production?" The approver answers "who accepted this risk?" The incident commander may be the approver on a small team, but delegation to the operations lead is better when the commander needs to watch broader impact.

Approval does not transfer accountability to the person who clicked. The commander still owns coordination and the operations lead still owns the production action lane. The approval record identifies a decision inside that structure. Without this distinction, teams either blame the nearest reviewer for the whole incident or treat approval as meaningless group consent.

Reject approvals that outlive their context. A rollback approved while error rates are climbing may be wrong ten minutes later if a failover has already moved traffic or a database restore has begun. Keep expiry short and invalidate pending approvals when the commander changes the mitigation plan. The operations runner should also refuse a request when the observed production revision differs from the revision named in the approval.

Many agent interfaces ask a human to approve a tool category, such as shell or cloud access, rather than the final operation. That interaction improves convenience, not control. It is acceptable for low-risk development work inside an isolated environment. It is a poor production gate because get deployment status and delete deployment can travel through the same tool.

For production, place enforcement outside the model session. A policy proxy, deployment system, cloud role broker, or purpose-built runner should verify the signed request, resource scope, expiry, and current incident state. The agent can ask for permission, but it cannot grant permission to itself or choose a more powerful credential.

Emergency access needs the same discipline. A break-glass path should name the human opening it, page or notify another owner, expire automatically, and produce a complete activity record. Do not share one emergency token in a password manager and call that accountability. Shared credentials erase the person just when the incident requires a clear decision trail.

Revocation must be quick and tested. The commander should be able to end the agent session, revoke its short-lived token, stop queued tool calls, and freeze deployment automation without disabling every human responder. If the only stop mechanism is deleting a broad integration while production is failing, the access design has coupled automation and recovery in the worst possible way.

Test revocation with an action already in flight. Some systems check authorization only when a job starts, so revoking a token does not stop a queued or long-running operation. The incident plan must say whether the team cancels the job, fences the target, changes a deployment lock, or rotates the underlying credential. A revoked credential that leaves an accepted write running is only half a stop control.

The hardest approval is a proposed data repair. An agent may generate an SQL statement that looks narrow and passes a dry run. The approver still needs a count of affected rows, tenant and time boundaries, transaction behavior, backup or compensation plan, and a second human for destructive changes. During an outage, the desire to clear visible errors makes speculative repair unusually tempting.

Record a refusal too. A rejected action explains why the team changed course and prevents another responder from submitting the same operation with less context. Refusals also reveal recurring agent suggestions that need better tool descriptions, prompts, or guardrails after the incident.

Evidence must outlive the agent session

The incident record must show what the agent saw, what it was asked, which tools it called, what changed, and who approved the change. Saving only the final chat answer is inadequate. That answer may omit a failed command, a truncated log result, a retrieved instruction, or an earlier hypothesis that shaped later actions.

NIST's AI Risk Management Framework Playbook recommends histories and audit logs that let people review possible sources of error or vulnerability. It also calls for documenting human oversight, overrides, policy exceptions, escalations, and go or no-go decisions. This guidance is practical incident hygiene, not an abstract AI principle.

Capture these records under the incident ID:

• prompt and relevant conversation history, with secrets redacted;
• model and tool versions, agent configuration, and permission set;
• every tool request and response, including failures;
• approval identity, timestamp, scope, and reason;
• commit, artifact, deployment, flag, and infrastructure identifiers.

Do not depend on the agent vendor's chat history as the system of record. Retention may differ by plan or workspace, tool calls may live elsewhere, and responders may lose access after a credential is rotated. Send event records to infrastructure you control.

A compact event format makes later reconstruction possible:

{"incident":"INC-482","time":"2026-07-27T14:11:08Z","actor_type":"agent","actor_id":"deploy-assistant","session":"sess-91f","action":"logs.query","target":"checkout-api","mode":"read","request_hash":"sha256:...","result":"success","evidence_ref":"evt-7721","approved_by":null}
{"incident":"INC-482","time":"2026-07-27T14:18:42Z","actor_type":"human","actor_id":"leon","action":"approve","target":"checkout-api/prod","mode":"rollback","request_hash":"sha256:...","result":"granted","evidence_ref":"evt-7754","approved_by":"leon"}

The hash links an approval to an exact request without placing sensitive payloads in a broad incident channel. The evidence reference points to access-controlled command output. If the requested command changes after approval, its hash changes and the runner must reject it.

Logs need a clock, an identity, and an immutable destination. A transcript copied manually after recovery may still help, but it cannot prove ordering or completeness. Test the capture path during drills by asking a reviewer to reconstruct one agent action without opening the original chat interface.

Rollback must exist before an agent receives write access

Do not grant an agent a production write path unless the team has tested a bounded reversal or containment action. "Git revert" is not a rollback plan when a deployment also ran a database migration, emitted irreversible events, or changed an external API contract.

Classify the change before deployment:

• Reversible changes can be restored automatically within a known time.
• Containable changes can be disabled or isolated, though their effects may remain.
• Irreversible changes require a recovery procedure, such as restoring data or compensating events.
• Unknown changes do not receive unattended production execution.

The popular recommendation to "keep a human in the loop" is too vague. A tired approver looking at a large generated diff seconds before release is physically present but operationally useless. The loop needs a decision, evidence, and enough time to refuse. Define which risk level requires review, who may approve, and what the reviewer must see.

For an agent-generated database migration, the reviewer should see the schema diff, lock and duration estimates from a production-like test, compatibility with the currently deployed application, backup or restore evidence, and the containment plan. If the migration drops or rewrites data, a syntactically valid down migration may give false comfort. The commander needs the truthful recovery time and loss boundary.

Run a rollback drill with the same permissions and automation used in production. The exercise should produce observable output: deployment revision before and after, health checks, error rates, and confirmation that the agent's token could touch only the named resource. A runbook nobody has executed is a hypothesis.

When an incident begins, freeze unrelated agent writes. Automation can keep collecting evidence, but parallel autonomous changes corrupt the timeline and widen the search space. The commander can reopen a path deliberately when it supports the chosen mitigation.

Customer communication stays under human control

A human owns every external incident update because communication commits the company to facts, expectations, and sometimes legal positions. An agent can draft from approved incident fields, translate an approved update, or compare a draft with the current status. It cannot decide what customers should be told.

The communications owner should publish three things: confirmed impact, the action underway, and the time of the next update. Avoid naming the AI agent in the first message unless its involvement is itself relevant to customer safety or a reporting duty. "An AI change caused this" is usually an unverified causal claim and tells customers less than which service failed and what they should do.

Use a small source block that the commander approves:

customer_impact: Some checkout requests return errors.
started_at: 2026-07-27T13:52:00Z
current_action: Rolling back the latest checkout-api deployment.
customer_action: Retry failed requests after the next update.
next_update_at: 2026-07-27T14:40:00Z
approved_by: leon

The agent may turn that into prose without introducing a root cause, recovery promise, percentage, or scope not present in the block. The communications owner compares the draft with the source fields. This is faster than asking the agent to summarize an entire noisy incident channel, and it reduces the chance that speculation escapes.

Internal updates can include confidence levels and competing hypotheses. Executive updates should separate current business impact from technical detail. Support needs an approved customer response and a route for new evidence. The same facts feed each audience, but the level of detail differs.

If privacy, security, safety, contractual notice, or regulated data may be involved, bring the appropriate legal or security owner into the decision early. The agent should not interpret notification duties during the outage. Put jurisdiction and contract checks in the incident plan before anyone needs them.

Reconstruct the failure without scapegoating the model

The review must trace how the change reached production and how the response behaved. Blaming "AI hallucination" ends the analysis at the least useful point. Models produce wrong output. The engineering question is why that output passed the controls and gained the permissions needed to create customer harm.

Consider a plausible chain. An engineer asks an agent to reduce database load in a checkout service. The agent replaces a per-request lookup with a shared cache and writes tests around normal responses. The pull request is large, the reviewer focuses on query reduction, and the deployment begins automatically after merge.

Under concurrent traffic, the cache key omits tenant identity. Users receive errors when an authorization check catches the mismatch. The agent sees those errors, correlates them with the deployment, and recommends clearing the cache. A responder runs the suggestion, which briefly hides the symptom. The cache fills again, and impact returns.

This failure has several owners without splitting command. The incident commander owned response decisions. The operations lead owned the cache clear and rollback execution. The service owner owns the missing isolation invariant. The engineering leader owns the review and deployment controls that let a generated concurrency change pass with weak tests. The agent owns nothing, but its prompt, output, permissions, and tool calls remain evidence.

The review should ask:

1. Which invariant did the change violate, and where should that invariant have been tested?
2. Which human decision admitted the risk, and what evidence did that person have?
3. Which permission or automation turned an accepted change into production impact?
4. Why did the first mitigation fail, and what signal showed the failure?
5. Which control will now prevent or contain the same class of failure?

Do not make "review AI code more carefully" the corrective action. It cannot be measured and it fades under schedule pressure. Add tenant-isolation tests, require a specialist review for shared caching changes, canary the release, gate production, or restrict the agent's deployment scope. Name an owner and a due date for each action.

Also review the response, not only the trigger. If responders ran overlapping commands, if the communications draft leaked an unverified cause, or if agent logs vanished with the session, those are separate failures. A fast rollback does not excuse an unauditable path to it.

Accountability is designed before the next deployment

Teams should encode incident ownership in the same systems that grant agents access. A policy in a handbook will lose to a token with broad privileges and a pipeline that deploys on merge. Make the safe path the easy path: short-lived credentials, protected production environments, recorded approvals, one operations lane, and automatic evidence capture.

Set a simple policy for each production service:

service: checkout-api
human_owner: payments-oncall
incident_commander_rota: company-incident-command
agent_change_risk:
  read_only: autonomous
  reversible_write: human_approval
  data_or_identity_change: two_person_approval
  unknown: denied
incident_mode:
  default_agent_access: read_only
  production_writes: operations_lead_only
  external_updates: communications_owner_only

The names should resolve to current people and schedules. Test that resolution outside office hours. If payments-oncall points to an empty rota or the commander cannot revoke the agent token, the policy is decorative.

Exercise one agent-triggered incident every quarter or after a major change to permissions, tools, or deployment flow. Include an ambiguous symptom, a bad agent hypothesis, a request for production write access, and a command handoff. Measure whether the team can name the commander, stop concurrent writes, retrieve the evidence, and issue a verified update. The drill should expose control gaps while the stakes are low.

At oleg.is, a Team & AI Audit can map these ownership and access gaps alongside engineering cost, then assign the changes to a practical operating model. The audit does not replace incident command; it helps founders establish it before automation raises the speed and blast radius of a mistake.

The accountable person should never be inferred from the Git history after customers are already affected. Put one human name at the top of the incident, constrain every agent action beneath that authority, and preserve enough evidence to challenge the first explanation. Faster code generation demands faster clarity about who can say stop.