Build1 publisher3 min readPublished
Amp got SOC 2 Type II without pull requests, which kills a convenient excuse
The AICPA's change-management criterion asks whether changes are authorized, tested and approved, not whether a second engineer clicked approve. Amp says its auditors agreed.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- Quinn Slack is CEO and co-founder of the coding-agent company Amp, and backs a rule allowing engineers to push code directly to the main branch.
- Amp says it preserved its direct-to-main workflow while obtaining SOC 2 Type II certification, using signed commits, automated validation and detailed agent transcripts instead of mandatory pull requests.
- In Amp's account of its SOC 2 process, pull requests had been absent since its first commit, and Amp took the choice directly to its auditors when it began preparing for SOC 2.
- According to Amp's account, the auditors evaluated Amp's change-management process rather than prescribing a Git workflow.
- Amp's current security page says it is SOC 2 Type II certified.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Amp, the coding-agent company run by co-founder Quinn Slack, says it holds SOC 2 Type II certification while letting engineers push straight to the main branch, with no mandatory pull requests [1][2][5]. What matters here is subtractive: it removes the argument that a second engineer's approving click is a compliance requirement rather than a management choice.
The criteria support that reading. The AICPA's Trust Services Criteria do not mention Git, pull requests or a second human reviewer [6]. CC8.1, the change-management criterion, requires an organization to authorize, document, test, approve and implement changes to its systems, and leaves the organization and its auditor to determine which controls satisfy those objectives [7]. Amp says pull requests have been absent since its first commit and that it took the workflow to its auditors when it began preparing for SOC 2; by Amp's account, the auditors evaluated its change-management process rather than prescribing a Git workflow [3][4].
What replaced the gate is not nothing. Amp describes four controls: access to main limited by business function, GitHub-enforced verified signatures on commits to main, mandatory passage of automated tests plus infrastructure and security checks, and commits linked to the Amp threads that produced them [8][10][11][12]. The first is thinner than it sounds. Every engineer can push, and Amp says most of its staff are engineers [8]; with headcount in the 11-50 range on its LinkedIn profile [9], the group excluded by business function is a minority of a small company, fewer than 25 people at the outer bound [24]. The weight sits on the automated checks and the transcript.
The transcript is the part worth copying. A conventional pull request preserves a diff, comments and approvals; Amp says its thread-linked commits preserve the interaction that generated the change, giving an auditor evidence beyond the final code [13]. That is what allows the approval mechanism to live in access policy and automated enforcement instead of a queue [14]. It also ties the control to the tooling: Amp's agents inspect repositories, edit files, run commands and continue on remote machines after a developer closes a laptop [19], and its orbs give each task a fresh repository copy and toolset that a developer can watch and then synchronize locally [20]. A team whose agent work leaves no durable, commit-linked record of instructions and intermediate steps does not have this control, whatever its branch protection settings say.
Caveats in order of size. This is Amp's account of its own audit: the public note identifies neither the auditor nor the examination period, and Amp directs customers to a trust portal to request reports [15]. Those reports are what carry the scope and tested controls needed to judge how the process operated across the period [16]. The available evidence establishes that Amp holds a Type II certification and says direct push was included; it does not make Amp's control design a universal template [17]. Scale is a factor too. Amp was built inside Sourcegraph and separated into an independent company on December 2, 2025, with Sourcegraph citing different distribution models, and Amp called itself profitable without publishing revenue or customer figures [21][22].
Amp's stated logic is that when writing code becomes fast, slow process becomes the source of delay, so its controls emphasize isolation, automated detection and rapid reversal [18].
Watch whether the trust portal reports name an examination period long enough to cover the direct-push workflow in operation, and whether the tested controls match the four described publicly [15][16]. Watch, too, whether anyone larger than 50 people passes an audit on the same design [9].