Token Security sostiene que las auditorías SOC 2 deberían tratar a los agentes de IA como una categoría de identidad propia. La empresa afirma que los criterios tecnológicamente neutrales del marco pueden abarcar a los agentes, pero no exigen expresamente que las organizaciones o los auditores los traten por separado.
Esta brecha puede inducir a error en las revisiones de acceso. En un ejemplo de Token Security, una revisión registra 50 consultas a una base de datos de producción a las 10:03 bajo el nombre de un ingeniero sénior. Sin embargo, el ingeniero había ido a por café y su agente estaba realizando actualizaciones.
La empresa señala cuatro supuestos en los que se basan las prácticas habituales de acceso: que las cuentas se aprueban antes de crearse, tienen un responsable conocido, los registros identifican quién realizó la acción y los permisos indican el trabajo previsto. Según la empresa, los agentes pueden crearse como consecuencia de acciones como aprobar una solicitud de OAuth o añadir un servidor MCP, carecer de un responsable registrado, usar credenciales prestadas y actuar según instrucciones y contextos cambiantes.
Token Security también afirma que estas brechas pueden debilitar tres controles SOC 2, incluidos los procesos para retirar accesos cuando alguien deja la empresa. Los agentes vinculados a empleados que se marchan pueden seguir funcionando mediante concesiones de OAuth o claves de API. La empresa cita un estudio realizado con Cloud Security Alliance según el cual más de dos tercios de las organizaciones no pueden distinguir claramente las acciones de los agentes de IA de las humanas. Token Security sostiene que SOC 2 debe adaptarse a estos riesgos para evitar quedar obsoleto.
Comentarios
0Aún no hay comentarios. Escribe el primero.