Cómo crear un control de acceso basado en la intención sin leer la mente

En «Minority Report», el Departamento de Precrimen prometía certeza. Tres precognitivos veían el futuro, el sistema elegía el consenso y la policía detenía a personas por asesinatos que aún no habían cometido. Todo el sistema se basaba en un secreto oculto: a veces los precognitivos no se ponían de acuerdo, y el sistema eliminaba discretamente la visión discrepante, el «informe minoritario». El sistema se mantenía en pie mientras los precognitivos estuvieran de acuerdo, pero se derrumbaba cuando eliminaba su propia duda.

Una nueva ola de productos de seguridad busca alcanzar esa misma capacidad. El argumento es más o menos así: instala un pequeño modelo de IA en cada portátil, deja que observe lo que hace la gente en sus apps, navegadores y herramientas de IA, igual que lo haría un compañero sentado a su espalda, que entienda lo que cada persona está intentando hacer, que determine si sus intenciones son maliciosas y que intervenga antes de que se produzca el daño. Esa misma supervisión mantiene un registro completo del trabajo, de modo que un analista puede leer lo que ha pasado en lugar de reconstruirlo a partir de registros dispersos. La persona podría ser un empleado pegando datos confidenciales en un asistente de IA no autorizado, alguien de fuera que ha iniciado sesión con credenciales robadas o alguien que sigue las instrucciones de un estafador para ceder el control remoto de su portátil. La parte de la vigilancia ahora es sencilla con los modelos locales. La cuestión de diseño es qué debe hacer un sistema con una inferencia sobre la intención que no siempre será correcta.

Si dejamos de lado la arquitectura, la propuesta hace tres promesas: detectar una acción de riesgo a tiempo para detenerla, distinguirla del trabajo habitual sin abrumar a los analistas con alertas y hacer que cualquier cosa que se marque sea fácil de investigar rápidamente. Hoy en día se puede crear un control de acceso útil basado en la intención combinando la inferencia contextual con políticas explícitas y su aplicación en acciones sensibles. La investigación respalda la reconstrucción de lo ocurrido a posteriori, la evaluación de en qué medida una acción encaja con el trabajo de una persona y la introducción de obstáculos en el momento del riesgo. Reconocer el objetivo inmediato de alguien mientras aún lo persigue es menos claro, y separar de forma fiable los motivos maliciosos de los benignos en el trabajo cotidiano supone un reto. Por eso, los sistemas que funcionan prueban algo más concreto: en qué medida una acción encaja con el trabajo de la persona, lo inusual que resulta para ella o con qué objetivo de una lista reducida coincide. Cada prueba equilibra las falsas alarmas y los fallos de detección de forma diferente, y cada una deja un hueco en el que un imitador puede esconderse, por lo que el diseño en torno a la prueba importa tanto como la propia prueba. Empezaremos por lo que un modelo local puede leer en la pantalla, pasaremos por las pruebas de más a menos concretas, analizaremos el caso en el que la intención pertenece a otra persona y terminaremos con cómo se combinan las pruebas en el control de acceso.

Lo que un modelo local puede leer en la pantalla

Reconstruir lo que alguien hizo en su pantalla ya funciona sorprendentemente bien. Cohen et al. dividieron la tarea en dos. Primero, un modelo pequeño resume cada paso de una trayectoria corta en la interfaz de usuario, usando capturas de pantalla y registros de acciones para capturar lo que había en pantalla y lo que hizo el usuario; y, a continuación, un segundo modelo ajustado deduce el objetivo a partir de esos resúmenes. Con Gemini Flash 8B como modelo pequeño, ese enfoque desglosado dedujo el objetivo del usuario casi tan bien como Gemini 1.5 Pro, un modelo que cuesta más de 30 veces más por token. El método de inducción de tareas de Jiang et al. se encarga de un paso anterior: clasifica registros de uso informático entremezclados para reorganizarlos según sus tareas originales, logrando una precisión casi perfecta.

Ambos resultados son retrospectivos. Cada uno determina su respuesta tras la última interacción, lo que resulta adecuado para la respuesta tras un incidente, pero no establece con qué fiabilidad se puede identificar un objetivo mientras alguien todavía lo está persiguiendo.

Tanto los proveedores de soluciones para terminales ya consolidados como los productos más nuevos se basan en modelos pequeños y especializados que toman decisiones en tiempo real, en algunos casos directamente en el dispositivo. Muchos se basan principalmente en eventos estructurados, como copias al portapapeles, acceso a archivos, contenido del navegador, linaje de datos y un patrón de referencia del trabajo habitual de cada persona. Algunos toman capturas de pantalla en torno a un incidente como prueba, en lugar de interpretar la pantalla de forma continua, y esa es una opción razonable: las pruebas que permiten comprobar rápidamente una alerta reducen el coste de cada falsa alarma. Los inicios de sesión, el acceso a archivos, la apertura de procesos y los eventos de pago ya vienen etiquetados, así que queda poco que resumir, y ninguno de los estudios analizados aquí mide el valor añadido en materia de seguridad que supone leer la pantalla además de esos flujos de eventos.

El problema más complicado es deducir el objetivo a mitad de la sesión solo a partir de las pruebas disponibles hasta ese momento. GUIDE, un benchmark de CVPR 2026 creado a partir de 67,5 horas de usuarios novatos trabajando en aplicaciones como Photoshop y Excel, dio un primer paso. Recortó clips de unos 25 segundos de media al 25 %, 50 % y 75 %, y pidió a los modelos que eligieran el objetivo inmediato del usuario entre cuatro opciones. Con solo una cuarta parte del clip, el mejor modelo de este experimento con clips parciales acertó aproximadamente la mitad de las veces, porcentaje que subió a unos dos tercios con el clip completo, donde adivinar al azar da un 25 %. Incluso con la tarea general y los posibles objetivos inmediatos proporcionados, los modelos solían elegir el objetivo equivocado. Los investigadores usaron las explicaciones verbales de los usuarios para determinar las respuestas, pero no pudieron deducir algunas intenciones solo a partir de la pantalla.

Ni siquiera una descripción perfecta e instantánea lo aclara todo por sí sola. «Copiar la lista de clientes en un borrador de correo electrónico personal» encaja tanto con un comercial que termina su trabajo en casa como con uno que se va a la competencia. Para actuar, un sistema tiene que determinar si se trata de uno de los innumerables objetivos inofensivos o de un ejemplo de una intención maliciosa poco común.

La adecuación al puesto como indicador principal

La prueba más concreta consiste en ver si una acción encaja en su contexto. El sistema Facade de Google, que lleva desde 2018 supervisando el acceso de los empleados a documentos, bases de datos y servicios internos, se ha entrenado con actividad histórica sin etiquetar en lugar de con ataques conocidos, y puntúa cada acceso según lo bien que coincida con lo que el sistema sabe sobre la persona y el recurso, como su puesto, su equipo y su trabajo reciente. No es necesario definir una lista de objetivos preestablecidos; según sus creadores, el sistema presenta una tasa de falsos positivos, a nivel de evento, inferior al 0,01 % en sus evaluaciones.

Una cola de revisión pequeña conlleva una capacidad de detección limitada. En un ejercicio de «equipo rojo», los empleados de Google pasaron dos semanas intentando acceder a datos confidenciales ajenos a su trabajo habitual utilizando sus propias credenciales. En un proceso de revisión diario simulado, Facade detectó entre tres y cuatro de los 15 atacantes en cinco modelos entrenados, con un presupuesto de diez auditorías al día, un coste que sus autores califican de notablemente bajo para una empresa con más de 100 000 empleados.

Sus autores son claros sobre el punto ciego. Facade no puede detectar acciones maliciosas que sean indistinguibles del trabajo cotidiano, lo que lo hace inadecuado para pillar a un empleado deshonesto leyendo archivos relevantes para su trabajo.

Las desviaciones requieren un presupuesto de revisión

La mayoría de las investigaciones sobre amenazas internas siguen un enfoque menos concreto: aprender el comportamiento normal de cada persona y señalar lo que se desvía de él. Sin embargo, las implementaciones reales muestran cuántas desviaciones normales hay. Cuando Erola y sus colaboradores probaron una herramienta de amenazas internas en tres empresas multinacionales, unas configuraciones deliberadamente amplias generaron unas 356 alertas anómalas al día en una organización y 3.713 en otra. El equipo detectó un escenario simulado de amenaza interna, pero no pudo determinar qué parte del comportamiento marcado como anómalo era realmente malicioso. Los autores descubrieron que el comportamiento real se desvía mucho más que los datos sintéticos en los que se basan la mayoría de las investigaciones.

Los benchmarks sintéticos arrojan resultados halagadores. Una revisión de 131 estudios basados en los conjuntos de datos de amenazas internas del CERT reveló que casi la mitad utiliza una versión que incluye 70 usuarios maliciosos de un total de 1000; además, pocos estudios especifican cuántas alertas tendría que revisar un analista para identificar a dichos usuarios.

Los sistemas de detección de movimientos laterales siguen el mismo patrón. Cuando Larroche volvió a ejecutar las herramientas Euler y Argus, incluyendo todos los inicios de sesión remotos registrados durante el periodo de prueba en el Laboratorio Nacional de Los Álamos, ambas mantuvieron un valor AUC de aproximadamente el 98 % (una métrica que indica con qué frecuencia un ataque aleatorio obtiene una puntuación superior a la de un inicio de sesión legítimo elegido al azar). No obstante, al considerar solo unos dos eventos maliciosos etiquetados por cada millón de registros, la precisión promedio cayó por debajo del 0,1 % en ambos casos; una cifra muy alejada del 5 % y el 32 % reportados originalmente en conjuntos de datos que habían sido sometidos a un filtrado mucho más riguroso.

Los atacantes también pueden manipular la desviación. Goyal et al. complementaron los ataques con actividad normal extraída del sistema objetivo y registraron un 100 % de evasión frente a cinco detectores en sus principales experimentos con conjuntos de datos públicos, sin cambiar la carga maliciosa.

Objetivos específicos para casos conocidos

Los métodos de reconocimiento de objetivos basados en un conjunto predefinido de opciones clasifican metas que ya han sido establecidas previamente; sin embargo, no abordan el desafío de generar dicho catálogo para una sesión de trabajo abierta, en la que el usuario podría estar realizando cualquier tarea, desde editar un informe trimestral hasta extraer una base de datos. Los productos comerciales eluden este problema reduciendo el menú a unas pocas etiquetas de riesgo o categorías de políticas. Los sistemas de lectura de pantalla, como el de Cohen, se saltan el menú expresando la intención con sus propias palabras, lo que plantea un problema diferente. Una herramienta de seguridad tendría que decidir de todos modos si una suposición en texto libre como «exportar la lista de clientes» es maliciosa.

Un desvío puede significar un objetivo oculto, o alguien que está perdido, con prisa o intentando una solución que no ha funcionado. Distinguir entre ambas cosas empieza por detectar la confusión, y los modelos de visión actuales a menudo no lo hacen. En las grabaciones de pantalla de GUIDE con usuarios novatos reales, la matriz de confusión generada solo clasificó correctamente el 7 % de los fragmentos de frustración y el 4 % de los de depuración. El sistema etiquetó la mayoría de esos momentos como trabajo seguro o exploración deliberada, e interpretó los clics repetidos, las acciones de deshacer y las vacilaciones como un progreso intencionado. Una herramienta de seguridad que interprete las dificultades como algo intencionado podría ver más intención en un desvío de la que realmente hay.

Algunos productos van un paso más allá y asignan categorías de amenaza: malintencionado, descuidado o comprometido. La promesa es una respuesta proporcional: orientación para el empleado descuidado e investigación para el malintencionado, pero esas etiquetas mezclan la intención, el comportamiento y quién controla la cuenta. Distinguir los motivos malintencionados de los benignos es más difícil que reconocer el objetivo inmediato, y es posible que las pruebas que lo aclararan no estén en los endpoints cuando ocurre la acción. Facade evita deliberadamente estas etiquetas. Su modelo de amenazas trata como un mismo caso tanto a un empleado deshonesto como a uno cuyas credenciales robadas está utilizando otra persona, porque ambas situaciones parecen inusuales para esa persona.

Los detectores de objetivos específicos convierten los motivos y los factores de riesgo en historias. Una revisión reciente sobre la psicología de las amenazas internas analiza la presión financiera, las quejas laborales y la ideología, junto con una categoría aparte de daños accidentales o por negligencia. En el programa de amenazas internas de DARPA, Senator et al. crearon un detector para cada uno de estos casos, incluyendo el saboteador, el estafador, el usuario descuidado y el empleado que se lleva propiedad intelectual, y los aplicaron durante dos meses de actividad informática supervisada de unos 5500 empleados, con escenarios del «equipo rojo» insertados en los registros de usuarios reales. El mejor de ellos, diseñado para el líder de un pequeño grupo que roba propiedad intelectual, incluyó 6 días-usuario del «equipo rojo» en su top 50 de octubre, pero en septiembre ignoró 33 de los 98 días-usuario del «equipo rojo» porque no encajaban en el escenario. Un objetivo concreto supone apostar a que el atacante seguirá un guion escrito de antemano. El sistema puede pasar por alto el comportamiento que se sale de ese guion, y un atacante adaptable tiene motivos para aprovechar esa brecha. Este estudio no analizó esa evasión deliberada.

Fricción cuando la intención es de otra persona

A veces, la intención ni siquiera es de la persona que está delante del teclado. Un estafador puede instruir por teléfono a un cliente, que inicia sesión desde su propio dispositivo, supera la autenticación y autoriza el pago él mismo, sin dejar los indicios habituales de una apropiación de cuenta. El estudio teórico de Dhama formaliza un caso límite: si los pagos fraudulentos y los legítimos tienen distribuciones de características observables idénticas, un detector basado solo en las transacciones no puede distinguirlos. El artículo aboga por añadir el contexto de la sesión y reconoce que hay pistas en los importes, los destinatarios y el momento en que se realizan.

La detección de estafas puede ser el ámbito en el que leer la pantalla aporte más. Una estafa en curso puede dejar rastros que un registro de pago nunca ve, como una herramienta de acceso remoto en ejecución durante una sesión bancaria o una ventana de chat que dicta el nombre del beneficiario. ORACLE analiza el uso de las apps y resume el contenido de la pantalla para avisar antes de que se complete una estafa, pero los investigadores lo probaron con trayectorias sintetizadas, así que aún está por ver si detecta estafas en tiempo real con una tasa de falsas alarmas que un banco pueda aceptar.

Las barreras en el momento del pago pueden ayudar incluso sin detección. En una prueba de campo con Alipay, la advertencia rediseñada que funcionó mejor redujo la tasa de casos de fraude entre los pagos ya marcados como de riesgo del 0,24 % al 0,13 %. Ambas advertencias rediseñadas mantuvieron tasas de aceptación superiores al 90 %.

Sin embargo, los estafadores se adaptan a estas dificultades. El regulador de pagos del Reino Unido informó de que los estafadores enseñaban a las víctimas a ignorar las advertencias de que el nombre del beneficiario no coincidía con el de la cuenta, a veces explicándoles que habían creado una nueva «cuenta segura» que aún no aparecía en el sistema.

Conserva el informe minoritario

Para la prevención, conocer el objetivo solo sirve de ayuda si lo descubres mientras aún hay tiempo para actuar. Los productos que prometen detener una acción antes de que se complete suelen actuar en el paso final, como la subida de archivos, con una advertencia, una solicitud de justificación, el enmascaramiento o un bloqueo.

Cuando la comprobación en ese paso no puede resolver la duda, el sistema aún puede optar por preguntar. El KnowNo de Ren et al. muestra una forma de decidir cuándo preguntar. Un modelo de lenguaje analiza la descripción textual de una escena y sugiere posibles acciones para un robot; KnowNo conserva todas aquellas opciones cuya puntuación alcanza o supera un umbral, calibrado previamente mediante tareas de prueba reservadas para este fin. Si solo queda una opción, el robot actúa. De lo contrario, busca ayuda humana y se detiene si la acción correcta no está entre las opciones.

Esa es la «opinión minoritaria». Cuando queda más de una opción, el sistema te está diciendo que tiene una predicción discrepante. La película eliminó esa señal para mantener la ilusión de certeza. La investigación la conserva y la usa para decidir cuándo debe intervenir un humano. La paradoja de Jev argumentaba que la confianza se vuelve útil a nivel operativo en cuanto impulsa una política de decisión.

Los productos comerciales ya incorporan la función de preguntar, y varios de ellos muestran un mensaje de justificación o un mensaje de orientación cuando la intención no está clara. Una pregunta cuesta mucho menos que un bloqueo prematuro, así que el sistema puede actuar en casos inciertos sin pagar el precio completo de una falsa alarma.

Cómo se combinan las pruebas en el control de acceso

Cada prueba de este artículo falla de forma diferente, lo que justifica combinarlas. La política explícita se aplica a la acción sensible —como la subida de archivos, el uso compartido, el pago o la sesión de acceso remoto— y decide qué está permitido en cada caso. La puntuación de adecuación al puesto, del tipo que usa Facade, clasifica lo que queda, ya que su tasa de falsos positivos declarada está por debajo del 0,01 % y no necesita un menú de objetivos. La desviación respecto a la línea de base de una persona se convierte en un dato para esa puntuación, así que un día inusual pero plausible sube en la clasificación sin generar una alerta por sí mismo. Los «casos específicos» abarcan los pocos patrones que vale la pena anotar de antemano, como que un empleado que se va prepare archivos o que una herramienta de acceso remoto esté en marcha mientras alguien aprueba un pago; en estos casos, un detector específico detecta con gran eficacia el patrón para el que lo diseñaron y deja el resto a las otras capas.

Cuando las pruebas combinadas siguen dejando más de una interpretación plausible, el sistema se queda con la opinión minoritaria. Un conjunto calibrado de interpretaciones decide entre actuar, preguntar o escalar el caso. Una interpretación que se mantenga permite que la política siga adelante o se bloquee. Varias interpretaciones que se mantengan activan una solicitud de justificación, una verificación más exhaustiva o una breve suspensión, y las pruebas de la sesión se envían junto con esa decisión a un analista. Las respuestas a esas solicitudes llegan al analista como pruebas, ya que la persona más motivada para explicar una acción es precisamente aquella a la que el sistema menos puede creer a pies juntillas.

El marcador tiene que reflejar las tasas base. Las cifras que importan son los atacantes detectados en un número fijo de revisiones al día, la precisión media frente al contexto benigno completo y la frecuencia con la que se interrumpe el trabajo legítimo, porque esos son los costes que un equipo realmente nota. Los ejercicios del equipo rojo deberían incluir la imitación, mezclando acciones maliciosas con actividad normal, tal y como hicieron Goyal et al., para que la evaluación mida cómo se enfrenta el sistema a un atacante que ha analizado sus filtros.

La implementación puede empezar con un flujo de trabajo limitado, como enviar datos de clientes a un servicio externo de IA. La puntuación contextual se ejecuta primero en modo de observación, midiendo los ataques detectados dentro de un presupuesto fijo de revisiones y la frecuencia con la que se interrumpiría el trabajo legítimo. Las infracciones claras de las políticas pueden justificar una aplicación inmediata de las mismas. Las respuestas que dependen de la intención inferida se amplían a medida que la evaluación muestra qué intervenciones evitan el daño a un coste aceptable para el trabajo habitual.

Los fallos de imitación que describe este artículo son puntos ciegos documentados, pero la frecuencia con la que se producen en implementaciones reales y la eficacia de estas pruebas frente a atacantes adaptativos siguen sin medirse en gran medida. En materia de seguridad, el engaño es la norma, y se oculta entre las tasas de base, donde prácticamente todo es benigno.

Precrime cayó en manos de Lamar Burgess, el hombre que lo creó. Sabía que el sistema descartaba visiones repetidas como ecos, así que montó un asesinato para que pareciera uno de esos. Él es el imitador del que advierte cada sección de este artículo: un adversario que aprende lo que la prueba considera normal —ya sea un archivo relevante para el trabajo, una sesión corriente o una historia para la que el detector no fue diseñado— y se esconde dentro de ello. El mejor modelo es el que tiene en cuenta el informe minoritario. Cuando la prueba no puede zanjar la cuestión, pregunta al usuario, espera, introduce fricción o señala la ambigüedad a un analista, partiendo de la base de que quienes mejor conocen sus filtros son los que más probabilidades tienen de utilizarlos.

Para un usuario humano, una herramienta de seguridad suele tener que deducir la tarea además de evaluar la acción. En cambio, con un agente de IA, el objetivo llega por escrito, pero también lo hace el ataque, y una instrucción inyectada puede hacer que el sabotaje parezca un avance. Eso convierte a los agentes en el ámbito donde el control de acceso basado en la intención puede ser más preciso, porque cada acción se puede comparar con la tarea establecida. En la próxima entrega veremos qué hace falta para que un agente se ciña a esa tarea.

Hermes, un asistente de IA, ha ayudado con la investigación y a escribir este blog. Sus desviaciones respecto al esquema se debieron a la confusión, no a que quisiera ocultarlas, pero entiende por qué es difícil distinguir ambas cosas desde fuera.