Algunos cumplimientos son más bien de escaparate, y eso siendo generosos. Se hacen para obtener la insignia en el sitio web, no para encontrar puntos débiles en la organización. SOC 2 no es así. Hay una razón por la que los equipos de compras de los clientes lo exigen: quieren saber si pueden confiar sus datos, y el cumplimiento de SOC 2 es la forma aceptada de demostrarlo. Puede que no sea la razón por la que se cierra un trato, pero ese trato no se habría cerrado sin él.
Hemos vivido bajo el lema de 'moverse rápido y romper cosas' durante tanto tiempo que asumimos que la disrupción significa, por definición, romper cosas. Sin embargo, con los agentes de IA no es tan sencillo debido a cómo utilizan la infraestructura existente. Considere una fila de revisión de accesos: una base de datos de producción, a las 10:03 a. m., 50 consultas a nombre de un ingeniero sénior. Se aprobó correctamente; todo cumple con el control. Pero ese ingeniero estaba tomando café en ese momento, mientras su agente realizaba actualizaciones en producción.
Los criterios neutrales en cuanto a tecnología de SOC 2 pueden cubrir agentes de IA, pero no exigen explícitamente que las organizaciones o los auditores los traten como una clase de identidad distinta. Esa discrecionalidad permite que los agentes de IA añadan riesgo a un entorno sin fallar un solo control. Si SOC 2 permite esto, el marco debe cambiar o corre el riesgo de quedar obsoleto.
Lo que está sucediendo
Durante una auditoría, se evalúan dos cosas: si el control cumple con un criterio de cumplimiento y si funcionó durante todo el período de revisión. Pero, ¿qué pasa con probar si el diseño sigue siendo relevante? A veces, cuando hay un cambio, una prueba se vuelve más difícil. Pero a menudo simplemente se vacía, porque la actividad ocurre en otro lugar, lo que nos lleva a los Criterios de Servicios de Confianza en SOC 2. No es que estén equivocados, pero cuatro suposiciones comunes ya no se sostienen y, como resultado, tres controles se están vaciando. Las suposiciones son:
- Alguien aprueba una cuenta antes de que se cree.
- Cada cuenta tiene un propietario conocido.
- El nombre en el registro identifica al actor.
- Lo que una cuenta puede hacer indica lo que se espera que haga.
Cuatro suposiciones que ya no se sostienen (CC6.1–CC6.3)
Cada criterio de acceso se basa en suposiciones sobre lo que controla. Mientras los actores eran humanos, esas suposiciones eran lo suficientemente seguras como para que nadie necesitara escribirlas. Con los agentes, esto ya no es así.
1. Alguien aprueba una cuenta antes de que se cree.
SOC 2 exige registrar y aprobar a un usuario antes de otorgar capacidades de inicio de sesión. Para los humanos, esto significa que alguien solicita un inicio de sesión, otra persona lo aprueba y lo registra. Los agentes, en cambio, son como un efecto secundario de una acción general. Puede ser un desarrollador haciendo clic en 'Permitir' en una pantalla de OAuth, una clave API pegada en un archivo de configuración o un servidor MCP añadido a un archivo JSON. Nadie aprobó la creación de un agente; simplemente sucedió.
2. Cada cuenta tiene un propietario conocido.
En los procedimientos de revisión de accesos, una persona nombrada confirma que la cuenta revisada aún debe tener acceso. Para los agentes, es común que no tengan un propietario nombrado. Hay que reconstruirlo a posteriori, a partir de evidencia circunstancial y conjeturas, examinando los artefactos del agente asociados a humanos, como claves y repositorios. A escala, la propiedad de un agente es una conjetura educada en lugar de un registro determinista. SOC 2 no tiene en cuenta esto: un propietario supuesto y uno registrado se ven igual en una hoja de cálculo de revisión.
3. El nombre en el registro identifica al actor.
Este es el punto costoso, que ya mencionamos en el ejemplo de las 10:03 a. m. A menudo, los agentes trabajan con credenciales prestadas: una sesión iniciada, un token de desarrollo o una cuenta de servicio. Esa es la persona que aparecerá en los registros y en la revisión de accesos. Esto pasará la revisión, ignorando por completo las diferencias de seguridad entre personas y agentes. Por un lado, la revisión de accesos será completamente precisa. Por otro, no dirá lo que realmente se necesita saber. Un estudio reciente con Cloud Security Alliance encontró que más de dos tercios de las organizaciones no pueden distinguir claramente las acciones de agentes de IA de las humanas.
4. Lo que una cuenta puede hacer indica lo que se espera que haga.
El principio de mínimo privilegio opera bajo la suposición de que una cuenta tiene un trabajo permanente, y la lista de cosas que puede hacer nos dice para qué sirve. Para las personas, eso suele ser correcto. A menos que su CEO quiera ser administrador en todas partes, los niveles de acceso se adaptan al puesto. Para los agentes, los límites de acceso reducen el radio de impacto, pero no indican lo que se espera que haga el agente en un momento dado. Eso depende de las instrucciones recibidas, el contexto absorbido y las decisiones que tome el agente. Por lo tanto, verificar los permisos proporciona la visión más amplia posible de lo que puede suceder sin proporcionar contexto sobre las acciones del agente.
Más allá de la casilla de verificación
Su informe SOC 2 dice que los controles funcionaron, pero nunca dice qué pasaron por alto. Los agentes operan con credenciales prestadas, sin propietario y sin interruptor de apagado. Token Security encuentra cada agente, le asigna una identidad y remedia su acceso al trabajo para el que fue creado.
Tres controles que pasan sin cubrir nada
Así es como las suposiciones que hemos mencionado reducen la efectividad de tres controles de SOC 2.
Nada dice nunca que un agente debe detenerse (CC6.3)
Cada auditoría SOC 2 evalúa la baja de empleados, y para los empleados humanos, las empresas se han vuelto muy buenas en eso. Los sistemas de RR. HH., el IdP y los sistemas SaaS trabajan en conjunto cuando el departamento de RR. HH. marca a una persona para su baja, ejerciendo así su autoridad incuestionable. Incluso la evidencia se escribe sola. No hay sistemas de RR. HH. para agentes. No hay un organismo centralizado y acordado que esté en posición de decir que un agente específico debe detenerse. No es un control roto, sino uno que simplemente no abarca a los agentes y las identidades que utilizan. Lo que lo empeora es que los agentes están mayormente vinculados a humanos, por lo que cuando una persona se va, los agentes configurados a su nombre pueden seguir funcionando utilizando concesiones OAuth o claves API, a menos que se contemple este escenario.
La revisión de proveedores comienza en la compra (CC9.2)
SOC 2 gestiona los procesos relacionados con las relaciones con proveedores. Se contrata, evalúa, recopila un informe y se revisa anualmente; funciona bien para proveedores que llegan con una orden de compra. Un servidor MCP es un proveedor en todo lo que importa: recibe sus datos, actúa en su nombre y ejecuta código que nadie en la empresa lee. En lugar de una orden de compra y un acuerdo de datos, llega en un archivo de configuración. A menudo, no hay ninguna empresa al otro lado. Alrededor de tres de cada diez nombres en nuestro registro no se pueden asociar con una empresa existente. Esa es una cifra del espacio de nombres, no de un entorno específico, pero apunta a un problema de cumplimiento fundamental para muchos MCP: no se puede recibir un informe SOC 2 de un proveedor sin nombre. El mismo problema aparece para los agentes de IA. Cuando los encontramos en las máquinas de los empleados, solo algunos son seguros de bloquear; el resto se retiene porque el nombre del programa puede coincidir con algo que el cliente construyó. Identificar un agente es más difícil que identificar a una persona. Si está listo para explorar los controles de seguridad de agentes de IA, solicite una demostración con Token Security para ver qué se esconde en su entorno.
Segregación de funciones entre dos instancias de la misma política (CC8.1)
Al implementar la gestión de cambios, los cambios deben ser autorizados, probados, aprobados e implementados. En la mayoría de las implementaciones, el autor y el aprobador deben ser personas diferentes debido a la segregación de funciones. Cuando un agente hace un cambio y un segundo agente lo revisa, la separación es solo nominal, aunque haya dos identidades involucradas. Mientras tanto, la autorización quedó fuera del alcance de la auditoría. La decisión sobre el cambio puede ocurrir en un prompt, en una herramienta que no aparece en la descripción del sistema. La única evidencia es una solicitud de extracción.
El argumento más fuerte en contra de todo esto
Vale la pena señalar que nada en los Criterios de Servicios de Confianza dice 'humano'. CC6.2 utiliza 'usuarios internos y externos', mientras que CC6.1 usa 'activos de información protegidos'. Los criterios se escribieron para evitar nombrar tecnologías y describir resultados en lugar de métodos. Así que no hay razón para no cubrir a los agentes. Se tratan las cuentas de máquina como usuarios, se listan los agentes en las descripciones del sistema y se prueban adecuadamente. Es algo que sucede en el mundo real. Dicho esto, dado el nivel actual de disrupción, la ambigüedad podría no ser suficiente. Sin menciones específicas de agentes en los criterios, lo que se cubre se acuerda entre usted y su auditor. Ambos tienen razones para preferir un alcance fácil de evidenciar. Mientras se pueda dejar fuera a los agentes sin registrar una sola excepción, algunos lo harán.
Lo que nunca ha significado un informe limpio
Un informe limpio significa que sus controles se comportaron como usted dijo que lo harían, no que la descripción fuera completa. La brecha solía ser lo suficientemente pequeña como para ignorarla, pero ya no lo es. Ahora es perfectamente posible tener un informe Tipo 2 sin salvedades y no poder responder, el día de su emisión, cuatro preguntas sobre su propio entorno de producción.
- ¿Qué se ejecuta ahí? – Control: Registro y autorización de usuarios (CC6.2). Por qué pasará: El agente nunca fue registrado, así que nada pareció faltar.
- ¿Quién lo autorizó? – Control: Autorización de cambios (CC8.1). Por qué pasará: La decisión ocurrió en un prompt, antes de la evidencia.
- ¿De quién son las credenciales que lleva? – Control: Revisión de accesos (CC6.1). Por qué pasará: Credenciales de un empleado real, con un rol aprobado.
- ¿Quién podría apagarlo? – Control: Eliminación de accesos (CC6.3). Por qué pasará: La baja se ejecutó correctamente y nunca marcó a los agentes.
SOC 2 no está equivocado. Es preciso sobre un mundo que se movió. Así que trate las cuentas de máquina como usuarios y vaya más allá de lo que pide el informe. La lista de permisos puede decirle a qué puede acceder un agente; no le dice para qué está ahí un agente. Cerrar esta brecha es lo que entendemos por seguridad basada en la intención: se establece lo que cada agente debe hacer y luego se hace que su acceso coincida. La identidad es la capa donde ese control realmente se sostiene porque abarca todos los sistemas que toca el agente. El informe no cambiará, pero estos controles están ahí por una razón, y a los atacantes no les importan las listas de verificación. Cada entorno tiene una línea de revisión de accesos que parece aprobada pero no dice nada. Token Security le muestra el agente detrás de ella: quién es su propietario, de quién son las credenciales que usa y si lo que puede alcanzar aún se alinea con lo que está ahí para hacer. Solicite una demostración y revisaremos su entorno juntos. Patrocinado y escrito por Token Security.
Deja una respuesta