# How one person can handle SOC 2 agent deployment

> Test SOC 2 agent deployment across author, reviewer, and deployer roles, with compensating controls and evidence an auditor can verify.

A one person engineering team can supervise an AI coding agent, approve a change, and still operate a defensible SOC 2 change control. The control passes only when the workflow prevents that person from quietly writing, approving, deploying, and concealing an arbitrary production change. Calling the agent a second reviewer does not solve that problem.

The useful design separates powers, even when it cannot separate payroll. The agent may prepare a change, the human may review and authorize it, and an automated release identity may deploy the exact approved artifact. Protected branches, required checks, restricted production access, and logs outside the operator's control then compensate for the missing second engineer. Whether an auditor accepts that design depends on the stated control, the risks it addresses, and evidence that it operated throughout the review period.

## SOC 2 tests the control, not your org chart

SOC 2 does not contain a rule that every software release needs three employees. It asks management to describe controls that meet the applicable Trust Services Criteria, then asks an independent CPA firm to evaluate those controls. Headcount matters because it affects risk and control design, but headcount is not itself the criterion.

Two parts of the AICPA Trust Services Criteria frame this question. Under CC5.1, one point of focus says management should segregate incompatible duties and, when segregation is not practical, select and develop alternative control activities. That second clause matters to a small company. It permits a compensating design, but it does not permit management to ignore the conflict.

CC8.1 addresses change management. Its wording covers authorizing, designing, developing or acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures. The criterion names lifecycle activities. It does not say that a different employee must perform each verb. Your own policy may impose that stricter requirement, however, and an auditor will test you against the control description you chose.

NIST Special Publication 800-53, control AC-5, gives a sharper definition of separation of duties: identify the duties that require separation and define access authorizations that support it. NIST also says the purpose is to reduce the risk of abuse by someone with authorized privileges. SOC 2 is not a NIST certification, but the language exposes the right design question. Can one principal misuse authorized access without another person or an enforced system control stopping or revealing it?

This is also why “compliant” is too blunt a label for a release workflow. A SOC 2 Type I examination evaluates control design and implementation at a specified date. A Type II examination also tests operating effectiveness over a period. A beautiful branch rule created the week before fieldwork may support design. It will not prove that every sampled production release followed the rule for the preceding months.

## Author, reviewer, and deployer are powers

Treat author, reviewer, and deployer as powers that can conflict, not job titles to paste onto accounts. For each production change, trace who or what can exercise each power and who can bypass the boundary.

The author power determines the proposed change. An AI agent may create the commit under a bot identity, but the person who supplied the task, repository context, credentials, and acceptance criteria remains accountable for using it. A bot name in Git history proves attribution to a service account. It does not prove independent judgment.

The reviewer power decides whether the proposed change is fit to merge or release. A human who reads the diff, challenges assumptions, checks security effects, and records an approval is performing a real review. If that same human also requested the behavior, the review is a self review. It can still catch an agent's mistake, but it does less to deter an intentional or conveniently overlooked change.

The deployer power can alter production. A continuous integration service can hold that power through a narrow production identity. The service becomes a useful control boundary when it will deploy only an immutable artifact from an approved commit after required checks pass. If the human retains an administrator credential that can deploy any local build, the automated pipeline is merely the usual path, not an enforced control.

Run this role test against a single change:

1. Identify the human who requested and accepted the behavior, the account that committed it, the account that approved it, and the identity that deployed it.
2. Check whether the approver can change the commit after approval without forcing a new approval and new tests.
3. Check whether the human can bypass branch protection, replace the release artifact, use a direct production shell, or rewrite the relevant logs.
4. Check whether an outside reviewer can reconstruct the sequence from timestamps, commit digests, build records, approval records, and deployment events.
5. Record every bypass as a conflicting power, even if the operator promises not to use it.

That last point catches many weak controls. An auditor does not have to accuse the founder of bad intent. A control that depends entirely on the same person's restraint neither prevents a mistake nor produces independent evidence that the restraint held.

## An AI agent cannot approve its own work independently

An AI coding agent is not a second person for segregation of duties. It is a process acting with authority that a human or organization granted. Giving one agent an “author” prompt and another an “auditor” prompt may improve defect detection, but both can share the same model errors, repository context, orchestration account, and administrator.

This distinction separates quality review from authorization. An agent can inspect a diff for unsafe input handling, compare migrations with a policy, run tests, and flag a dependency change. Those actions create useful evidence. Authorization means an accountable party accepts the residual risk and permits the change to proceed. The model cannot accept corporate responsibility, and changing its system prompt does not create organizational independence.

Multiple agents still help when the workflow treats their results as checks rather than signatures. For example, one agent writes a patch, a second evaluates it against a fixed review rubric, static analysis runs without either agent controlling its configuration, and the human receives all failures before approval. The review record should identify the model run and inputs that matter, but the human approval must remain explicit.

Do not let the agent hold the production credential. An agent that can edit code, modify pipeline configuration, approve a run through an API, and invoke production has accumulated every conflicting power behind one automation token. Human supervision becomes observational because the consequential action can finish before the person intervenes.

There is another subtle failure: the agent presents a summary instead of the actual diff. Approving “added validation and tests” is not code review. The approval interface must bind the human decision to a commit digest or artifact digest. If the agent amends the commit afterward, the system must invalidate the approval.

## One person needs enforced compensating controls

A one person release process becomes defensible when alternative controls address the same risks that a second engineer would address: unauthorized changes, accidental defects, hidden bypasses, and weak attribution. The exact set should follow your risk assessment. A marketing copy change does not need the same release treatment as authentication code or a destructive database migration.

At minimum, I would expect the normal path to have these properties:

- The main branch rejects direct pushes and requires recorded approval plus required automated checks.
- The human cannot approve a commit and then alter it without causing the checks and approval to run again.
- The build service creates one identifiable artifact, records its digest, and promotes that artifact unchanged.
- Only the release service has routine production write access; the human uses a separately controlled emergency path.
- Audit and deployment logs go to a location where the operator cannot silently edit or delete the relevant history.

These controls do different jobs. Tests reduce the chance of a defective change. Branch protection prevents an unreviewed commit from becoming the approved source. An artifact digest connects what was reviewed to what ran. Restricted production access blocks an alternate deployment. Externalized logs make bypasses visible. Ten more tests do not compensate for a person who can deploy an unrelated local artifact.

A periodic independent review can strengthen the design without putting a second engineer on every release. A founder, security advisor, or contracted reviewer can sample production deployments, compare them with approved changes, review emergency access, and sign a monthly record. This is a detective control, so it does not stop a bad release. It can make concealment harder and force exceptions into management's risk process.

Write the compensation into the control description. “All code is peer reviewed” is false when the only human reviews agent output. A more accurate description is: “Management reviews and approves production changes; automated controls require successful tests, bind approval to an immutable artifact, restrict routine deployment to the release service, and retain deployment evidence; an independent reviewer examines releases and exceptions monthly.” Your wording should match the system you actually operate, including frequency.

## Policy as code must bind the approved artifact

The highest value automated control is the join between approval and deployment. A reviewer should be able to point to one digest and say: this is the code I reviewed, this is the artifact the trusted builder produced, and this is what the release service deployed.

The following Open Policy Agent policy shows the decision in executable form. It expects a deployment request with the source commit, the approved commit, test state, artifact digests, caller identity, and emergency state. Adapt the field names to your release system.

```rego
package release

default allow := false

allow if {
  input.caller == "ci-production"
  input.source.commit == input.approval.commit
  input.build.artifact_digest == input.deploy.artifact_digest
  input.checks.required == "passed"
  input.approval.actor != input.source.committer
  not input.emergency
}
```

For a literal one person team, the final inequality will often fail because the human controls the request while the agent's service account appears as committer. Do not “fix” that by pretending the bot is independent. Replace that condition only after documenting the conflict and the controls that compensate for it. A one person variant might require a human approval, a bot-authored commit, an untampered build, and a delayed external review:

```rego
allow if {
  input.caller == "ci-production"
  input.source.commit == input.approval.commit
  input.build.artifact_digest == input.deploy.artifact_digest
  input.checks.required == "passed"
  input.approval.actor_type == "human"
  input.source.committer_type == "agent"
  input.evidence_sink == "restricted"
  not input.emergency
}
```

This policy is not automatically sufficient for SOC 2. It makes the design testable. An auditor can submit a changed digest, failed check, wrong caller, or emergency flag and confirm that the decision returns false. The evidence should preserve both the policy version and the input used for each release because an allow result without those details is hard to reproduce.

Keep the agent away from the policy repository or require a separate approval path for policy changes. If the agent can modify the gate in the same pull request as the application change, it can convert a preventive control into decorative code. Apply the same caution to required test definitions, build scripts, and branch rules.

## The evidence must reconstruct every sampled release

Auditors usually start with the control population, not the screenshots you selected. They may ask for all production deployments during the review period, choose samples, and trace each sample through authorization, testing, approval, and implementation. Build your export before fieldwork so it does not depend on manually finding favorable examples.

For each deployment, retain a structured record with these fields:

- Change or pull request identifier, business purpose, risk class, author identity, and creation time.
- Human approver identity, approval time, approved commit digest, and any recorded review comments.
- Required check names, results, completion times, and a reference to retained test output.
- Builder identity, artifact name and digest, deployment identity, target environment, and deployment time.
- Exception status, emergency access events, rollback result, and the independent review record when one is required.

An evidence record should look more like a transaction than a screenshot:

```json
{"change":"CR-1842","risk":"high","commit":"8f2c1a7","author_type":"agent","approved_commit":"8f2c1a7","approver":"user-17","checks":"passed","artifact":"sha256:4b2...91e","deployer":"ci-production","environment":"production","exception":false}
```

The truncated values above illustrate the shape; production evidence should retain complete identifiers and digests. The auditor should be able to join the change system, source repository, build system, identity provider, and production platform on stable identifiers. Timestamps alone are weak join keys because retries and parallel builds create ambiguity.

Also retain evidence about control configuration, not only release events. Useful material includes branch rule exports, repository administrator lists, production role assignments, access review records, policy versions, log retention settings, break glass membership, and screenshots or machine exports showing that the operator cannot alter stored audit events. A screenshot of a passing pipeline proves one run passed. It does not prove the rule could not be bypassed.

For a Type II period, completeness matters as much as detail. Reconcile the deployment population from the production platform against pipeline records. If production reports 412 deployments and the change system contains 409 approved releases, investigate the three unmatched events. Do not exclude rollbacks, configuration changes, feature flag changes, database jobs, or infrastructure changes merely because they did not come from the application repository.

## Emergency access needs a different control

Small teams need a way to recover production when the normal pipeline is broken. Denying that reality produces an undocumented administrator account, which is worse than a controlled exception. Define emergency access as its own workflow with narrow triggers, short duration, strong authentication, immediate logging, and mandatory review.

The operator should request or activate a named emergency role rather than reuse a standing administrator credential. The identity system should record activation, reason, start time, and expiry. Production should record every action under that role. When service is stable, the operator links the emergency change to an incident record, captures the resulting diff, runs the skipped checks, and submits it for independent review within the deadline stated in policy.

The reviewer cannot be the same person who made the emergency change if your compensating control promises independence. For a tiny company, the reviewer might be a fractional CTO, a founder who does not hold production access, or a contracted security practitioner. They need enough technical context to challenge the action; a ceremonial “looks good” from someone who cannot read the change has little control value.

Set a realistic deadline and test it. If policy requires review within one business day, the audit evidence must show that sampled emergency changes met that timing or were recorded as exceptions. Do not write a four hour promise because it sounds strict when nobody is available overnight.

Emergency deployment also exposes whether the routine control is honest. If the sole operator uses the emergency role for ordinary releases because the pipeline is slow, the exception has become the process. Track activation frequency and reasons, and investigate repeated categories. A high count does not automatically fail a criterion, but unexplained routine use contradicts a control that claims restricted emergency access.

## A plausible workflow can still fail the test

Consider a solo founder who asks an agent to add account deletion. The agent edits application code, creates a database migration, updates tests, and opens a change under a bot account. The founder reads the summary, approves the change, and presses deploy. The pipeline reports success. On paper, the record contains an author, an approver, tests, and a deployer.

The control fails on closer inspection. The founder owns the bot token, can push directly to the main branch, and can change required checks. The deploy button accepts a branch name rather than an artifact digest, so the pipeline builds whatever the branch contains at execution time. The founder also has a production shell and can delete the central application logs. None of the named roles limits another role.

A second defect appears during the migration. The agent tested deletion on an empty database but did not test a customer with retained invoices. The founder reviewed the generated summary rather than the migration. The deployment removes a reference that the billing export expects. The pipeline passes because the agent also wrote the incomplete test.

Adding another agent to review the first agent's output may catch the missing fixture, but it does not cure the control conflict. Both runs use the same repository token and editable test suite. The founder can still deploy a different commit and remove evidence. This is the distinction teams routinely blur: a diverse review method may improve software quality, while segregation of duties constrains authority.

The repair is specific. Protect the branch and required checks from the routine operator. Make approval name a commit digest. Build once in a trusted service, record the artifact digest, and deploy only that digest through a production identity. Send deployment and emergency access events to a restricted evidence store. Have an independent person sample sensitive changes and every emergency action on a stated schedule. Now each control addresses a failure that the scenario exposed.

## Approval depth should follow change risk

Requiring identical evidence for every change encourages people to bypass the process. Define a small set of risk classes with objective triggers, then make the release gate apply the matching controls. The classification itself needs protection because an operator who can label an authentication rewrite as low risk can evade the stronger path.

A low risk class might cover text, isolated presentation changes, and reversible configuration with no effect on access, customer data, billing, or availability. A higher class should capture identity and authorization logic, cryptography, data retention, database migrations, infrastructure permissions, audit logging, build policy, and changes that can make recovery difficult. Do not rely on lines changed. A one line permission edit can carry more risk than a large internal refactor.

Let automation propose the class, but make deterministic rules set a floor. A change touching an identity policy directory, migration folder, deployment definition, or control policy should automatically require the higher path. The human may raise the class. Lowering it should require a recorded reason and appear in the independent review population.

For lower risk changes, one human approval plus enforced tests, immutable artifacts, restricted deployment, and retained logs may match the assessed risk. For higher risk changes, require an independent human before release whenever one is available. If the company truly has no qualified second person, add a release delay, stronger test suites controlled outside the change, full session recording for production actions, and prompt review by a contracted practitioner. These alternatives reduce risk, but management should acknowledge that they do not provide the same prevention as a second approver.

Approval evidence should show the substance of the review. A timestamp and an “approved” state establish that someone clicked a button. They do not show whether the person inspected the migration, checked authorization boundaries, or considered rollback. A short review template can force attention without creating paperwork:

```text
Approved commit: 8f2c1a7
Risk class: high
Behavior checked: account deletion preserves retained invoice records
Security effect: authorization remains account scoped
Rollback: restore prior service version; migration is additive
Evidence reviewed: integration run 7714; policy decision 194
```

Do not retain entire agent conversations by default merely because more evidence feels safer. Prompts can contain source code, secrets pasted by mistake, customer data, or irrelevant reasoning. Keep the records needed to reproduce the controlled action: task identifier, tool and model identity when relevant, commit digest, test output, policy decision, approval, and deployment event. Apply your existing retention and access rules to those records.

The audit scope also matters. If the agent changes only a prototype outside the described production system, the release may not enter the SOC 2 change population. Once the agent can alter components that support the in scope service, changing its label to “experiment” does not remove the activity. Define scope by systems and effects, then reconcile production reality against that definition.

## Your control statement should survive a hostile reading

Read the proposed control as an auditor would: every noun needs an owner, every verb needs evidence, and every absolute creates a population that can contain exceptions. “Changes are reviewed” leaves open who reviews, what they see, what identifier they approve, and whether deployment can substitute something else.

Name the boundaries plainly. State which changes enter the process, how risk affects approval, who can authorize, which checks block release, which identity deploys, where logs go, how emergency access works, and who reviews exceptions. Then compare the text with actual permissions. Policy prose cannot compensate for an administrator toggle that lets the operator bypass the entire path.

Document ownership of service accounts as carefully as human access. Record who can issue tokens, change workload identity bindings, alter approval APIs, and assume the release role. A narrowly named bot account provides little separation when the routine operator can mint its credentials or impersonate it without generating a protected alert.

Ask your auditor to review the design before the examination period when the workflow differs from a conventional peer review model. The CPA firm must evaluate your specific facts, system description, and selected criteria. No article, compliance platform, or advisor can guarantee that a particular firm will accept a control without that work.

A Team & AI Audit can test whether a smaller AI augmented engineering model will produce the payroll savings you expect before you redesign the team. Keep the SOC 2 control assessment explicit in that redesign rather than treating one human and one model as two independent reviewers.

One person may approve production under SOC 2 when enforced systems constrain what that approval can release and make every bypass visible. If the same person can rewrite the gate, deploy another artifact, and erase the record, the number of agent personas on the screen changes nothing.