It's Like a Self-Driving Car: Agentic Code Review and Your SOC 2 Type 2 Audit

Every conversation about agentic code review reaches the same sentence within about a minute. An auditor says it. A customer’s security team says it. I have said it myself. An agent is not a human.

Correct. And once you accept that, the interesting question is what an independent review is actually for, and whether a well-instrumented machine can give an auditor more of it than a tired person clicking Approve at 5:40 on a Friday.

I lead governance, risk and compliance at Augment Code, which makes SOC 2 Type 2 my job in the most literal sense. Our current Type 2 period has agentic reviewers inside the system boundary: changes authored by an engineer, reviewed by an agent (or, as I keep calling them in meetings, by our robots), merged into production. Preparing for it, we went back through our pull requests and tagged which ones were authored by a human, reviewed by an agent and merged, we rewrote our policy so that independence of review is defined as a property an agent can satisfy, and we decided to hit the question head on with our auditors rather than hope it would not come up. It came up in the first meeting. More than that, it is the question in nearly every customer conversation our team has. Augment Code’s customers are running the same pipeline, and their security leaders ask the same two things in the same order: is this something we can embrace? and how will we get this through our audit process?

The analogy I keep reaching for is a self-driving car, because it asks the right question: what is the governance framework that lets a new technology into society, and what did it take for regulators to say yes? Society did not accept autonomous driving because a person stayed in the seat. It accepted it because the sensors, the logs and the crash data turned out to be better than the person. Code review is heading the same way, and at the end of the day the pipeline that comes out of it is more secure than the one it replaces.

What the agentic SDLC did to code review

Start with the volume. Anthropic’s Deputy Chief Information Security Officer, Jason Clinton, wrote in July 2026 that “Claude authors about 80% of the code merged into our codebase today” (How Anthropic secures its AI-native software development lifecycle). Across 500-plus ordinary companies, DX measured the share of merged code authored by AI at 27.4 percent in early 2026, up from 22 percent a few months earlier (DX, April 2026). Inside Augment Code, before Cosmos, the engineering team had more than 1,400 open pull requests and a 20-hour median wait for a first review comment (How Cosmos removed the code review bottleneck).

Then look at what that volume does to the human on the other end. Faros AI’s telemetry across 10,000-plus developers found that high AI adoption came with 98 percent more pull requests merged, a 154 percent increase in average PR size, and a 91 percent increase in review time (Faros AI, The AI Productivity Paradox, July 2025). LinearB’s study of 8.1 million pull requests put review pickup at roughly 200 minutes for unassisted PRs and more than 16 hours for AI-generated ones, with merge rates of 84.5 percent versus 32.7 percent (LinearB, May 2026). And a 2026 study of open-source repositories found that 61.38 percent of agent-authored pull requests receive no recorded review activity at all; the authors conclude that “observable review activity does not necessarily correspond to direct human evaluation” (Duma et al., EASE 2026).

That last number is the one to sit with, because it is the software version of a safety driver watching a show on their phone. The review control still appears in the logs. It is no longer doing what the control was for.

It helps to remember what human review was doing before any of this. Microsoft Research found that finding defects was the top motivation developers gave for reviewing, and that only 14 percent of review comments actually concerned defects; the rest were improvements, knowledge transfer and alternatives (Bacchelli and Bird, ICSE 2013). Google’s analysis of nine million reviewed changes found a median of one reviewer and 24 lines modified per change (Sadowski et al., ICSE-SEIP 2018). The independent human reviewer that auditors sample for is, typically, one person reading two dozen lines, mostly for readability. That is a real and valuable control. It was never the exhaustive defect gate the compliance narrative implies.

Scott Dietzen, Augment Code’s former chief executive and now a board member, put the direction of travel plainly on this podcast:

“The role of the developer is going to move to being a tech lead for a team of agents.”

Scott Dietzen, board member at Augment Code, on episode 74

A tech lead does not read every line their team writes. They design the system that makes the team’s output trustworthy. That is also the job description of a change-management control.

What SOC 2 actually says about approving a code change

Here is the part of the audit conversation that surprised even people who have done a dozen SOC 2s (if you have done none, start with What Even Is a SOC 2?). The phrase “peer review” does not appear anywhere in the AICPA’s 2017 Trust Services Criteria. Neither does “someone other than the author.”

The change-management criterion is CC8.1: “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives” (AICPA, 2017 Trust Services Criteria with revised points of focus, 2022). Its points of focus are a list of processes that must exist: to authorize changes prior to development, to design and develop them, to document them, to track them prior to implementation, to test them, to approve them and to deploy them. The one that carries the whole peer-review tradition reads, in full: “A process is in place to approve system changes prior to implementation.”

It names no approver. The expectation that the approver is a second human is auditor practice, imported from the segregation-of-duties principle and from payment-card rules, and even the auditors who write it down hedge it. A CPA firm’s own guidance on the change review process describes final approval as “typically someone other than the change developer” (Sensiba LLP, 2024). Typically.

Segregation of duties does appear in the criteria, twice, and neither time in CC8.1. The relevant point of focus under CC5.1 says: “Management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities.” The escape hatch is in the text. The same criterion says control activities “may include a balance of approaches to mitigate risks, considering both manual and automated controls, and preventive and detective controls.” An automated preventive control is a first-class citizen of SOC 2 by design.

Other frameworks are even more direct. The National Institute of Standards and Technology’s Secure Software Development Framework tells organisations to “Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization” (NIST SP 800-218, PW.7.1). Its 2024 companion for generative AI adds that its practices “do not distinguish between human-written and AI-generated source code, because it is assumed that all source code should be evaluated for vulnerabilities and other issues before use” (NIST SP 800-218A). And PCI DSS v4, the strictest of the lot, only requires review by “individuals (other than the originating code author)” in requirement 6.2.3.1, which opens with the words “If manual code reviews are performed” (PCI DSS requirement 6).

So the criterion is not the obstacle. The habit is: every auditor has, until now, evidenced “a process is in place to approve system changes” with a screenshot of a pull request carrying a green approval from a different name. Our task is to hand them a better artefact and explain why it is better.

It’s like a self-driving car

The Society of Automotive Engineers defines six levels of driving automation, from Level 0 (momentary assistance) through Level 2 (continuous assistance with steering and speed, driver fully engaged) to Level 3 (the system drives, the driver stays available), Level 4 (fully responsible within a limited area) and Level 5 (fully responsible everywhere) (NHTSA, Automated Vehicles for Safety). The line that matters is between 2 and 3. Below it, the human is responsible for monitoring. Above it, the system is.

The coding-agent world has borrowed the ladder almost exactly. Tessl’s Guy Podjarny maps Level 0 (no automation) through Level 1 (AI as your coding assistant), Level 2 (partial automation with human oversight), Level 3 (conditional autonomy for defined scope), Level 4 (high autonomy with rare intervention) to Level 5 (full autonomy), and notes that the framework “works surprisingly well for AI agents” (Tessl, September 2025). Sourcegraph’s “Levels of Code AI” draws the same ladder and places the fulcrum precisely: at Level 3 the human stops reviewing each step the agent takes but still performs a high-level review of the final output, and at Level 4 the human need not review the final code at all (Sourcegraph). The CC8.1 approval question lives on that boundary.

Now the part of the analogy people skip. Society did not move autonomous vehicles up that ladder on trust. It moved them on evidence, published against a human baseline. Waymo reports that through March 2026 it had driven 220.6 million rider-only miles with 82 percent fewer injury-causing crashes, 94 percent fewer serious-injury-or-worse crashes and 93 percent fewer pedestrian-injury crashes than the human benchmark for the same roads (Waymo Safety Impact). A study with the reinsurer Swiss Re over 25.3 million autonomous miles found 88 percent fewer property-damage claims and 92 percent fewer bodily-injury claims (Waymo and Swiss Re, December 2024). The often-quoted figure that a driver was the critical reason in 94 percent of crashes is real, and the same NHTSA report warns that it “is not intended to be interpreted as the cause of the crash nor as the assignment of the fault to the driver, vehicle, or environment” (NHTSA, Critical Reasons for Crashes). Both halves matter: the machine is measurably safer, and the credible version of the argument keeps the caveats.

The failures teach the same lesson from the other side. When an Uber test vehicle killed a pedestrian in Tempe in 2018, the National Transportation Safety Board found the probable cause was “the failure of the vehicle operator to monitor the driving environment,” a case of automation complacency, and noted that the system’s design had disabled emergency braking in favour of relying on that operator (NTSB HAR-19/03). The guardrail was removed and a bored human was the only control left. Aviation learned this earlier: the 1997 American Airlines “Children of the Magenta Line” briefing defined an automation-dependent pilot as one who “does not select the proper level of automation for the task,” and prescribed stepping down a level when the situation stops matching the automation’s assumptions (Air Facts Journal).

Translate that into a code review policy and you get three rules. Pick the level of autonomy per risk class, not per team. Never make an inattentive human the only guardrail on a Level 3 system. Instrument everything, so the case for moving up a level is a dataset rather than a feeling.

Independence of review when the reviewer is an agent

With two humans, independence is a staffing rule: the author and the approver are different names. With an agent, independence has to be mechanical, which turns out to be a better place for it to live. This is the control design we describe to auditors and customers. It comes down to six properties.

The author cannot influence the referee. The review agent’s prompts, rules, guidelines and tool permissions live in version control and are protected the way production code is protected: changes to the reviewer go through their own review, and the author of a pull request has no write access to them. This is the GitOps principle applied to the referee, so that the player cannot sway the referee or rewrite its instructions, and it is the single most persuasive thing you can show an auditor, because it answers the independence question structurally rather than by assertion.

The referee has its own identity and no production credentials. The review agent runs as a distinct non-human identity, with read access to the change and the repository context it needs, and nothing else. It cannot merge and it cannot deploy. Anthropic’s playbook for the AI-native software development life cycle states the boundary in one line: “The agent that wrote the code has no way to approve it” (Anthropic, The AI-Native SDLC playbook).

The merge gate is mechanical. Branch protection requires the reviewer’s findings to be resolved before a merge can happen, and the merge itself is performed by a human who owns the change. In our own product the command that clears a pull request checks ownership of the modified files, unresolved reviewer findings and unaddressed runtime defects before it will proceed, and the documentation is explicit that “a human always owns and performs the final merge” (Augment Code, Cosmos code review pipeline). The human is accountable, the deployer is a different principal, and the independent review came from something the human could not lean on.

Risk decides where the humans sit. Not every change deserves the same level of autonomy. A classifier grades each change and routes the high-risk ones (authentication, authorization, data handling, infrastructure, anything touching a customer boundary) to a mandatory human checkpoint, while low-risk changes flow through the agent gate. Augment Code’s engineering leadership describes the discipline as choosing “the right level of autonomy for the risk involved” (Vinay Perneti, What is loop engineering). The self-driving analogy again: Level 4 on the highway, Level 2 in the school zone.

Everything is logged and replayable. Every review finding, every automated approval, every tool call and every merge decision lands in the security information and event management system with the inputs it used, so any decision can be reconstructed after the fact. This is where the agentic pipeline stops being a compliance risk and becomes a compliance asset. A human approval is a timestamp and a name. An agent approval is a transcript.

The referee is tested, not trusted. You measure your reviewer the way you would measure any detection control: precision and recall on known bugs, back-testing against the changes that caused past incidents, and a risk-weighted sample of its approvals re-read by humans. Anthropic reports that a retrospective run of its automated reviewer would have caught roughly a third of the bugs behind past incidents, and that it keeps humans reviewing a risk-weighted sample of automated approvals (Clinton, July 2026). That is the evidence an auditor wants for any control: not that it exists, but that you know how well it works.

Put those six properties in a policy, name the control “independence of review,” and the auditor’s sentence turns into your opening line. The agent is not a human. That is why we can prove it was independent.

How Augment Code builds independence of review into Cosmos

I should be clear about my interest: I work at Augment Code, and the reason I can describe this control in detail is that our platform is built around it. Cosmos, launched in June 2026, runs fleets of agents across the software development life cycle, waking on events such as a pull request opening and pulling humans in at defined checkpoints (Augment Code, Cosmos). Code review is the flagship loop.

A change moves through a sequence of specialised experts. A Risk Analyzer classifies the change and “applies your organization’s auto-approval policy to intrinsically low-risk changes.” A Deep Reviewer performs an exhaustive pass for correctness defects. A Pair Reviewer reconstructs the intent behind the change and guides the human through the judgment calls. A Verifier deploys the change into a running environment and exercises the affected behaviour, replacing “confidence based on code inspection alone with runtime evidence” in the form of logs and screenshots. A Memory Manager learns from merged changes and reviewer feedback so the fleet adapts to the team’s conventions over time (Cosmos code review pipeline). The Verifier is deliberately modest about what it knows: “The Verifier never posts a pass-or-fail result. A clean run means only that the behavior we tested matched the author’s intent, not that the PR is sound” (The bottleneck moved to verification). An auditor who has read a lot of vendor claims tends to like that sentence.

Underneath the fleet sits the permission model, which is where independence becomes enforceable. Agents run in isolated virtual machines. Tool permissions are declared as allow, deny, webhook-policy or script-policy rules, the most restrictive rule wins, and the configuration can be committed to the repository so every distributed agent enforces the same policy; permission flags set on the command line cannot be loosened by a permissive settings file (Augment Code, Permissions). Webhook policies let your change-management system make the allow-or-deny decision for a tool call in real time, which connects an agent’s actions to the approval workflow you already have. Cosmos adds enterprise identity through SAML and OIDC, role-based access, human-in-the-loop checkpoints configurable per loop, replayable runs and audit logs designed to feed your SIEM (Cosmos).

The results are the kind of evidence you can put in front of a customer’s security team. Running our own engineering through the pipeline, Augment Code reports that median merge time fell by roughly two-thirds, the bug rate per change dropped from 0.097 to 0.006, and the revert rate held at about 1.5 percent while code output more than tripled (How Cosmos removed the code review bottleneck); 97 percent of code reviews on Augment’s own repositories now run through Cosmos (Cosmos). The standalone Augment Code Review product, launched in December 2025, scored highest on the public AI code review benchmark at the time with an F-score of 59 percent, at about $1.50 per pull request (Augment Code Review launch). One MongoDB engineer’s description of how it fits with human review is the framing I use with auditors:

“It doesn’t replace human review; it enhances it by giving authors a thoughtful first pass before their teammates ever see the code.”

Tyler Kaye, Lead Engineer, Atlas Clusters, MongoDB, in Augment Code’s launch announcement

None of this works without context, which is where the security architecture and the review quality turn out to be the same investment. Augment’s Context Engine indexes a codebase in real time and enforces proof of possession: the client proves it holds a file by sending its SHA-256 hash before the service will use that file’s content, so an agent’s suggestions and reviews only draw on code the requesting engineer can access (Securing the code that writes code). The same post states the data commitment auditors ask about first: “We do not train on your code or your messages, nor can engineers read them by default.” Scott Dietzen’s version on the podcast was blunter.

“If you don’t have context, all you can do is vibe code.”

Scott Dietzen, Augment Code, episode 74

The compliance foundation predates the agents. Augment Code achieved SOC 2 Type 2 in July 2024 over an observation period from April 1 to July 1, 2024, without a single issue in the period (Augment Code achieves SOC 2 Type II): five months from a standing start with YSecurity’s team embedded, the story behind the Augment Code SOC 2 Type 2 case study and its 15x growth in security-qualified leads. In 2025 Augment became the first AI coding assistant certified to ISO/IEC 42001, the AI management system standard, by Coalfire (Coalfire, August 2025), 93 days from gap assessment to certificate (ISO 42001 case study). Enterprise customers can hold their own encryption keys (Customer Managed Keys), and EU tenants can optionally pin Cosmos to EU-only inference (Cosmos admin checklist). Evan Driscoll, Augment’s VP of Engineering, described the first of those programs on the record:

“YSecurity helped us raise our security to the next level.”

Evan Driscoll, VP of Engineering at Augment Code, in the SOC 2 Type 2 case study; hear him on episode 43

What Anthropic’s security team learned running the same experiment

Anthropic is the most instructive outside case, because it is further up the ladder than almost anyone and its security leadership has written down how the controls work. Jason Clinton, Anthropic’s first Chief Information Security Officer and now its Deputy CISO (RSA Conference speaker profile), published the design in July 2026, and three passages read like a SOC 2 system description for the agentic era.

On the reviewers: “When a PR is opened at Anthropic, multiple agents automatically review it. Each review agent is designed and scoped to a specific, narrow focus and leverages RAG for additional context and memory surrounding past incidents.” On the evidence, every agent action routes to the SIEM: “Every automated approval, tool call, and agent-to-agent message is logged with the signals it used and lands in our SIEM, so any decision is attributable and auditable after the fact. We use this data and treat these agents as a new type of insider threat, and raise alerts when they act out of alignment.” And on the outcome: “Human accountability is still central for code that is reviewed and merged by Claude,” with the share of pull requests receiving substantive review comments rising from 16 percent to 54 percent as the agents took the first pass (Clinton, How Anthropic secures its AI-native software development lifecycle).

“The security engineer’s job evolves from monitoring bugs to monitoring loops.”

Jason Clinton, Deputy Chief Information Security Officer, Anthropic, July 2026

Notice the shape of that program against the six properties above. Narrow, single-purpose review agents with their own identities. Everything to the SIEM. Agents treated as a class of insider, with alerting when they drift, which is the detective control behind the preventive one. A human still accountable for the merge. It is the same design, arrived at independently, by a company whose own institute noted that “human code review has become a new bottleneck” as more than 80 percent of its merged code became agent-authored (Anthropic Institute, When AI builds itself).

Clinton’s guide for chief information security officers, published four days earlier, supplies the governance vocabulary I now use in policy documents. “A CISO’s responsibility in the age of agentic AI is not to achieve zero risk. Instead, our jobs are to make agentic risk legible and bounded.” His principle of least agency, granting the narrowest capability that still completes the task, is the software version of choosing Level 2 for the school zone. And his warning is the one to put in front of anyone designing the merge step: “Ambiguous accountability is how incidents become unexplainable” (Clinton, Zero risk isn’t the job). A pipeline where a human owns the merge, the agent owns the review and the logs show which was which is the opposite of ambiguous.

Two more Anthropic findings belong in any conversation with an auditor about human-in-the-loop. Its Claude Code team found that users approve 93 percent of permission prompts, and built classifier-based “auto mode” because “approval fatigue” makes a confirmation click a weak control at agent speeds (Anthropic, Claude Code auto mode). The same team reported that sandboxing, which bounds what an agent can reach instead of asking permission for each action, cut prompts by 84 percent in internal use (Anthropic, Claude Code sandboxing). The pattern is consistent: the strongest controls on agents shape what the agent can do, and human attention is spent where it changes an outcome. Chris Kirschke borrowed the underlying thesis from Clinton on episode 102 of this podcast: if you can’t trust the inputs, you’ll never trust the output, whether the thing consuming the input is an analyst, a 2003 intrusion detection system or a review agent. Independence of review is how you make the reviewer’s inputs trustworthy.

The same control in FedRAMP, CMMC, ITAR, ISO 27001 and ISO 42001

SOC 2 is where most of Augment Code’s customers start, and almost none of them stop there. The good news is that the change-management control is the same control everywhere; only the numbering changes. Here is the crosswalk I keep on one page.

Framework	Control	What it says	What changes with agents
SOC 2	CC8.1, Approves System Changes	”A process is in place to approve system changes prior to implementation.”	No actor named. Evidence the gate operated across every change, not who clicked.
FedRAMP / NIST SP 800-53 Rev 5	CM-3, CM-4, CM-5(1), SA-15	Review and approve changes with security impact analysis; enforce access restrictions with automated mechanisms and “automatically generate audit records”; document the tools used (NIST 800-53 CM-5). SA-11(4), manual code review, is not part of any baseline.	Your agent, its model and its configuration are documented development tools under SA-15. Automated gates with audit records are exactly what CM-5(1) asks for.
FedRAMP 20x	KSI-CMT-VTD, KSI-CMT-RMV, KSI-CMT-LMC	”Persistent testing and validation of changes throughout deployment is automated”; changes ship by redeploying version-controlled resources; modifications are logged and monitored (FedRAMP 20x KSIs).	The indicators require automation. Agents that only ever open pull requests against version-controlled sources are natively aligned.
CMMC Level 2 / NIST SP 800-171	CM.L2-3.4.3, CM.L2-3.4.5	”Track, review, approve or disapprove, and log changes to organizational systems”; define and enforce access restrictions for change (CMMC practice 3.4.3).	Four verbs, no actor. Agent identities plus branch protection plus a separate deploy credential satisfy all four. Third-party Level 2 assessments phase in from November 10, 2026 (Squire Patton Boggs).
ITAR	22 CFR 120.50(a)(2), 120.54	Releasing technical data to a foreign person in the U.S. is a deemed export; end-to-end encrypted transit and storage is not (22 CFR 120.50; 120.54).	The question is who at the vendor and its model providers can read your prompts. Get U.S.-person access, retention and training commitments in writing.
ISO/IEC 27001:2022	A.8.25, 8.28, 8.29, 8.31, 8.32; 8.30; 5.19–5.23	Secure development life cycle, secure coding, security testing in development and acceptance, separation of development, test and production environments, change management; outsourced development; supplier and cloud-services controls (Annex A control list).	Encode secure-coding standards as agent rules so they are enforced rather than aspirational. Treat the agent as outsourced development capacity under 8.30.
ISO/IEC 42001:2023	A.4.4; A.6.2.4, A.6.2.5, A.6.2.8; A.9.2–9.4; A.10	Tooling resources; verification and validation, deployment, recording of event logs; responsible use of AI systems; third-party relationships (ISO 42001 controls list).	Users of coding agents are A.9 and A.10 subjects; providers are A.6 subjects. Augment Code is certified as a provider.
NIST SSDF SP 800-218 / 218A	PW.7.1, PO.3	Code review “and/or” code analysis “as defined by the organization”; use automation to generate artefacts of secure development. Practices “do not distinguish between human-written and AI-generated source code.”	The clearest textual permission anywhere for tool-based review, and a request for automation-generated evidence.
PCI DSS v4	6.2.3, 6.2.3.1	Custom software reviewed before release; “If manual code reviews are performed,” reviewers must be individuals other than the author.	The only “other than the author” rule in the set, and it is conditional on choosing the manual branch.

Three adjacent regimes deserve a sentence each. The EU Cyber Resilience Act’s vulnerability-reporting obligations apply from September 11, 2026, with full application on December 11, 2027 (Cyber Resilience Act explained), and a pipeline that already logs every finding is well placed for it. The EU AI Act’s general-purpose model obligations, in force since August 2, 2025, sit on model providers, and a coding agent is not in itself a high-risk system under Annex III, whose deadlines the Digital Omnibus moved to December 2027 (Gibson Dunn, May 2026). HIPAA’s Security Rule contains no code-review requirement; it asks for a periodic evaluation “in response to environmental or operational changes,” and adopting agents is one (45 CFR 164.308).

If you sell into government or defence, the ladder earns its keep one more time. FedRAMP 20x is explicitly replacing annual manual assessment with indicators that “can demonstrate security posture in near real time” (FedRAMP 20x). Continuous, machine-verifiable evidence is where assessors are heading, and an agentic pipeline is one of the few things that produces it by default.

How to evidence agentic code review in your next SOC 2 Type 2

This is the sequence we walk customers through, and it is the sequence that produced the evidence for our own audit. It fits on one page and it starts before you change anything.

1. Risk-assess the change itself. CC3.4 asks you to identify and assess changes in technology that could affect your controls. Introducing coding agents is exactly that change. Write the assessment; it becomes the paper trail that justifies everything below.
2. Rewrite the policy, and name the control. Define “independence of review” as a property of the pipeline rather than a count of humans. State which changes require a human checkpoint and why. Keep the old two-human path as an option for the highest risk classes.
3. Inventory your agents as identities. Each reviewer, verifier and author agent gets its own account, its own least-privilege permissions, and an owner, onboarded the way you onboard a person. This is the same access-review evidence you already produce for people; our primer on least privilege for agents covers the mechanics.
4. Protect the referee. Put reviewer prompts, rules and permissions in version control, protect that path like production, and show the auditor the change history. The author cannot touch it. Neither can the agent it is reviewing.
5. Gate the merge mechanically. Branch protection that blocks merges on unresolved findings; a human who owns the merge; a deploy identity that is neither. Write access is earned, which is the argument our write-access post makes for production and applies equally to main.
6. Log everything, and make it replayable. Every finding, approval, tool call and merge event to the SIEM with the inputs used. Alert on agents acting outside their loop. Keep enough to reconstruct any decision in the sample.
7. Measure the reviewer. Track precision and recall on known defects, back-test against past incidents, and re-read a risk-weighted sample of automated approvals. Keep the results where the auditor can find them. A reviewer nobody measures ends up like the shift-left scanner nobody reads.
8. Assess the vendors. Your agent platform and its model providers are CC9.2 vendors. Collect their SOC 2 and ISO 42001 reports, their training and retention commitments, and their sub-processor lists, and find the agents your teams adopted without telling you. Our vibe-coding security post has the questionnaire.
9. Tell the story in the system description. Section 3 of your report is where the auditor and every future customer will read how review works. Describe the fleet, the gates and the human’s role plainly, so nobody has to infer it from a screenshot.

Do those nine things and the evidence for CC8.1 stops being twenty-five screenshots sampled from a quarter and becomes a complete, queryable record of every change that reached production. That sentence changes the room with an auditor, and it closes deals with a customer’s security team. It is also, at the end of the day, a more secure pipeline: the reviewer never gets tired, never skims a 400-line diff, never approves because the author is a friend, and leaves a transcript every single time.

The agent is not a human. That is the point.

There is a version of the auditor’s sentence that I have come to agree with completely. An agent is not a human, so do not evidence it like one. Do not show a name and a timestamp and ask for the same benefit of the doubt a colleague gets. Show the identity, the protected configuration, the gate, the risk routing, the logs and the measurements, and let the control stand on its own.

The frameworks are ready for that. CC8.1 never named an approver. NIST wrote “and/or” into its code-review practice and told us it does not distinguish human from AI-written code. FedRAMP is rebuilding itself around continuous, automated indicators. What was missing was a working example and the vocabulary to describe it, and both now exist. SOC 2 stays the most useful piece of paper in enterprise sales for exactly as long as it keeps pace with how software is actually built, and the people keeping it relevant are the ones showing up to fieldwork with a pipeline they can prove. My job, once our own report is in hand, is to turn that experience into guidance our customers can use to configure and govern their own use of Augment so this control domain is handled before anyone asks.

If you are heading into your own Type 2 with agents inside the boundary, YSecurity’s team has done this at Augment Code and can help you design the control, write the policy and assemble the evidence before your auditor asks. Book a free 15-minute strategy call and bring your pipeline diagram. And if you would rather hear the builders first, Scott Dietzen’s conversation on episode 74 and Dirk Meister’s on episode 77 are where this story started.