Después de un acceso sospechoso, cambiar la contraseña parece la forma más rápida de recuperar el control. Sin embargo, algunas sesiones y aplicaciones conectadas pueden conservar el acceso. Entender cómo funcionan esos permisos ayuda a saber qué más hay que revisar.
Imagina que tu empresa detecta un acceso sospechoso al correo de un empleado. El equipo cambia la contraseña y comprueba que la anterior ya no funciona. Todo parece resuelto, hasta que descubre que una aplicación conectada a esa cuenta sigue descargando documentos. ¿Cómo puede hacerlo si ya no conoce la contraseña?
La explicación está en lo que ocurre después de iniciar sesión. Para evitar que tengamos que identificarnos a cada momento, los servicios mantienen sesiones abiertas y pueden conceder permisos a otras aplicaciones. Cambiar la contraseña no siempre anula todos esos accesos: depende de cómo funcione cada servicio y de las medidas que se hayan aplicado para retirarlos.
Esto resulta especialmente relevante cuando una empresa conecta su correo, sus documentos o sus bases de datos con herramientas que trabajan en su nombre. Entre ellas están los agentes de inteligencia artificial, capaces de consultar información y ejecutar tareas. Si uno de esos accesos cae en manos de un atacante, necesitamos saber qué puede hacer con él y cómo detenerlo.
Cómo puede una aplicación acceder sin conocer tu contraseña
Piensa en una herramienta a la que autorizas a consultar tu calendario. No necesita que le entregues tu contraseña cada vez que busca una reunión. El servicio puede proporcionarle un token de acceso: una credencial digital que presenta para realizar determinadas operaciones durante un tiempo limitado. OAuth 2.0 es uno de los mecanismos que permiten organizar esta autorización entre aplicaciones.
Ese token permite que las aplicaciones trabajen juntas, pero también necesita protección. En los llamados tokens al portador, quien consiga copiar uno podrá intentar utilizarlo mientras siga siendo válido. Si el servicio lo acepta, el atacante puede realizar las operaciones autorizadas sin volver a introducir la contraseña ni superar el segundo factor de autenticación. Por eso, proteger el inicio de sesión y proteger las credenciales emitidas después son tareas complementarias.
Además, algunas aplicaciones reciben una credencial de renovación que les permite obtener nuevos tokens cuando los anteriores caducan. Un acceso pensado para durar unos minutos puede prolongarse si esa renovación sigue autorizada. Para retirarlo puede ser necesario cerrar las sesiones, invalidar las credenciales y revocar la autorización de la aplicación. La comprobación decisiva es que haya dejado de acceder a la información.
No todos los tokens cumplen la misma función. Algunos comunican quién se ha identificado, otros permiten acceder a un recurso y otros sirven para renovar ese acceso. Esta distinción tiene una consecuencia práctica: el equipo técnico necesita averiguar qué se ha filtrado para saber qué debe desactivar. Cambiar una contraseña sin revisar estas conexiones puede dejar parte del problema sin resolver.
Lo que enseñó un ataque a los correos de 25 organizaciones
En 2023, Microsoft investigó una campaña conocida como Storm-0558 que había permitido acceder al correo de unas 25 organizaciones. Según su análisis técnico del incidente, los atacantes utilizaron una clave de firma obtenida de Microsoft para crear tokens falsificados. Un error en las comprobaciones del servicio permitió que se aceptaran para acceder a cuentas a las que no debían dar acceso.
La firma digital sirve para comprobar quién emitió una credencial y si ha sido alterada. Pero el servicio también debe revisar a qué aplicación va dirigida, cuándo caduca y qué operaciones autoriza. En este caso, el fallo en esa cadena de comprobaciones permitió que los atacantes presentaran credenciales que el sistema trataba como válidas, sin tener que robar la contraseña de cada usuario afectado.
El caso muestra por qué importa distinguir entre una credencial robada y la capacidad de fabricar credenciales falsas. Si se ha copiado un token, hay que impedir que siga utilizándose y revisar sus posibles renovaciones. Si se ha comprometido una clave con la que se firman tokens, la respuesta alcanza también a esa clave y a los servicios que confían en ella.
La guía del NIST sobre protección de tokens y aserciones, publicada el 15 de septiembre de 2026, aborda precisamente estos riesgos. Sus recomendaciones para agencias y proveedores de servicios en la nube abarcan la protección de claves, las comprobaciones de las credenciales y el control de su vigencia. Para una empresa que contrata aplicaciones conectadas, aporta una idea útil: necesita conocer cómo se conceden los accesos y qué ocurre cuando quiere retirarlos.
Qué debería comprobar tu empresa
La protección de tokens de acceso empieza por concretar qué necesita hacer cada aplicación. Una herramienta que consulta facturas puede requerir permiso para leerlas, pero eso no justifica que pueda modificar usuarios o autorizar pagos. Las buenas prácticas de seguridad de OAuth 2.0 recogen la importancia de limitar esos permisos. Al evaluar una integración, conviene traducirlos a acciones que el negocio pueda entender.
Una forma de hacerlo es pedir una demostración: que la herramienta consulte la información necesaria y que el sistema rechace las operaciones que quedan fuera de su tarea. También debería comprobarse que una credencial emitida para un servicio no pueda utilizarse en otro al que no da acceso. Así, la empresa puede valorar las restricciones por su funcionamiento, además de por la descripción del proveedor.
La siguiente prueba consiste en retirar la autorización y observar qué sucede. ¿La aplicación deja de acceder inmediatamente? ¿Puede continuar hasta que caduque el token? ¿Conserva alguna forma de obtener uno nuevo? Algunos sistemas mantienen credenciales válidas durante un intervalo, de modo que conocer ese tiempo resulta importante para planificar la respuesta ante un incidente.
Estas pruebas también ayudan a detectar responsabilidades mal definidas. Puede que el proveedor gestione la aplicación, otro servicio controle la identidad y la empresa administre los permisos. Si nadie ha acordado quién puede detener cada acceso, una alerta obliga a resolver esa coordinación en el peor momento. Dejar establecidos los responsables y comprobar el procedimiento antes reduce esa incertidumbre.
Existen además mecanismos que dificultan utilizar una copia robada de un token. Uno de ellos es DPoP, que vincula determinados tokens a una clave que la aplicación debe demostrar que posee. Copiar únicamente el token deja de ser suficiente. Su utilidad depende de que los servicios lo admitan y lo implementen correctamente; si el atacante también puede utilizar la clave, esa protección pierde eficacia.
Qué cambia cuando quien utiliza el permiso es un agente de IA
Imagina ahora un agente encargado de preparar el informe comercial de cada lunes. Necesita consultar determinadas carpetas y reunir datos, pero quizá no deba borrar archivos, modificar la base de clientes ni enviar el informe al exterior. La empresa tiene que decidir esas capacidades al configurar la integración, aunque el agente pueda entender instrucciones mucho más amplias.
Pedirle por escrito que «no modifique nada» puede orientar su comportamiento, pero la restricción debe aplicarse también en el sistema al que accede. Si solo necesita leer, sus credenciales deberían limitarlo a esa operación. Así, una interpretación equivocada o una instrucción engañosa encuentra un límite técnico antes de convertirse en un cambio sobre los datos.
También debe quedar registrado qué hizo el agente y en nombre de quién. Compartir una misma identidad entre varios procesos dificulta reconstruir un incidente o retirar un acceso concreto. El trabajo del NIST sobre identidad y autorización de agentes de software e IA aborda esta relación entre las personas que delegan una tarea y los programas que la ejecutan.
Esto conecta con el análisis de ITO sobre cómo evaluar la fiabilidad de una inteligencia artificial. La calidad de sus respuestas es una parte de la evaluación. También importa qué información puede consultar, qué acciones tiene permitidas y cómo se detiene su actividad cuando algo falla. Una respuesta correcta no garantiza que los permisos estén bien configurados.
Volvamos a la empresa del principio. Para saber si ha recuperado el control, necesita comprobar que la aplicación sospechosa ya no descarga documentos, que no puede renovar sus credenciales y que no quedan otros accesos no autorizados. El cambio de contraseña forma parte de la respuesta, pero son esas comprobaciones las que permiten saber si el intruso ha dejado de acceder.
Redacción ITO · International Technological Observatory