Amp 获得 SOC 2 Type II 认证，无需提交 pull request
编码智能体（coding agent）公司 Amp 的首席执行官兼联合创始人 Quinn Slack 支持一条会让不少安全团队皱眉的规则：工程师可以直接把代码推到主分支。Amp 表示，在拿到 SOC 2 Type II 认证的同时，他们保住了这套工作流程——靠的是签名提交、自动化验证和详细的智能体操作记录，而不是强制性的拉取请求（pull request）。
在 Amp 对 SOC 2 过程的说明中，公司表示，从第一次提交起就没有用过拉取请求；准备 SOC 2 时，他们直接把这一选择摆到了审计人员面前。据 Amp 的说法，审计人员评估的是它的变更管理流程，而不是指定某种 Git 工作流。Amp 当前的安全页面显示，它已经获得 SOC 2 Type II 认证。
这个认证对 Slack 来说分量不轻，因为 Amp 的核心前提是：AI 智能体应当改变软件开发的方式。Slack 在斯坦福学过计算机科学，此前联合创办了 Sourcegraph，在那里做大型代码库工具。他公开的目标是让每个人都能写代码。Amp 把这个理念用在了自己身上：它的智能体可以查看代码仓库、编辑文件、运行命令，而且在开发者合上笔记本电脑之后，还能继续在远程机器上干活。（Slack 简介）
按控制目标合规
美国注册会计师协会（AICPA）的信任服务标准（Trust Services Criteria）并没有指定 Git、拉取请求，也没有要求必须由第二个人类审查者把关。其中变更管理标准 CC8.1 规定，组织必须对其系统的变更进行授权、记录、测试、批准并实施。具体采用哪些控制措施来满足这些目标，由组织和审计人员共同决定。（AICPA 和 CIMA）
Amp 表示，它通过四项控制措施满足了这些目标。对主分支的访问按业务职能做了限制——尽管每个工程师都能推送代码，而 Amp 表示其大部分员工都是工程师（LinkedIn 档案显示团队规模目前在 11–50 人之间）。GitHub 要求推送到主分支的提交必须带有经过验证的签名。此外，每项变更都必须通过自动化测试、基础设施检查和安全检查。
提交记录也与产生它们的 Amp 线程相关联，从而在 CI/CD 记录变更进入生产环境的路径之前，保留下一项变更背后的指令、中间工作和决策记录。（Amp 对其控制措施的自述）最后这一项控制措施，恰恰说明了 Amp 的产品与运营模式如何相互强化。传统 pull request 保存的是 diff、评论和审批意见，而 Amp 声称其与线程关联的提交记录保留了产生变更的完整交互过程，为审计人员提供了超越最终代码的证据。因此，审批机制可以落在访问策略和自动化执行层面，而不必依赖第二位工程师的强制点击。需要说明的是，Amp 的描述仍然只是它自己对审计的叙述。公开说明并未指明审计机构或认证的审查期间，Amp 引导客户通过信任门户申请其报告——这些报告包含评估审计期间流程运行情况所需的范围和已测试控制项。现有证据可以确认 Amp 持有 Type II 认证，且其直推工作流被纳入了审计范围；但这并不意味着 Amp 的具体控制设计可以成为放之四海而皆准的模板。一位创始人押注于消除排队环节。Slack 之外，Amp 的其他联合创始人最初在 Sourcegraph 内部创建了这款产品，并于 2025 年 12 月 2 日将其分拆为独立公司。Sourcegraph 表示，两款产品需要不同的分发模式：Sourcegraph 将继续聚焦企业级代码搜索，而 Amp 则服务于愿意更早采用以智能体为中心的工作流的开发者和团队。Amp 称自己在分拆时已实现盈利，但未公布收入或客户数据。（Sourcegraph 的分拆公告）直推主分支的策略正是这一分拆理念的自然延伸。Amp 的智能体可以在名为 orbs 的远程机器上工作，每台机器都有一份全新的仓库副本和完成任务所需的工具。开发者可以在智能体工作时查看文件和终端，然后将变更同步到本地。Amp 将 orbs 定位为开发流程的一部分，其设计初衷是让智能体在笔记本电脑合上之后仍能无需监督地继续工作。
Amp 的 SOC 2 报告中提到一个观点：当写代码本身变得很快时，慢流程反而成了延误的源头。所以它的应对思路更倾向于隔离、自动检测，以及快速回滚。为了通过 SOC 2 审计，Amp 必须把这种运营理念落实成一套具体、可审计的控制项。这对创始人才是真正有参考价值的地方。合规要求往往和常见实现方式绑在一起：变更审批要走 pull request、授权要开工单系统、职责分离要有固定数量的审核人。Amp 的经验说明，创业公司完全可以挑战具体实现，同时保留控制目标本身——前提是能把风险讲清楚、有替代的强制手段，并且能向审计员提供证据。
不过这个做法的适用范围有限，Amp 自己也只做了很窄的声明。它的公开说明里写得很明白：这是一个以工程师为主的小团队，每个人都离生产代码很近。同时它也明确表示，不认为一个两千人的组织应该让每个工程师都能直接往主分支推送代码。大公司还存在利益冲突、经验参差不齐、监管负载、以及部署团队和系统本身脱节等问题。
签名提交只能证明身份，并不代表作者理解了所有下游影响。自动化测试只能拦住它设计时打算拦的故障，对新型风险或建模不充分的风险往往无能为力。而人工审查能捕捉到上下文、安全假设和组织依赖——这些是验证流水线容易漏掉的东西。
Amp 更有力的观点是：公司应该根据每个系统的风险等级来设定控制措施，而不是把最严格的工作流复制到所有仓库上。低风险的内部工具，未必需要和支付基础设施或处理敏感客户数据的软件走同一条审批链。
AI 生成代码让变更的数量和速度都大幅提升，不加区分的审查队列会变得越来越昂贵。对 Slack 和 Amp 来说，直接推送本身就是产品赌注的一部分。Amp 想证明的是：一个以 Agent 为核心（agent-native）的开发流程，完全可以既跑得更快，又不把企业合规变成事后才想起的事。
Amp 获得 SOC 2 Type II 认证，且无需强制 pull request
SOC 2 认证为 Amp 提供了审计师可以接受的模型证据。更严峻的考验还在后头：随着 Amp 团队扩张、客户群增长，以及 agent 编写的生产代码量逐渐超出当初那种高信任环境，认证所依赖的前提条件将不再成立，事情也会变得更难。