Amp holds SOC 2 Type II without requiring pull requests

Why it matters

Amp shows founders can satisfy SOC 2 change-management objectives without copying a standard pull-request workflow. Agent-native teams still need enforceable access, testing and audit trails, especially as AI increases the volume of production changes.

Quinn Slack, CEO and co-founder of coding-agent company Amp, backs a rule that would make many security teams recoil: engineers can push code directly to the main branch. Amp says it preserved that 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, Amp says pull requests had been absent since its first commit and that it took the choice directly to its auditors when it began preparing for SOC 2. The auditors evaluated Amp's change-management process rather than prescribing a Git workflow, according to Amp's account. Amp's current security page says it is SOC 2 Type II certified.

That distinction carries weight for Slack because Amp is built around the premise that AI agents should change the mechanics of software development. Slack studied computer science at Stanford and previously co-founded Sourcegraph, where he worked on tools for large codebases. His stated goal is to make it possible for everyone to code. Amp turns that thesis inward: its agents inspect repositories, edit files, run commands and continue working on remote machines after a developer closes a laptop. (Slack's bio)

Compliance by control objective

The AICPA's Trust Services Criteria do not specify Git, pull requests or a second human reviewer. The change-management criterion, CC8.1, says an organization must authorize, document, test, approve and implement changes to its systems. It leaves the organization and its auditor to determine which controls satisfy those objectives. (AICPA and CIMA)

Amp says it met those objectives through four controls. Access to main is limited by business function, although every engineer can push and Amp says most of its staff are engineers. Amp's LinkedIn profile currently places its workforce in the 11-50 employee range. GitHub requires verified signatures for commits to main. Each change must pass automated tests, infrastructure checks and security checks. Commits are also linked to the Amp threads that produced them, creating a record of the instructions, intermediate work and decisions behind a change before CI/CD records its path into production. (Amp's account of its controls)

That last control shows how Amp's product and operating model reinforce each other. 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. The approval mechanism can therefore live in access policy and automated enforcement rather than a required click from a second engineer.

Amp's description is still its account of the audit. The public note does not identify the auditor or the certification's examination period, and Amp directs customers to a trust portal to request its reports. Those reports would contain the scope and tested controls needed to evaluate how the process operated over the audit period. The available evidence establishes that Amp holds a Type II certification and says its direct-push workflow was included in the process; it does not make Amp's exact control design a universal template.

A founder bet on removing the queue

Slack and Amp's other co-founders created the product inside Sourcegraph before separating it into an independent company on December 2, 2025. Sourcegraph said the products needed different distribution models: Sourcegraph would remain focused on enterprise code search, while Amp would serve developers and teams willing to adopt agent-centered workflows sooner. Amp described itself as profitable at the time of the split, though it did not publish revenue or customer figures. (Sourcegraph's separation announcement)

The direct-to-main policy follows from that separation thesis. Amp's agents can work on remote machines called orbs, each with a fresh copy of a repository and the tools needed for a task. Developers can inspect the files and terminal while the agent works, then synchronize the changes locally. Amp presents orbs as part of a development process designed to let agents continue working without supervision after a laptop is closed.

Amp's SOC 2 account says that when writing code becomes fast, slow process becomes the source of delay. Its answer places more weight on isolation, automated detection and rapid reversal. The SOC 2 process required Amp to express that operating philosophy as specific, auditable controls.

That is the practical lesson for founders. Compliance requirements often become attached to familiar implementations: pull requests for change approval, ticketing systems for authorization, or a fixed reviewer count for separation of duties. Amp's experience shows that a startup can challenge the implementation while preserving the control objective, provided it can document the risk, enforce the alternative and produce evidence for an auditor.

The limit is scale

Amp makes a narrow claim about where this works. Amp's public account describes a small team composed mostly of engineers, with everyone close to the production code. The note explicitly rejects the idea that a 2,000-person organization should give every engineer direct access to main.

Larger companies also face conflicts of interest, uneven experience, regulated workloads and teams separated from the systems they deploy. A signed commit confirms identity; it does not establish that the author understood every downstream consequence. Automated tests block the failures they are designed to detect, leaving novel or poorly modeled risks untouched. Human review can catch context, security assumptions and organizational dependencies that a validation pipeline misses.

Amp's stronger argument is that companies should set controls according to the risk of each system rather than copy the strictest workflow across every repository. Low-risk internal tools may not need the same approval chain as payment infrastructure or software that handles sensitive customer data. Agent-generated code raises the volume and speed of changes, making indiscriminate review queues increasingly expensive.

For Slack and Amp, direct pushes are part of the product bet. Amp is trying to prove that an agent-native development process can move faster without making enterprise compliance an afterthought. SOC 2 certification gives Amp evidence that auditors can accept the model. The harder test will come as Amp's team, customer base and amount of agent-written production code grow beyond the high-trust conditions that made the process possible.