Amp tiene SOC 2 Type II sin requerir 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 y cofundador de la empresa de agentes de código Amp, respalda una regla que haría retroceder a muchos equipos de seguridad: los ingenieros pueden hacer push de código directamente a la rama main. Amp dice que preservó ese flujo de trabajo mientras obtenía la certificación SOC 2 Type II, usando commits firmados, validación automatizada y transcripciones detalladas de los agentes en lugar de pull requests obligatorios.

En el relato de Amp sobre su proceso SOC 2, Amp dice que las pull requests habían estado ausentes desde su primer commit y que llevó la decisión directamente a sus auditores cuando empezó a prepararse para SOC 2. Según la versión de Amp, los auditores evaluaron el proceso de gestión de cambios de Amp en lugar de prescribir un flujo de trabajo de Git. La página de seguridad actual de Amp indica que está certificada SOC 2 Type II.

Esa distinción tiene peso para Slack porque Amp está construido alrededor de la premisa de que los agentes de IA deberían cambiar la mecánica del desarrollo de software. Slack estudió ciencias de la computación en Stanford y previamente cofundó Sourcegraph, donde trabajó en herramientas para bases de código grandes. Su objetivo declarado es hacer posible que todos programen. Amp convierte esa tesis hacia adentro: sus agentes inspeccionan repositorios, editan archivos, ejecutan comandos y continúan trabajando en máquinas remotas después de que un desarrollador cierra una laptop. (Biografía de Slack)

Cumplimiento por objetivo de control

Los Trust Services Criteria de la AICPA no especifican Git, pull requests ni un segundo revisor humano. El criterio de gestión de cambios, CC8.1, dice que una organización debe autorizar, documentar, probar, aprobar e implementar cambios en sus sistemas. Deja a la organización y a su auditor determinar qué controles satisfacen esos objetivos. (AICPA and CIMA)

Amp dice que cumplió esos objetivos mediante cuatro controles. El acceso a main está limitado por función de negocio, aunque cada ingeniero puede hacer push y Amp dice que la mayoría de su personal son ingenieros. El perfil de LinkedIn de Amp actualmente sitúa su plantilla en el rango de 11-50 empleados. GitHub requiere firmas verificadas para los commits a main. Cada cambio debe pasar pruebas automatizadas, comprobaciones de infraestructura y controles de seguridad. Los commits también están vinculados a los hilos de Amp que los produjeron, creando un registro de las instrucciones, el trabajo intermedio y las decisiones detrás de un cambio antes de que CI/CD registre su camino hacia producción. (El relato de Amp sobre sus controles)

Ese último control muestra cómo el producto y el modelo operativo de Amp se refuerzan entre sí. Una pull request convencional preserva un diff, comentarios y aprobaciones. Amp dice que sus commits vinculados a hilos preservan la interacción que generó el cambio, dando a un auditor evidencia más allá del código final. El mecanismo de aprobación puede entonces residir en la política de acceso y la aplicación automatizada en lugar de un clic obligatorio de un segundo ingeniero.

La descripción de Amp sigue siendo su versión de la auditoría. La nota pública no identifica al auditor ni el período de examen de la certificación, y Amp dirige a los clientes a un portal de confianza para solicitar sus informes. Esos informes contendrían el alcance y los controles probados necesarios para evaluar cómo operó el proceso durante el período de auditoría. La evidencia disponible establece que Amp posee una certificación Type II y dice que su flujo de trabajo de push directo se incluyó en el proceso; no convierte el diseño exacto de controles de Amp en una plantilla universal.

Un fundador apostó por eliminar la cola

Slack y los otros cofundadores de Amp crearon el producto dentro de Sourcegraph antes de separarlo en una compañía independiente el 2 de diciembre de 2025. Sourcegraph dijo que los productos necesitaban diferentes modelos de distribución: Sourcegraph permanecería enfocado en la búsqueda de código empresarial, mientras que Amp serviría a desarrolladores y equipos dispuestos a adoptar flujos de trabajo centrados en agentes antes. Amp se describió como rentable en el momento de la escisión, aunque no publicó cifras de ingresos o clientes. (Anuncio de la separación de Sourcegraph)

La política de push directo a main sigue esa tesis de separación. Los agentes de Amp pueden trabajar en máquinas remotas llamadas orbs, cada una con una copia fresca de un repositorio y las herramientas necesarias para una tarea. Los desarrolladores pueden inspeccionar los archivos y el terminal mientras el agente trabaja, y luego sincronizar los cambios localmente. Amp presenta los orbs como parte de un proceso de desarrollo diseñado para permitir que los agentes continúen trabajando sin supervisión después de que se cierre una laptop.

La versión de SOC 2 de Amp dice que cuando escribir código se vuelve rápido, los procesos lentos se convierten en la fuente de la demora. Su respuesta pone más peso en el aislamiento, la detección automatizada y la reversión rápida. El proceso SOC 2 requirió que Amp expresara esa filosofía operativa como controles específicos y auditables.

Esa es la lección práctica para los fundadores. Los requisitos de cumplimiento a menudo se adhieren a implementaciones familiares: pull requests para la aprobación de cambios, sistemas de tickets para la autorización o un número fijo de revisores para la separación de funciones. La experiencia de Amp muestra que una startup puede desafiar la implementación mientras preserva el objetivo de control, siempre que pueda documentar el riesgo, aplicar la alternativa y producir evidencia para un auditor.

El límite es la escala

Amp hace una afirmación estrecha sobre dónde esto funciona. El relato público de Amp describe un equipo pequeño compuesto mayoritariamente por ingenieros, con todos cerca del código de producción. La nota rechaza explícitamente la idea de que una organización de 2,000 personas deba dar a cada ingeniero acceso directo a main.

Las empresas más grandes también enfrentan conflictos de interés, experiencia desigual, cargas de trabajo reguladas y equipos separados de los sistemas que despliegan. Un commit firmado confirma identidad; no establece que el autor entendiera cada consecuencia aguas abajo. Las pruebas automatizadas bloquean los fallos que están diseñadas para detectar, dejando riesgos novedosos o mal modelados sin tocar. La revisión humana puede captar contexto, suposiciones de seguridad y dependencias organizacionales que una canalización de validación pasa por alto.

El argumento más sólido de Amp es que las empresas deberían establecer controles según el riesgo de cada sistema en lugar de copiar el flujo de trabajo más estricto en todos los repositorios. Herramientas internas de bajo riesgo pueden no necesitar la misma cadena de aprobaciones que la infraestructura de pagos o el software que maneja datos sensibles de clientes. El código generado por agentes aumenta el volumen y la velocidad de los cambios, haciendo que las colas de revisión indiscriminadas sean cada vez más costosas.

Para Slack y Amp, los pushes directos son parte de la apuesta de producto. Amp intenta probar que un proceso de desarrollo nativo de agentes puede moverse más rápido sin convertir el cumplimiento empresarial en una idea secundaria. La certificación SOC 2 le da a Amp evidencia de que los auditores pueden aceptar el modelo. La prueba más difícil vendrá a medida que el equipo de Amp, su base de clientes y la cantidad de código en producción escrito por agentes crezcan más allá de las condiciones de alta confianza que hicieron posible el proceso.