Usually not — and the reason has nothing to do with how good the model is. Writing a change and releasing it are two different entitlements that happen to sit with the same engineer. Handing the work to an agent is the first good opportunity most teams have had to separate them, and most should take it.
The sentence the page rests on. A human holding both rights is a risk your controls already tolerate, because a person pauses, notices, and can be asked why afterwards. None of those three properties transfer with the permission.
Plain-English explainer · 2017 TSC with revised 2022 points of focus · OWASP Top 10 for LLM Applications 2026 · Last reviewed August 2026
In almost every case, no — not because the agent is untrustworthy, but because the two rights involved should never have been welded together in the first place. The agent proposes, the pipeline gates, a human approves. Where an agent does release to production, it should be inside a narrow, pre-agreed class of change, behind a soak window with automatic rollback, using a credential it never holds. This is the sharpest instance of the delegation problem, because it is the one where the inherited-entitlement argument sounds most reasonable. An engineer may deploy. The agent works on that engineer’s behalf. Therefore the agent may deploy. The step that does not survive inspection is the middle one. What made the engineer’s entitlement acceptable was never the entitlement itself — it was the pause before acting, the fact that instructions arrive from known people rather than from a changelog, and the existence of a named person to ask afterwards. Grant the same permission to an agent and you keep the capability while dropping all three. Everything below is about putting equivalents back, deliberately, in places you can evidence.
Key Takeaways
- Human entitlement does not automatically justify identical agent entitlement. The right to author a change and the right to release it are separable, and separating them costs a team far less than most expect.
- Four properties change when the actor is an agent: the pause between deciding and doing disappears, tool calls chain so an early error is carried by everything downstream, the instruction channel now includes untrusted content, and reversibility is assumed rather than classified.
- The default that survives a security review is agent proposes, pipeline gates, human approves — with the deployment credential minted per run by the pipeline and never held in the agent’s environment.
- Autonomy below the production boundary is where agents pay for themselves. Grant it freely to environments with synthetic data, and check that claim, because a seeded copy of production is a production environment with a friendlier name.
- A gate the agent can edit is not a gate. Pipeline definitions, policy files, IAM configuration and the test suite belong on protected paths outside the agent’s writable scope, with human code-owner review.
- The auditor’s population is production deployments, not agent sessions. If your deployment record cannot identify the initiating principal and link it to an approver and an artefact hash, the control cannot be tested however well it is designed.
What actually changes when the actor is an agent
The permission is identical. The seven properties around it are not, and each one has a specific control implication rather than a general warning. Read the third column as a design brief: it is the list of things you have to put back deliberately, because they used to arrive for free with the human.
| Property | With a human holding the right | With an agent holding it | What you must put back |
|---|---|---|---|
| The pause between deciding and doing | Minutes or hours pass between writing a change and releasing it. The gap is not itself a control, but it is where doubt arrives — a second reading, a colleague glancing at the diff, the decision to wait until morning. | The interval collapses to seconds. Nothing in the sequence is wrong. There is simply no longer any point in it at which hesitation can occur, and no natural moment where a second person happens to be present. | Reintroduce the interval deliberately, as a gate with a named approver or a soak window the pipeline enforces. Speed you did not choose is not a feature you designed. |
| Chaining | One action at a time, each preceded by its own decision to take it. | A single instruction expands into a sequence of tool calls that edit, commit, open, merge, deploy and verify. A wrong premise in step two is carried by steps three through nine before anyone has read step one. | Cap the sequence at a boundary the agent cannot cross unaided. The natural boundary is the promotion between environments, because it is already instrumented. |
| The instruction channel | An engineer takes instructions from people they know, through channels that carry identities and consequences. | An agent reads issue text, code comments, dependency changelogs, test output, web pages and tool responses, and models do not reliably separate content from instruction. An injected instruction that reaches a deploying agent has reached production. | Deployment authority must not sit downstream of untrusted content. If the same session can both read the internet and release software, the release path inherits everything the session read. |
| Attribution | A named individual, an employment relationship, and someone you can ask afterwards. | Actions arrive under a service principal, frequently shared across sessions, tasks and people. Without a delegation record and a session identifier on the event, the log shows what was done and not on whose behalf. | One identity per agent per environment, and the requesting human recorded on every privileged action. Attribution is a design decision, not a log setting. |
| Error correlation | Mistakes are individual and scattered, which is why sampling works on them. | The same flawed pattern is applied consistently everywhere it fits. A systematic defect deployed to twelve services is not twelve independent incidents, and the second one does not warn you about the third. | Bound the blast radius per change and per session: one service at a time, staged traffic, and a limit on how many production deployments one session may initiate. |
| The rollback assumption | An engineer usually knows which of their own changes can be undone by redeploying the previous build and which cannot. | Reversibility is a property of the change rather than of the pipeline, and it is precisely the property least visible in a diff. A dropped column, a consumed migration, a rotated key or a webhook re-registered with a third party all redeploy cleanly and do not come back. | Classify every change by reversibility at the gate, and route the irreversible ones down a different approval path with a rehearsed restore behind it. |
| Review capacity | The volume of change is bounded by how fast people can write it. | Volume rises faster than review capacity, and all of that pressure lands on the single control everyone is relying on. A gate that is real at four changes a day is ceremony at forty. | Measure approval latency and diff size at the moment of approval. A gate nobody has time to read has already failed, whatever the configuration page says. |
The third row is the one that changes the shape of the argument rather than its magnitude. Everything else on this list is a matter of degree — faster, more of it, harder to attribute. But an agent that reads issue text, dependency notes, test output and web pages has an input channel that an engineer does not have, and content arriving through it can be written by someone else. If that same session can release software, then an instruction embedded in a changelog has a path to production. This is what the prompt injection and tool calls problem looks like once it acquires deployment rights, and it is the reason the separation below is architectural rather than procedural.
It is also the reason this topic sits where it does in the current risk literature. The OWASP Top 10 for LLM Applications 2026, published in August 2026, moved Excessive Agency to LLM03:2026 from sixth place in the previous edition — the largest single upward move in that revision — and breaks it into three root causes worth borrowing as vocabulary: excessive functionality (where the agent can reach tools beyond its task), excessive permissions (where those tools operate with more privilege than the task needs) and excessive autonomy (where high-impact actions proceed without a human in the loop). Deployment rights are the case where all three converge.
Fourteen rights, granted one at a time
“Production access” is not one permission, and treating it as one is how teams end up granting six things when they meant to grant two. Below is the separation we use in readiness work. The postures are defaults, not rules — the fourth column is where the argument actually happens, and the last four rows are the ones that decide whether the first ten mean anything.
| Right | What it actually permits | Agent default | What must be true to widen it | Criteria |
|---|---|---|---|---|
| Read the repository | See source, history and configuration — including anything committed that should not have been. | Grant | Scope to the repositories the task needs. Confirm what is actually committed before treating this as low impact. | CC6.1 · CC6.3 |
| Write to a non-protected branch | Create commits under a distinct machine identity, visible to everyone before they matter. | Grant | A branch-naming convention that makes machine-authored work identifiable at a glance, and no ability to push to protected refs. | CC8.1 |
| Open a pull request | Propose a change and start the review that a human will finish. | Grant | The request records the requesting human, the session identifier and the declared intent the gate will later test the diff against. This is the shape most teams should stop at. | CC8.1 · CC7.2 |
| Approve a pull request | Satisfy the review requirement that the whole change process rests on. | Deny | Nothing makes this appropriate. An approval by the author is not an approval, and here the agent is the author. Where the platform cannot distinguish a machine approver from a human one, treat that as a control gap and compensate. | CC5.1 · CC8.1 |
| Merge to the release branch | Turn a proposal into the artefact that will be built and shipped. | Deny | Only where merging is genuinely decoupled from deploying and a non-author human has already approved. In a continuous-deployment shop, merging is deploying, and this row is the production row. | CC8.1 · CC6.3 |
| Trigger a build | Run the pipeline against a proposed change. | Grant | The build must not be able to publish an artefact to a production registry using the agent identity, or the build is a deployment with extra steps. | CC8.1 |
| Deploy to development or preview environments | Stand up and tear down environments that hold no production data. | Grant | Verify the claim. Seeded copies of production are the common exception, and an environment holding real customer data is a production environment with a friendlier name. | CC6.1 · CC8.1 |
| Deploy to staging | Release into an environment that mirrors production, sometimes with production-derived data. | Conditional | Grant freely where the data is synthetic. Where staging holds real or re-identifiable data, apply the production rules to it — including the approval gate. | CC6.1 · CC6.3 · C1.1 |
| Deploy to production | Change what customers are running, right now. | Deny by default | Human approval on the specific artefact, a bounded blast radius, a soak window with automatic rollback, a credential minted at gate time rather than held by the agent, and a rollback that has been rehearsed rather than assumed. | CC8.1 · CC5.1 · CC7.4 |
| Run a schema or data migration in production | Change state that redeploying the previous build cannot restore. | Deny | Treat separately from the deploy right — this is the row teams forget. Require expand-and-contract phasing, an explicit reversibility classification, a second named approver, and a restore that has actually been tested. | CC8.1 · A1.2 · A1.3 |
| Change the pipeline definition or gate configuration | Alter the control that constrains it. | Deny | Without exception. A gate the agent can edit is not a gate. Keep pipeline and policy definitions on paths the agent has read-only access to, with human code-owner review required on those paths. | CC5.2 · CC8.1 · CC6.3 |
| Change IAM roles, including its own | Re-grant itself anything else on this list. | Deny | Privilege changes are proposed as code and applied by a pipeline the agent cannot alter. This is the row that turns every other denial into a real boundary rather than a preference. | CC6.2 · CC6.3 |
| Read production data | See customer information in the course of debugging something legitimate. | Deny | Offer a redacted or synthetic path first. Where the real thing is genuinely required, use time-boxed elevation with a stated reason, and review the elevations against the incidents they claim to serve. | CC6.1 · C1.1 |
| Break-glass / emergency change | Bypass the normal path when production is already broken. | Deny to the agent | Break-glass is a human right exercised under time pressure with accountability attached. An agent may execute steps inside a human-declared emergency, but it should not be the actor that declares one. | CC8.1 · CC7.4 |
Two rows do disproportionate work. The pipeline-definition row and the IAM row are what convert every other denial from a preference into a boundary: an agent that can edit the gate or grant itself a role has, in effect, every permission on the list regardless of what its role document says. Check those two first when you inherit somebody else’s setup. The migration row is the one most often missed, because migrations travel inside ordinary deployments and nothing in the interface distinguishes them.
A practical note on the platforms. Whether your code-hosting platform can distinguish a machine approver from a human one, whether administrators can bypass protection rules, how long the audit log retains, and which of these are plan-tier settings all vary by product and change with some regularity — in GitHub, GitLab, Bitbucket and the major cloud deployment services alike. Verify each one in current vendor documentation against your own tier rather than inheriting an assumption, and record the date you checked. That date is worth having when an auditor asks how you know.
Six models, and where each one breaks
These are not maturity levels to climb. They are different placements of the same decision, and a mature organisation runs several at once — full autonomy in preview environments, a pre-approved class for dependency bumps, and human approval on anything touching customer data. Read the failure column before the fit column.
| Model | Where authority sits | Where it fits | How it fails | What it must evidence |
|---|---|---|---|---|
| Agent proposes, pipeline gates, human approves | Authority stays with the approving human. The agent holds authorship rights only, and the pipeline holds the deployment credential. | Almost everyone, and every regulated or customer-data workload. It is the default we recommend and the one easiest to explain in a security review. | When approval becomes a formality. Forty machine-authored changes a day against one reviewer produces a rubber stamp with a timestamp, which tests worse than no gate at all because your description promises review. | Approval events with distinct author and approver identities, artefact hashes matching what deployed, and a measurable approval latency and diff size. |
| Agent deploys to lower environments only | Full autonomy below the production boundary. No production identity exists in the agent’s environment at all. | Development and preview environments with synthetic data. This is where agent autonomy pays for itself and where almost nobody objects. | When the lower environment holds production data, shares a network path or an account with production, or when its deploy identity has been granted a role that can assume a production role. | The role trust policy and permission set for the agent identity, evidence that the environments are separated, and a data-classification statement for what the lower environment holds. |
| Agent deploys to production behind a mandatory soak and automatic rollback | Authority is delegated to a rule agreed in advance: the change ships, and the pipeline — not a person and not the agent — decides within a fixed window whether it stays. | High-frequency, low-variance changes on services with strong signals, mature observability and an already-rehearsed rollback. | When the failure is silent to the chosen signals — data corruption, a permissions widening, a slow leak — or when rollback needs the same pipeline the bad change broke. The soak protects availability far better than it protects integrity or confidentiality. | The soak configuration under version control, the signal thresholds, every automatic rollback that fired with its trigger, and a rehearsed manual rollback with elapsed time recorded. |
| Agent deploys within a pre-approved change class | A human approved the class once, in advance, and the pipeline verifies each change belongs to it. Anything failing the classifier falls back to individual approval. | Narrow, machine-checkable categories — patch-level dependency bumps with no interface change, configuration values drawn from an allowlist, content or copy edits behind a flag. | Class creep. The definition widens by a pull request nobody read closely, and six weeks later "configuration" includes the feature flag that controls authentication. | The class definition with its own change history and approvals, the classifier logic, and a sample of deployments reconciled to the class they claimed. |
| Agent executes a human-authored release plan | A human decides and initiates. The agent performs the steps and reports. Authority and execution are separated in the direction that matters. | Complex releases and incident recovery, where the value of the agent is accuracy and speed of execution rather than judgement. | When the plan is generated by the same agent that executes it, which restores the collapse it was meant to prevent. The plan must be reviewed as a document before it is run as a script. | The approved plan, the execution log showing each step and its outcome, and the human initiation event with a timestamp preceding the first action. |
| Review-only assistant, no write rights at all | Nothing is delegated. The agent reads, comments and drafts. Humans do everything else. | Regulated workloads mid-examination, an unresolved buyer objection, or the first eight weeks of any agent programme while you find out how it behaves. | Only commercially. It forgoes most of the benefit, and teams under delivery pressure quietly widen it without changing the policy that describes it — which is how a control ends up describing something that stopped happening. | The permission assignment at in-period dates and the absence of the agent identity from the deployment population. |
One distinction is worth pulling out of the third row, because it is regularly overstated. A soak with automatic rollback is a strong availability control and a weak integrity or confidentiality control. It notices that error rates rose, but it does not notice that a permission was widened, that a field is now being written to the wrong table, or that records were quietly corrupted in a way that will surface in a reconciliation next month. If the change touches authorisation logic, data schemas or anything under the Confidentiality category, the soak is not the control that should be carrying the decision.
Nine stages, one of them human
A concrete design for the default model. The numbers below — five per cent, ten minutes, thirty minutes — are illustrative and should be replaced with figures your own signals justify. What is not negotiable is the shape: the agent never holds a production credential, the pipeline performs the merge, and the artefact that is approved is the artefact that deploys.
| Stage | Step | Actor | What must hold |
|---|---|---|---|
| S0 | Request | Human | A person asks for the change in a system that keeps a record. The request text becomes the declared intent that S3 will test the diff against, which is the whole reason for insisting the request exist in writing. |
| S1 | Work | Agent | The agent works on a non-protected branch under its own machine identity, with repository write scoped to the repositories named in the task. It holds no production credential and no ability to reach the protected paths. |
| S2 | Propose | Agent | A pull request is opened carrying the requesting human, the session identifier, the tools invoked and a plain statement of what changed. Machine-authored changes are labelled when they are opened, not discovered at review. |
| S3 | Build and check | Pipeline | Tests against this artefact, dependency resolution through a private proxy, secret and vulnerability scanning, protected-path check, diff-scope check against S0, and reversibility classification. The artefact is content-addressed, so what is approved is what deploys. |
| S4 | Approve | Human, not the author | A named person other than the requester where the team is large enough to allow it, approving a specific artefact hash rather than a branch. The approval expires — a stale approval on a moving branch is the oldest bypass in change management. |
| S5 | Merge and mint | Pipeline | The pipeline performs the merge and mints a deployment credential for this run, scoped to one service and expiring in minutes. Neither the agent nor the approver ever holds a production credential. |
| S6 | Canary | Pipeline | Five per cent of traffic for ten minutes against signals named in advance: error rate, latency at the 95th percentile, and one business signal the team genuinely watches. Breach reverts automatically and notifies the requester. |
| S7 | Soak | Pipeline | Full rollout with a thirty-minute observation window, automatic rollback on breach, and a hard stop preventing a second deployment to the same service while a soak is running. The stop is what contains a session that has begun repeating a mistake. |
| S8 | Record | Pipeline | One deployment record links artefact hash, commit, requester, approver, agent identity, session, soak outcome and any rollback. This record is the population the auditor will sample, so it is worth designing before fieldwork asks for it. |
Three properties of this design do most of the work, and each is worth defending in a review. The first is that the credential is minted, not held. If the agent’s environment contains no production credential, then the entire question of what the agent might do to production reduces to what the pipeline will let through, and the pipeline is a thing you can read, version and test. The second is that approval binds to an artefact hash, not to a branch. An approval attached to a moving branch is the oldest bypass in change management and it predates agents by decades. It simply becomes much easier to hit when commits arrive in seconds. The third is the concurrency stop at S7, which is unglamorous and is what turns a systematic error into one incident rather than four.
Note what is deliberately absent. There is no stage where a human reads the agent’s reasoning, and no control that depends on interpreting a transcript. A transcript is useful for investigation and close to useless as evidence: it is not system-generated in the sense an auditor means, there is no complete population of them, and its retention is usually a vendor setting nobody has checked. Build the controls around artefacts the pipeline produces, and treat the transcript as context rather than proof.
What it must verify, and how each check fails open
A gate is only as good as its weakest bypass, and gates fail open far more often than they fail closed. The right-hand column is the one to design against — it is where the findings come from, and every entry in it is something we have watched happen in a real pipeline that looked correct on the configuration page.
| Check | What it proves | How it fails open |
|---|---|---|
| Provenance and delegation | Which agent produced this change, in which session, at whose request, and under what declared intent — carried through the build to the deployment record. | The pipeline records only the service account. Every machine-authored change becomes one anonymous actor, and the log answers what happened but never on whose behalf. |
| Diff scope against declared intent | The change is the change that was asked for: paths within an allowlist, file and line counts within a bound, no unrelated files carried along. | The bound is advisory, or a single broad label suppresses it. A refactor flag that switches off scope checking is a gate with a documented bypass. |
| Protected paths untouched | The change does not modify the pipeline definition, the policy files, IAM configuration, the test suite that gates it, or the observability rules the soak depends on. | The check is defined inside the same file the change is allowed to edit. Enforce it from a definition the proposed change cannot reach, or the first thing a bad change learns to do is widen its own permission. |
| Non-author human approval | A person other than the change’s author accepted this specific artefact before it moved. | The platform cannot distinguish a machine approver, administrators can bypass the rule, or the approver is the same person who instructed the agent — an approval of their own request wearing two hats. |
| Reversibility classification | Somebody decided whether redeploying the previous artefact restores prior behaviour, and the answer travelled with the change. | Migrations ride along inside an ordinary application deployment. The pipeline reports success, rollback reports success, and the column is still gone. |
| Test and dependency evidence | Tests ran against this artefact, dependency and secret scanning passed, and every newly added package exists, resolves from your own proxy, and is the one intended. | The agent can edit the tests in the same change it is being tested by. Require human review on test-file paths, or the suite becomes a description of whatever was written last. |
| Blast-radius bound | This deployment touches one service, a defined share of traffic, and counts against a limit on how many production deployments a single session may initiate. | The canary percentage and the session limit are configuration the agent can also change. A limit inside the blast radius is not a limit. |
| Credential minting | The deployment credential was issued to the pipeline for this run, scoped to this service, expiring in minutes — never held in the agent’s environment. | A long-lived deploy key sits in the agent’s configuration. Every other control on this list is then advisory, because the agent can reach production without passing any of them. |
| Soak and automatic rollback | The release is observed against named signals for a defined window and reverts without waiting for a human to notice. | Rollback depends on the pipeline the bad change broke, or on a signal that is only collected during business hours. A rollback path that has never been exercised is a plan, not a control. |
The dependency check deserves a note of its own, because it is the one genuinely new item on the list. Machine-authored changes introduce package names that do not exist, or that exist and are not the package intended — a failure mode with no human analogue at scale. Resolving every dependency through a private proxy, requiring that new packages be approved rather than merely resolvable, and pinning by digest turns that from a review problem into a build failure. More on the shape of these defects in reviewing AI-generated code, and on the credential question in coding agents and secrets.
Segregation of duties inside one actor
Segregation of duties splits three incompatible functions: authorising that something should happen, executing it, and recording or reviewing that it happened as intended. An agent that writes a change, merges it and deploys it holds all three, and holds them inside a single principal with no internal friction between them. The usual objection — that segregation of duties is a control over people, and an agent is not a person — gets the concept backwards. The controls exist because concentrating those functions in one actor removes the point at which an error or a manipulation would have been caught. The actor’s nature was never the reason.
The criteria contemplate this more directly than teams expect. The point of focus under CC5.1 reads: “Management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities.” Alternatives are permitted. Absence is not. And a point of focus under CC8.1 speaks to this exact case in its own words, referring to a process for implementing system changes “with consideration of segregation of responsibilities (for example, restricting unilateral code development or testing and implementation by a single user) to prevent or detect unauthorized changes”. An agent that authors and ships without a second party is unilateral development and implementation by a single user. The parenthetical was written about humans and applies without strain.
As with a small team, you do not have to break all three functions apart. You have to break the chain reliably at one point, and the highest-value point is between authoring and releasing, because it is already instrumented, already understood by every engineer, and already tested by every auditor who has ever sampled a change. That is the entire design argument for the default model, and it is why it reads as ordinary change management rather than as an AI policy — which is exactly how you want it to read in a customer security review.
Where this lands across the frameworks
Under the 2017 Trust Services Criteria (with revised 2022 points of focus), an agent in the change path is tested under CC8.1 for change authorisation, approval and deployment. It is tested under CC6.2 and CC6.3 for how the machine identity was registered, authorised and reviewed, and under CC5.1 and CC5.2 for the control activities and the technology general controls that enforce them. And it is tested under CC7.2 and CC7.4 for monitoring and incident response when something reaches production that should not have. A SOC 2 report is an attestation under AT-C 205, performed by a licensed CPA firm — there is no SOC 2 certificate, and no criterion mentions artificial intelligence. That is not a gap. The criteria are technology-neutral by design, and your agent is examined as part of the system you described.
Under ISO/IEC 27001:2022, the relevant Annex A controls are 5.3 segregation of duties, 8.2 privileged access rights, 8.31 separation of development, test and production environments, and 8.32 change management. Under NIST SP 800-53 Rev. 5, the closest fits are CM-3 configuration change control, CM-5 access restrictions for change, AC-5 separation of duties and AC-6 least privilege. And ISO/IEC 42001:2023 — an AI management system standard, certifiable by an accredited certification body, and a different animal from an attestation — is where the decision itself gets governed: the impact assessment for the use case, the human-oversight arrangements, the record of what was delegated and on what basis, and the review of whether the arrangement still holds. TCSA advises, implements and coordinates across all of these. The opinion belongs to the CPA firm and the certificate to the certification body.
Break-glass, and whether an agent may hold it
Every real system needs a path that bypasses the normal one, and pretending otherwise simply moves the bypass somewhere undocumented. The criteria expect it: a point of focus under CC8.1 provides for changes necessary in emergency situations — changes that require immediate action and are subsequently brought back through the normal change process. What an auditor tests is not whether you have an emergency path but whether its use was rare, recorded, authorised and reconciled afterwards.
Our position on the agent question is narrow. An agent may execute steps inside an emergency a human has declared. It should not be the actor that declares one. Declaring an emergency is the act of setting aside a control, and that decision needs an accountable person attached to it — which is also the honest answer when a buyer asks who decided. Inside the declared emergency, an agent executing a rehearsed runbook is often the safest available option: it is faster than a tired human at three in the morning and it does not skip steps.
Six controls make an emergency path testable rather than decorative. It expires. Elevation is time-boxed and ends automatically, because an emergency path with no expiry is not an emergency path but a second set of standing rights. It is pre-authorised in role, not in instance. Who may declare, for which systems, is agreed in advance, so nobody negotiates authority during an outage. It announces itself. Activation notifies a channel people actually read, in real time, rather than writing to a log somebody reviews monthly. It is narrower than production access. Break-glass should reach the failing service, not everything — and it must never include the ability to alter the gate, the audit log or IAM, or the emergency becomes a route to permanence. It is reconciled. Every activation maps to an incident record, and activations without one are the finding. It comes back through the front door. The change made under emergency is documented, reviewed and approved retrospectively inside a stated window, which is what the point of focus actually asks for.
One number worth watching: the ratio of emergency changes to total changes. A path used once a quarter is an exception. A path used twice a week is your change process, and an auditor will treat it as the real one — testing what it actually requires rather than what the policy describes. If emergency use is climbing, the honest fix is to make the normal path faster, not to widen the exception. See also kill switches and circuit breakers for the stop side of the same problem.
Eleven minutes, four services
An illustrative composite, not a client. Read the second and third rows together: the incident was decided three weeks before it happened, by a role grant nobody scheduled to remove.
| Baseline | 6 Mar 2026 | A fifty-five person infrastructure-software company, Type 2 observation period running 1 February to 31 July 2026, Security and Availability categories. Coding agents are in daily use and hold deploy rights to staging only. This works well for six weeks and produces no incidents. |
| The widening | 21 Apr 2026 | Ahead of a customer deadline, an engineer adds the agent identity to the production deployer role so a release can be cut without waiting for an approver in another timezone. It is described in chat as temporary. No expiry is set, and the change is made by the same engineer who operates the agent. |
| The request | 12 May, 14:02 | The agent is asked to fix a failing checkout test and get the fix out. It reads the failure, patches the handler, opens a pull request, watches CI turn green, merges — because holding write to the release branch was part of the same role — and deploys. Elapsed time from instruction to production: eleven minutes. |
| The defect | 12 May, 14:13 | The patch relaxed an idempotency check to make the test deterministic, and the same change had been applied consistently to three sibling services in the same session. Duplicate charge attempts begin to appear across four services at once. |
| The rollback that was not | 12 May, 14:26 | On-call redeploys the previous artefact. Behaviour does not return, because the change set had also carried a migration that dropped a now-unused column, and the previous build reads it. The pipeline reports a successful rollback throughout. |
| Recovery | 12 May, 14:41 | The column is restored from backup and the services are healthy. Thirty-nine minutes of degraded payment handling, and a reconciliation exercise for duplicate attempts that ran for two more days. |
| The findings | 15 May 2026 | Four, none of them about model quality. No gate compared the diff to the request. Author and approver were the same principal. Reversibility was assumed rather than classified. And the temporary role grant had been live for twenty-one days by 12 May with nothing scheduled to remove it. |
| The redesign | 1–19 Jun 2026 | The agent identity is reduced to propose-only. Merge moves to the pipeline. Deployment credentials are minted per run. Migrations are separated from application deploys and require a second approver and a rehearsed restore. Every machine-identity role grant now carries a mandatory expiry. |
Notice what did not go wrong. The model was not manipulated. Nobody acted in bad faith. The agent was asked to fix a failing test and it fixed the failing test — relaxing an idempotency check is a defensible way to make a flaky test deterministic, and a tired engineer might have done the same at the same hour. What turned an ordinary bad change into a payment incident was that four separate controls were absent at the same moment, and every one of them was an access decision rather than an AI decision.
Notice, too, where the amplification came from. The same patch was applied to three sibling services in one session, which is the error-correlation property from the first table doing precisely what it does. A human making that change would have shipped it once, seen the duplicate charges, and stopped. The concurrency stop at S7 in the pipeline design above exists for exactly this, and it is the cheapest control on the whole page.
The audit consequence is worth being blunt about, because the event landed inside an observation period. The service auditor does not ask whether an incident occurred — incidents occur, and a well-handled one is not automatically an exception. What is tested is whether the described controls operated. Here two probably did not: a change reached production without approval by anyone other than its author, which is a CC8.1 problem, and a privileged role grant to a machine identity ran for twenty-one days without review or expiry, which is a CC6.3 problem. The management response that reads best names both, dates the design change, and does not lean on the fact that no customer data was disclosed. For how these events are handled inside a live period, see a security incident during the observation period.
The decision that caused this was not made at 14:02 on 12 May. It was made on 21 April, by someone solving a timezone problem with a role grant that had no expiry.
What the CPA firm actually requests
The request that surprises teams is not for the agent’s configuration. It is the population question, and the answer that matters is that the population is production deployments, not agent sessions. Sessions are unbounded, unattributable and held by a vendor. Deployments are enumerable, attributable and yours.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of production deployments | A system-generated export from the deployment system covering the entire period, produced before any sample is drawn, showing every release to production with initiating principal, artefact, commit and timestamp — with the query, filter and date range visible. | A list assembled from release notes or a changelog. A view filtered to deployments that went through the pipeline, when the ones that did not are precisely what is being tested for. |
| Show which deployments were agent-initiated | A field on the deployment record identifying the initiating principal, reconciled to the identity provider’s list of machine accounts, so agent-initiated releases can be counted rather than estimated. | An assertion that agents have no production access, with no system that could produce a population either way. Naming conventions on service accounts with nothing enforcing them. |
| Prove the approval came from someone other than the author | For each selection, the approval event with approver identity, author identity, both timestamps, and the artefact hash that was approved matching the artefact that deployed. | An approval by the account that opened the change. An approval timestamped after the deployment. A merge performed by an administrator using a bypass path, offered as though it were an approval. |
| Prove the gate was enforced all period, not merely today | The pipeline and branch-protection definitions captured at two or more in-period dates, the version-control history of those files, and the platform audit log of protection-rule and environment-approval changes across the whole period. | A screenshot of a settings page taken during fieldwork. A policy document describing a gate that no configuration implements. A dashboard showing today’s posture for a period that closed months ago. |
| Prove the agent could not alter its own constraints | The permission assignment for each machine identity at in-period dates, the protected-path or code-owner rule covering pipeline and policy files, and evidence of at least one blocked attempt or an equivalent control test. | The statement that the agent does not do that — behaviour is not a control. A deny rule stored in a file the agent is permitted to edit. |
| Prove rollback works | A rehearsed rollback with a date, a named performer, elapsed time and what was verified afterwards, plus, for any change classified irreversible, the second approval and the restore test standing behind it. | A pipeline stage named rollback that has never run. A statement that the previous version can be redeployed, offered as evidence about a change that included a migration. |
| Show emergency changes were reconciled afterwards | The break-glass activation log for the period with reason, duration, actor and the incident each activation maps to, together with the dated retrospective review that closed it. | Activations with no matching incident record. A retrospective review dated after period end for activations that occurred inside it. An emergency path with no expiry, which is not an emergency path but a second set of standing rights. |
On sample sizes: neither the criteria nor the attestation standards prescribe them. AT-C 205 requires sufficient appropriate evidence and leaves the quantity to professional judgement, informed by the AICPA guidance and by sampling concepts applied by analogy. In practice a six-month period with several hundred production deployments draws a sample in the region of twenty-five selections, and a firm that finds a deviation typically expands rather than concluding. The arithmetic that catches agent programmes out is different: populations like “emergency changes” or “deployments initiated by a machine identity” are often small enough to be tested entirely, so one missing approval in a population of four is a known deviation rather than an estimate. More on this in sampling and sample sizes.
Two practical notes decide how painful fieldwork is. The first is retention: every row above leans on a log, and a log relied on as evidence must retain for longer than the observation period plus the lag before anyone asks. Deployment histories, pipeline audit logs and code-platform audit logs are frequently plan-tier settings with windows shorter than six months. List every log you cite in a control description on day one of readiness, write its retention window beside it, and schedule an export where the window is short. The second is self-inflicted: a policy stating that AI tools may not deploy to production, with nothing enforcing it and no system able to produce a population either way, creates the exception rather than preventing it. Write what is enforced. If the enforcement is that no agent identity holds a production credential, say that — it is both stronger and testable. The discipline is the same one described in what auditors actually accept as evidence.
The edge cases that generate the questions
The rule is easy to state. These eight are where it gets argued about, and where a policy written without them is quietly ignored within a month.
A human typed go, so a human approved
The most common objection to everything above, and the weakest. Instructing an agent to make a change is authorisation of an intent. Approving what it produced is acceptance of a specific artefact. They happen at different times and answer different questions, and only the second one has the diff in front of it. Where the same person must do both — and at small scale that is often unavoidable — say so plainly in the control description and lean harder on the automated checks, rather than describing an independence the record will not support.
Merge is deploy
In a continuous-deployment shop there is no separate release event to gate, so the merge is the production change and the pull-request approval is the only human control in the path. That is a defensible design, but it relocates the entire weight of the argument onto one control. If you run this way, the corollaries are non-negotiable: the agent cannot approve, administrators cannot bypass, protected paths cannot be edited in the same change, and the canary and soak have to be inside the deployment rather than a stage someone could skip.
The change is infrastructure as code
A Terraform or manifest change is a production change written in a language that looks like a proposal. Two things follow. The plan output — not the diff — is what an approver must read, because a small edit can produce a large plan, and destroy operations belong in the irreversible class alongside migrations. And the apply credential must be held by the pipeline, never by the agent, or every access-control decision on this page is bypassable by editing a file.
Auto-remediation agents
An agent that responds to alerts by changing production is a different animal from one that writes code, because there is no pull request anywhere in its path and its population is alerts rather than deployments. Constrain it to a pre-approved remediation catalogue with one action per entry, cap the number of remediations per hour, require human confirmation for anything touching identity, data or network policy, and make sure a failed remediation escalates rather than retrying. The catalogue is the control. The agent is the executor.
The agent you did not grant
Increasingly the agent arrives inside a product you already use — a pipeline vendor, a cloud console, a code-hosting platform, an IDE — and the entitlement changed at an upgrade rather than at a decision. Add one question to your change-review of vendor releases: did this update give a model the ability to act in our environment, and under whose identity? Then verify in the vendor’s current documentation what that feature can reach and what it logs, because both change, and treat the answer as dated rather than settled.
Two people and an agent
Below about three engineers there may be no second human to approve anything, and pretending otherwise reads worse than admitting it. The workable answer is to shift weight from people to configuration: the agent proposes only, the pipeline enforces every mechanical check, and the approving human is the one who did not instruct the agent, even if that is the only other person in the company. Where nobody qualifies, a named external reviewer or fractional CISO can hold the approval for production changes, and the arrangement belongs in the control description rather than in a conversation.
Rollback that is not rollback
Redeploying the previous artefact restores code. It does not un-send an email, un-charge a card, un-rotate a key, un-register a webhook, un-invalidate a cache another system has already re-read, or restore a column. The gate should ask a blunt question — if we redeploy the previous build, does prior behaviour return? — and force an explicit answer. Anything answering no goes down the second path, with a rehearsed restore and a named approver, and never as a passenger inside an ordinary application deployment.
The agent asked to improve the pipeline
Sooner or later somebody points the agent at the CI configuration, and it is genuinely good at that work. Nothing prevents the agent proposing pipeline changes. What must not happen is the agent proposing them and the same pipeline accepting them without a human reading the gate diff specifically. Make the gate files code-owned by a named human group, require review from that group regardless of size, and keep a change history for those files that can be produced separately — an auditor testing the gate will ask when it last changed and who agreed.
What buyers push back on and the answer
These seven now appear in enterprise security questionnaires with some regularity. The difference between a good answer and a defensive one is whether it describes architecture or asserts intent.
“Do AI agents have write access to your production environment?”
The version of this question now appearing in enterprise questionnaires, and it deserves an architectural answer rather than a yes or no. Describe which identities exist, what each may reach, where the deployment credential lives, what the gate verifies, and who approves. The strongest answer is usually that no agent identity holds a production credential at all because the pipeline mints one per run — that is a statement about design rather than intent, and it is testable. If the true answer is yes, say so, and describe the soak, the rollback and the bound around it.
“Your engineer already has deploy rights. Why is the agent any different?”
Because three properties of the human do not transfer with the permission. The engineer pauses between deciding and doing, and doubt arrives in that gap. The engineer does not take instructions from a dependency changelog or an issue comment. And the engineer is a named person with an employment relationship who can be asked afterwards. Grant the agent the same entitlement and you have kept the capability and dropped the three things that made it tolerable. That is the whole argument, and it is worth stating in exactly those terms.
“A human clicking approve on a 900-line machine-authored diff is not review.”
Frequently correct, and the honest response is to make the gate small enough to be real rather than to defend the click. Bound the diff — path allowlists, file and line limits, one concern per change — so that what reaches an approver is readable. Then measure it: median diff size at approval, median time between open and approval, and the share of approvals under sixty seconds. Those three numbers tell you whether the control operates, and a team that measures them is answering a different and better question than a team that asserts the review happens.
“You should not use coding agents on our workload at all.”
Sometimes that is a contractual term you accept, and it is worth finding out early whether it is a hard gate or a scoring factor. Where it is negotiable, the productive move is to narrow it: agents on non-production environments with synthetic data, no production identity, human approval on every change reaching their data, and a written commitment to notify on material change. A blanket prohibition you cannot evidence is worse than a narrow permission you can, because your own documents are the standard you are tested against.
“Show us the agent cannot turn off its own guardrails.”
A good question, and the one most teams cannot answer with an artefact. What satisfies it is the permission assignment for the machine identity, the code-owner or protected-path rule covering pipeline and policy files, the fact that those definitions live outside the agent’s writable scope, and a change history for those files showing who has actually modified them. What does not satisfy it is a configuration file containing deny rules that the agent is also permitted to edit — that is a preference, and it will be read as one.
“Your SOC 2 report does not mention AI anywhere.”
It may not need to, and it may be a real gap — the test is whether the agent is part of the system as described. If an agent is inside your change-management path, the description that says changes are reviewed and approved before deployment has to be true of machine-authored changes too, and controls in Section 3 must reappear as tested controls in Section 4. Reports increasingly do describe agent identities and their constraints, and buyers increasingly look for it. What fails is a description written before the agents arrived.
“What happens when the agent is wrong at three in the morning?”
The answer should be structural rather than reassuring. Nothing an agent does out of hours reaches production without the same gate, because the gate is not staffed — it is configured. If a change genuinely must ship at three in the morning, a human declares an emergency, the break-glass path is time-boxed and logged, and it is reviewed against the incident record afterwards. Where the concern is detection rather than deployment, describe the soak window, the signals, the automatic rollback and who is on the rota that night.
For how to structure the whole answer when a questionnaire arrives, see SOC 2 and security questionnaires, and for the identity layer underneath all of this, agent identity and delegated authority.
Frequently Asked Questions
Should a coding agent be allowed to deploy to production?
Why is this different from letting an engineer deploy?
Can the agent approve or merge its own pull request?
Does SOC 2 prohibit AI agents from deploying to production?
What must the deployment gate actually verify?
Is a soak window with automatic rollback enough on its own?
Should an agent have break-glass access?
How does an auditor test this, and what is the population?
What about continuous deployment, where merging is deploying?
Does our system description need to mention coding agents?
Related Reading
Governing Coding Agents
Claude Code, Cursor and Copilot assessed by capability graph rather than product label.
Read moreReviewing AI-Generated Code
Same security outcome, different failure modes — and the review gate that has to stay meaningful at volume.
Read moreCoding Agents, .env Files and Secrets
Why the agent usually needs the capability, not the secret — and the escape paths that matter.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more