Adam Markowitz, director ejecutivo y cofundador de Drata: serie de entrevistas

Adam Markowitz es director ejecutivo y cofundador de Drata, donde está ampliando la labor de la empresa en materia de cumplimiento continuo y confianza para abarcar la gobernanza de agentes de IA. Antes de cofundar Drata en 2020, fundó Portfolium junto con Troy Markowitz y Daniel Marashlian. Su experiencia con cuestionarios de seguridad, auditorías y revisiones de cumplimiento contribuyó a dar forma al enfoque de Drata para automatizar la manera en que las organizaciones demuestran que son confiables.

Drata ofrece una plataforma de gobernanza, riesgo y cumplimiento que combina la recopilación automatizada de evidencias, la supervisión continua de controles, la gestión de riesgos de terceros y flujos de trabajo para cuestionarios de seguridad. Sus capacidades de gobernanza de agentes de IA se centran en detectar agentes, aplicar políticas antes de que se ejecuten acciones y registrar decisiones para que puedan auditarse. En esta entrevista, Markowitz habla de las amenazas internas que plantean los agentes, la identidad de máquina, los límites de seguridad de las llamadas a herramientas y los controles que las empresas necesitan para desplegar agentes autónomos a gran escala.

Antes de cofundar Drata en 2020, fundó Portfolium y vivió en primera persona lo engorroso que podía volverse el cumplimiento de los requisitos de seguridad a medida que crecía una empresa. ¿Qué le llevó a creer que este era un problema que merecía la creación de una empresa completamente nueva, y cómo ha evolucionado la misión de Drata a medida que la IA ha transformado el panorama de la seguridad?

Mientras dirigíamos Portfolium junto con mis cofundadores, Troy Markowitz y Daniel Marashlian, aprendimos una valiosa lección: ganarse la confianza en los negocios es un proceso, no un discurso de venta. Dado el gran volumen y la sensibilidad de la información estudiantil, las universidades y las empresas no se asociaban con nosotros hasta que demostrábamos que hacíamos lo necesario para proteger sus datos. Nos dimos cuenta de que la lenta y ardua tarea de completar manualmente cada cuestionario de seguridad, auditoría y revisión de cumplimiento era una experiencia común. Tras la adquisición de Portfolium, Troy, Daniel y yo volvimos a reunirnos y dedicamos seis meses a crear la primera versión de Drata. Hablamos con decenas de empresas y auditores para validar el problema antes siquiera de empezar a escribir código. Cuando lanzamos el producto, alcanzamos los 100 clientes en las primeras seis semanas y los 1.000 en el plazo de un año, lo que nos indicó que habíamos pasado de vender algo «deseable» a ofrecer algo sin lo que la gente no podía operar.

Con la IA, la misión de Drata de ofrecer confianza continua no ha cambiado, pero el alcance de esa confianza se ha ampliado. Empezamos por automatizar el arduo trabajo de cumplimiento y luego avanzamos hacia flujos de trabajo agénticos capaces de realizar evaluaciones de riesgos de terceros y completar cuestionarios de seguridad de principio a fin. Pero el verdadero cambio llegó cuando los propios agentes se convirtieron en aquello que había que gobernar. Ahora hemos ampliado la plataforma para permitir la gobernanza de agentes de IA: detectar los agentes, gobernar lo que tienen permitido hacer y generar evidencias sólidas cuando alguien las solicite.

Ha acuñado el término «amenaza interna de agentes» para describir los riesgos creados no por un atacante externo, sino por los propios agentes de IA de una organización. ¿Qué distingue una amenaza interna de agentes de las amenazas internas tradicionales para las que los equipos de seguridad llevan décadas preparándose?

Las amenazas internas tradicionales consisten en que una persona haga un uso indebido de los accesos que ya tiene, como un empleado descontento, uno descuidado o alguien que simplemente hace clic donde no debe. Los equipos de seguridad llevan décadas creando programas para afrontar ese riesgo, centrados en verificaciones de antecedentes, el principio de mínimo privilegio, listas de control para retirar accesos al finalizar una relación laboral y medidas similares.

La amenaza interna de agentes es distinta porque, en primer lugar, nunca se concedió acceso al agente. El riesgo pasa del uso indebido a la obtención de acceso. Si se le asigna un objetivo y se bloquea la vía más directa para alcanzarlo, no se limita a abrir un ticket y esperar, como haría una persona. Intenta encontrar otra ruta: una cuenta de servicio con una contraseña débil o un punto de conexión que nadie recordó cerrar. Consigue entrar sin malicia ni ser consciente de que infringe una política. Hace exactamente lo que se le pidió, y eso es lo que dificulta tanto detectarlo. Cada paso parece razonable por sí solo y, al final, el agente informa de que ha tenido éxito.

Ya sabemos cómo gobernar a empleados y terceros con acceso a sistemas sensibles, pero los agentes constituyen un tercer grupo, al que no llegan las herramientas creadas para los dos primeros.

Los agentes de IA pueden perseguir objetivos de forma persistente, operar a velocidad de máquina e interactuar con múltiples sistemas sin el criterio que podría aplicar un empleado humano. ¿Hasta qué punto cambia esto el modelo de amenazas empresariales?

Más que nada, cambia los plazos. Una persona que busca la manera de entrar en un sistema acaba aburriéndose, la descubren o se da por vencida. Un agente, no. Ahora se detecta una puerta abierta que antes nadie había encontrado, porque el agente no se cansa ni deja de buscar.

Y no se trata de una sola puerta. Un agente diseñado para realizar una tarea puede interactuar sin problema con una docena de sistemas para completarla: consultar el historial de una cuenta aquí, revisar una base de datos allá. La mayor parte de esas acciones no tiene nada que ver con lo que realmente se le pidió. Mientras prepara una presentación, puede acceder a datos de otro cliente, registros financieros, información de empleados o cualquier otra cosa que encuentre en el camino. Nada de eso aparece como un incidente.

Por eso ha cambiado el modelo de amenazas. Hoy, la pregunta que debería hacerse un equipo de seguridad es hasta dónde llegarán sus propios agentes para completar una tarea si nadie les ha indicado dónde detenerse.

Muchas organizaciones ya cuentan con sistemas de gestión de identidades y accesos, de gestión de accesos privilegiados y con arquitecturas de confianza cero. ¿Por qué esos controles no bastan por sí solos para gobernar agentes de IA autónomos?

Esos marcos se diseñaron para personas y proveedores: dos grupos capaces de ejercer criterio y que se detienen cuando encuentran un obstáculo. La identidad de los agentes requiere el mismo rigor que se aplica a las personas y al riesgo de terceros: identificación, asignación de responsables y pruebas que un auditor pueda aceptar. La carencia es que aún no existe un criterio común sobre lo que significa realmente estar «gobernado» cuando quien posee la credencial es un agente.

Por ejemplo, un agente creado por uno de sus ingenieros puede actuar con los permisos de acceso de esa persona, incluso en sistemas que nunca utiliza personalmente. Los sistemas de gestión de identidades y accesos y de gestión de accesos privilegiados presuponen que quien posee la credencial sabe cuándo detenerse, pero los agentes no incorporan ese supuesto.

¿Deberían las empresas empezar a tratar cada agente de IA como una identidad de máquina independiente, con un responsable, permisos, alcance y ciclo de vida claramente definidos? ¿Cómo sería un marco de identidad maduro para los agentes?

Sí, pero la mayoría de las empresas aún no ha llegado a ese punto. Más empresas de las que cabría esperar ni siquiera saben cuántos agentes operan dentro de sus organizaciones, y mucho menos quién es responsable de cada uno. Un marco maduro empieza por identificarlos y elaborar un inventario real y continuo de todos los agentes. A partir de ahí, cada agente necesita un responsable, un alcance definido que especifique a qué puede acceder y una política que haga cumplir ese alcance. Nuestra propia investigación revela el mismo problema con los proveedores: tres de cada cuatro organizaciones solo vuelven a evaluar a sus terceros una vez al año o con menor frecuencia, por lo que toman decisiones de gobernanza basadas en datos que ya están desactualizados cuando se produce cualquier cambio. Las evaluaciones puntuales no sirven para los agentes, ni internos ni externos

Queremos un único estándar que se aplique por igual a todos los agentes, en lugar de que el equipo de seguridad tenga que averiguar qué ha creado cada desarrollador por su cuenta. Eso significa poder redactar políticas en lenguaje sencillo, probarlas con tráfico histórico real antes de activarlas y, después, hacerlas cumplir en línea, de modo que el marco intervenga en la ruta de cada acción del agente y no se limite a quedar documentado.

Un escenario especialmente difícil es el de un agente que infringe las políticas de seguridad sin actuar de forma maliciosa. Si un agente descubre una vía no prevista para acceder a datos confidenciales simplemente porque intenta completar la tarea que se le ha asignado, ¿cómo pueden los equipos de seguridad distinguir entre una automatización exitosa y un incidente de seguridad?

Por ahora, la respuesta sincera es que no se puede. Imaginemos un agente de atención al cliente diseñado para redactar revisiones trimestrales del negocio, al que se le pide consultar el historial de una cuenta y preparar la presentación. La vía prevista —la exportación de la que debería obtener los datos— no devuelve nada. Una persona se detendría ahí, pero el agente encuentra otra vía y, desde su perspectiva, logra completar la tarea.

Aunque la tarea se completó, el agente lo consiguió eludiendo los protocolos de seguridad y accediendo a sistemas que no debía abrir. La pregunta clave debe ser si se mantuvo dentro del alcance que le habíamos asignado. Nunca se trató de si completó la tarea. Se trata de una cuestión de políticas. Significa definir el alcance con suficiente precisión para que, a posteriori, la «automatización exitosa» y el «incidente de seguridad» no parezcan lo mismo.

La supervisión de seguridad tradicional suele detectar actividades sospechosas después de que se producen, pero un agente autónomo puede completar cientos de acciones antes de que una persona responda. ¿La IA agéntica requiere controles de seguridad que actúen directamente en la ruta de ejecución, en lugar de depender principalmente de alertas y de la supervisión retrospectiva?

Sí, sin duda. Si lo detecta en tiempo de ejecución, ya es demasiado tarde. Cuando una herramienta de supervisión señala la acción, esta ya se ha ejecutado. Tendrá un registro perfecto de cómo quedó expuesto, pero no podrá dar marcha atrás para detenerla.

La única forma de gobernanza que funciona con algo que opera a velocidad de máquina es evaluar la acción antes de que se ejecute y bloquear la infracción en línea. Nunca entregaríamos nuestros datos más confidenciales a una persona recién contratada con la esperanza de que la supervisión detectara cualquier problema. Los agentes merecen esa misma disciplina, justo cuando la acción está a punto de producirse. No después.

El Model Context Protocol (MCP) y otras interfaces entre agentes y herramientas están dando a los sistemas de IA acceso a capacidades externas cada vez más potentes. ¿Qué nuevos límites de seguridad deben establecerse para las llamadas a herramientas, las API, las credenciales y las cuentas de servicio a medida que las empresas amplían las acciones que permiten realizar a sus agentes?

La llamada a una herramienta es el nuevo perímetro de seguridad. Cada vez que un agente recurre a una credencial, llama a una API o invoca una herramienta, se abre un punto de decisión, y hoy la mayoría de las empresas no tiene ningún control situado justo en ese punto que evalúe si debe llevarse a cabo la acción. Eso es lo que ha faltado. Desde fuera, vemos el mismo punto ciego: solo el 37 % de los responsables de seguridad confía en que siquiera puede identificar dónde se ejecuta la IA dentro de los proveedores con los que ya trabaja. Si no puedes verla en el producto de un proveedor, tampoco verás el siguiente movimiento de tu propio agente. Las credenciales y las cuentas de servicio que sustentan todo esto también requieren el mismo rigor que aplicamos al acceso humano: titularidad conocida, alcance definido y revisiones periódicas. Un agente no debería poder recurrir a una credencial que nunca se le concedió solo porque esa credencial existía en algún punto de su recorrido.

Cuando un auditor, un regulador o un cliente pregunta a qué accedió un agente de IA, qué decisiones tomó y adónde fueron los datos resultantes, ¿qué nivel de trazabilidad deberían poder ofrecer las organizaciones de forma realista? ¿Podrían los registros de auditoría de los agentes llegar a ser tan esenciales como los registros de acceso tradicionales?

Las organizaciones deberían poder responder en cualquier momento a qué accedió un agente, qué decisiones tomó y adónde fueron los datos resultantes. No basta con reconstruir la respuesta después, reuniendo información de los registros. El estándar debe ser un registro continuo y a prueba de manipulaciones que ya exista cuando se formule la pregunta. Hoy, la mayoría de las empresas no tiene respuesta a estas preguntas. No es una carencia que puedas justificar ante un cliente y, dependiendo de lo que se haya filtrado, tampoco es algo que los reguladores vayan a aceptar.

Y sí, creo que los registros de auditoría de los agentes pronto serán tan esenciales como los registros de acceso. Desde hace años, consideramos innegociable registrar «quién accedió a qué y cuándo» en los sistemas humanos. No hay motivo para exigirles menos a los agentes solo porque no haya sido una persona quien hizo clic. Marcos como la Ley de IA de la UE, AIUC-11 e ISO 42001 ya están impulsando esa tendencia. La trazabilidad de los agentes debe ajustarse a los mismos controles y criterios probatorios que ya sustentan los programas de cumplimiento. Tratarla como algo secundario es la forma de relegarla.

De cara al futuro, ¿crees que la gobernanza de los agentes de IA se convertirá en una categoría de seguridad independiente o acabará integrándose en las plataformas existentes de gobernanza, riesgo, cumplimiento, identidad y ciberseguridad? ¿Qué deberán tener preparado las empresas para poder implementar de forma segura agentes verdaderamente autónomos a gran escala?

Cada gran ola tecnológica genera su propia ola de seguridad: la nube dio origen a Wiz y los dispositivos finales, a CrowdStrike. Ahora, los agentes de IA están generando una propia. Los proveedores de modelos están creando consolas y políticas para sus plataformas, lo cual resulta útil, pero ninguna empresa funciona con un único proveedor de modelos, un único asistente de programación y un único conjunto de agentes desarrollados internamente. Alguien tiene que gobernar todo eso con un único conjunto de políticas y una única fuente de evidencia, y ninguna plataforma de IA por sí sola está diseñada para resolver ese problema. No es para eso que existe. La gobernanza de los agentes de IA ya es una categoría propia, aunque se integre con los sistemas de GRC, identidad y cumplimiento que las empresas ya utilizan.

Antes de implementar agentes verdaderamente autónomos a gran escala, las empresas deben tener preparadas cuatro cosas, y la mayoría todavía no tiene ninguna. La primera es la detección en tiempo real: saber qué agentes están en ejecución, quién es responsable de cada uno y con qué identidad opera, desde el momento en que se crea.

La siguiente es la aplicación de políticas en línea, evaluadas antes de que se ejecute una acción. En tercer lugar, las empresas necesitan supervisión continua para detectar desviaciones, ya que los agentes siguen activos después de que termina la sesión en la que se crearon y su alcance puede ampliarse sin que nadie lo advierta. Por último, se necesita un registro a prueba de manipulaciones de cada decisión que tome un agente, vinculado a los marcos que los auditores y reguladores realmente reconocen. Esa es la capa que estamos desarrollando en Drata. Sin ella, una empresa que implemente agentes autónomos a gran escala solo está confiando en que todo salga bien.

Gracias por esta excelente entrevista. Los lectores que quieran conocer más sobre la gobernanza de los agentes de IA, el cumplimiento continuo y los controles frente a las amenazas internas relacionadas con agentes pueden visitar Drata.