Durante años, los líderes de ciberseguridad se han preocupado por las contraseñas robadas.
Ahora considere un escenario diferente.
Un atacante descubre una aplicación de IA orientada a Internet. Un defecto de software ha desactivado inadvertidamente la autenticación que lo protege. El atacante entra, instruye a un agente de IA que se ejecuta en el servidor para revelar una clave API, y luego utiliza esa clave durante tres semanas.
¿ Cuál fue el resultado?
Aproximadamente $600,000 en créditos no autorizados modelo de IA consumidos.
Eso es lo que pasó con la evaluación de IA sin fines de lucro Metr, según un informe reciente de DataBreachToday.
Afortunadamente para Metr, el desarrollador del modelo había proporcionado esos créditos sin costo, por lo que la organización no fue presentada con un proyecto de ley de $600,000. Metr también dijo que su investigación no encontró evidencia de que el atacante obtuviera nada más allá de una clave API proporcionando acceso a modelos disponibles públicamente.
Pero creo que enfocarse sólo en la cantidad de dólares pierde la historia más importante.
Una llave API ya no es solo un secreto.
En una empresa impulsada por la IA, las credenciales representan cada vez más autoridad, capacidad y poder económico.
Y eso significa que tenemos que empezar a tratar la identidad de la máquina con la misma seriedad que hemos reservado históricamente a la identidad humana.
El ataque no comenzó Con Algo de técnica de IA exótica
Uno de los aspectos más interesantes de este incidente es lo ordinario que fue su comienzo.
Según Metr, un investigador estaba ejecutando agentes de IA en un servidor de nube personal. Una aplicación en ese servidor era accesible desde Internet y se suponía que requería la autenticación de Google.
Pero un defecto de software de autenticación desactivada.
La aplicación había sido construida usando "codificación de vibraciones" asistida por IA y permaneció expuesta a Internet pública durante varios días. Metr sospecha que un atacante pudo haberla descubierto mientras buscaba en sitios web recientemente registrados relacionados con IA credenciales de proveedores de modelos expuestos.
Una vez dentro, el atacante habría dado instrucciones a un agente de inteligencia artificial que corría en el servidor para que revelara la llave API de Metr. El atacante también instaló una llave SSH para mantener el acceso.
Hay algo casi irónico en esa secuencia.
Una aplicación de IA ayudó a crear el entorno.
Un fallo de autenticación abrió la puerta.
Se pidió a un agente de inteligencia artificial que revelara la credencial.
Y la credencial de la máquina robada proporcionó la capacidad económica.
Esto no fue simplemente un ataque de IA.
Era un Fallo de confianza que ocurre dentro de un entorno de IA.
Y creo que veremos muchas más variaciones de este problema.
Tenemos que dejar de pensar en la identidad exclusivamente humana
Cuando la mayoría de los ejecutivos oyen "seguridad de identidad", ellos todavía piensan naturalmente en la gente.
Empleados.
Clientes.
Administradores.
Contratistas.
Usuarios privilegiados.
Pero la población de identidad empresarial está cambiando rápidamente.
Las aplicaciones tienen identidades.
Las API tienen credenciales.
Las cuentas de servicio tienen privilegios.
Las cargas de trabajo se autentican con otras cargas de trabajo.
Los agentes de IA interactúan cada vez más con aplicaciones, bases de datos, servicios en la nube y otros agentes.
Y a diferencia de un empleado humano que finalmente se va a casa por la noche, las identidades de las máquinas pueden funcionar continuamente y a una velocidad extraordinaria.
Eso cambia las posibles consecuencias de la confianza extraviada.
Una cuenta de empleado comprometida podría permitir que un atacante realice cualquier acción que el empleado esté autorizado a realizar.
Una credencial de máquina comprometida puede permitir potencialmente que los sistemas automatizados realicen acciones autorizadas miles o millones de veces.
El problema de identidad no ha desaparecido.
Se ha convertido en la velocidad de la máquina.
La autenticación es sólo el comienzo
Hay otra lección aquí que creo que es particularmente importante.
A menudo hablamos de autenticación como si la autenticación exitosa completara la decisión de seguridad.
No lo hace.
Respuestas de autenticación:
¿Quién eres?
Respuestas de autorización:
¿Qué se le permite hacer?
Pero en un entorno de IA, cada vez necesitamos más preguntas adicionales:
¿Qué recurso está solicitando acceso?
¿Con qué servicio se comunica?
¿Qué autoridad se le ha delegado?
¿Cuál es el propósito de la solicitud?
¿Cuánto tiempo debería existir esa autoridad?
¿Cuánto puede consumir?
¿Y en qué momento debería un ser humano aprobar lo que sucede después?
Esta última pregunta va a ser especialmente importante.
La IA expande dramáticamente lo que el software puede hacer de forma autónoma.
Por consiguiente, la seguridad tiene que ser mucho más deliberada sobre ¿Qué software debe ser permitido hacer de forma autónoma.
$600,000 es una historia de autorización
Considere la llave API robada en sí.
Una vez que el atacante lo poseyó, la clave aparentemente proporcionó suficiente autoridad para consumir aproximadamente $600,000 por valor de créditos modelo durante tres semanas.
¿Por qué esa actividad no se detuvo inmediatamente?
Metr explicó que sus evaluaciones normalmente consumen un gran número de tokens y generan rutinariamente errores de límite de tasa y API. Su monitoreo tampoco mostró todas las solicitudes rechazadas. Y como los créditos modelo se habían proporcionado de forma gratuita, no había límite de gasto para activar una alerta o detener la actividad.
Eso es fascinante desde una perspectiva de seguridad.
La actividad podría ocultar, al menos temporalmente, un comportamiento interno que no era necesariamente inusual para el medio ambiente.
La credencial era utilizable.
El servicio lo aceptó.
El consumo continuó.
Lo que lleva a una pregunta incómoda:
¿Debe la posesión de una credencial de máquina válida conferir automáticamente todo lo que la credencial es técnicamente capaz de hacer?
En un entorno cada vez más autónomo, no creo que la respuesta pueda ser siempre sí.
El menos privilegio está a punto de volverse mucho más importante
La respuesta de Metr es instructiva.
Después de los incidentes, la organización dijo que formalizó revisiones de seguridad para investigadores que colocaban aplicaciones en la Internet pública y añadió alertas de gasto a las claves API.
También aisló las aplicaciones orientadas al público de los sistemas internos, amplió el registro y la supervisión, acorta la vida útil de las credenciales, redujo los permisos, contrató una ventaja de seguridad y cerró la infraestructura heredada que aumentó su superficie de ataque.
Esas no son solo medidas de limpieza.
Señalan hacia las empresas de arquitectura que cada vez más necesita a medida que la adopción de IA se acelera:
Las credenciales de corta duración.
Permisos con alcance.
Aislamiento.
Seguimiento continuo.
Límites de uso.
Autorización consciente del contexto.
La aprobación humana de las acciones consecuentes.
En otras palabras:
Dar a las máquinas suficiente autoridad para cumplir la tarea, no suficiente autoridad para convertirse en el incidente.
Agentes de IA nos obligarán a separar la identidad Desde Autoridad
Aquí es donde creo que la conversación de IA se vuelve particularmente interesante.
Supongamos que un empleado autoriza a un agente de inteligencia artificial a realizar una tarea.
Eso crea varias identidades y relaciones de confianza simultáneamente.
Ahí está el humano.
Ahí está el agente.
Existe el servicio al que el agente está intentando acceder.
Ahí está la credencial que se está usando.
Existe la autoridad delegada por el ser humano u organización.
Y está la acción que el agente en última instancia quiere realizar.
Esas cosas no pueden simplemente colapsar en:
"La credencial es válida, por lo tanto proceda."
La credencial podría ser válida mientras el contexto esté equivocado.
El agente puede ser legítimo mientras que la acción solicitada es inadecuada.
El humano podría ser autorizado mientras que el agente se ha concedido privilegios excesivos.
El destino puede ser auténtico, mientras que la cantidad que se gasta es anormal.
O, como Metr experimentó, una credencial legítima podría simplemente haber caído en manos de otra persona.
La identidad nos dice quién o qué está actuando. La confianza determina si debemos permitir lo que sucede después.
Esto es más grande que la gestión de API-Key
Sería fácil leer este incidente y concluir que las organizaciones simplemente necesitan proteger mejor las claves API.
Lo hacen.
Pero creo que la interpretación es demasiado estrecha.
Este incidente apunta hacia una transición mucho más grande que tiene lugar en toda la seguridad de la empresa.
Nos estamos moviendo de un ambiente dominado por identidades humanas utilizando aplicaciones hacia uno poblado por humanos, aplicaciones, APIs, cargas de trabajo y agentes autónomos actuando en nombre de los demás.
Eso significa que nuestro modelo de confianza tiene que evolucionar con ellos.
En Identité®, hemos estado argumentando que la confianza digital moderna necesita responder más que una sola pregunta en el inicio de sesión.
Cada vez es más necesario considerar:
Identidad + Autenticación + Destino + Intención + Contexto + Autorización
Full Duplex Authentication® es parte de esa filosofía más amplia porque la confianza no debe fluir simplemente en una dirección. La parte que solicita la autenticación también importa.
Pero AI extiende el desafío aún más.
Cuando las máquinas empiezan a actuar para nosotros, también tenemos que establecer quién autorizó la máquina, qué autoridad se delegó, dónde se puede ejercer esa autoridad, cuánto tiempo debe existir y cuándo un ser humano necesita volver a la decisión.
Eso no es simplemente una autenticación más fuerte.
Esa es una arquitectura diferente para la confianza.
La IA más peligrosa puede ser la IA que autorizamos
Las discusiones sobre la ciberseguridad acerca de la inteligencia artificial se centran comprensiblemente en lo que harán los atacantes con IA.
Mejor phishing.
Un reconocimiento más rápido.
Descubrimiento automatizado de vulnerabilidad.
Una imitación más convincente.
Esas amenazas son reales.
Pero hay otro problema de seguridad de IA que se desarrolla dentro de nuestras propias organizaciones.
Estamos dando rápidamente credenciales, acceso y autoridad a las máquinas porque hacerlo crea una enorme productividad.
Y deberíamos.
El objetivo no debe ser impedir que los agentes de IA actúen.
Debe ser para asegurarse de que su autoridad es proporcional a la tarea, limitada en duración y difícil de heredar o robar.
Porque la siguiente clave API comprometida podría no proporcionar acceso a $600,000 en créditos de modelo gratis.
Podría autorizar transacciones financieras.
Acceda a los registros de clientes.
Modificar los sistemas de producción.
Mueva los datos sensibles.
Activar flujos de trabajo.
O indíquele a otro agente de inteligencia artificial que actúe.
Las consecuencias económicas del compromiso de la identidad automática no se determinarán simplemente por si el atacante obtiene una credencial.
Ellos serán determinados por cuánta autoridad le hemos dado.
La pregunta que los líderes de seguridad deben estar pidiendo
El incidente del Metr nos da una visión útil de un futuro que llega más rápido de lo que muchas organizaciones se dan cuenta.
La cuestión de la seguridad ya no es simplemente:
"¿Cómo autentificar a nuestra gente?"
Se está convirtiendo en:
"¿Cómo establecemos y gobiernamos la confianza entre las personas, las máquinas y los agentes autónomos?"
Eso requiere que pensemos de manera diferente sobre la autenticación, autorización, intención, contexto, privilegio e identidad en sí.
Porque en una empresa impulsada por IA, una credencial puede ya no simplemente desbloquear una cuenta.
Puede desbloquear capacidad.
Y cuando la capacidad puede funcionar de forma autónoma, continua y a velocidad de la máquina, las consecuencias de confiar en la identidad equivocada pueden escalarse con la misma rapidez.
Cuanto más autoridad damos a las máquinas, más deliberadamente debemos controlar a quién, o qué, se le permite ejercerla.
Los atacantes no tienen que derrotar todos los controles de seguridad.
Sólo tienen que convertirse en alguien, o algo, esos controles se han enseñado a confiar.
Y en la era de AI, "algo" puede convertirse en la palabra más importante en esa oración.