El informe anual de investigación de brechas de datos de Verizon, edición 2026, llegó a una cifra que debería incomodar a cualquier área de tecnología: el 83% de los casos de escalamiento de privilegios del estudio no explotó ninguna falla técnica. El atacante no necesitó una vulnerabilidad sofisticada. Solo usó un acceso que ya estaba concedido, solo que demasiado amplio para la tarea que debía cubrir.
El mismo informe midió cuánto tardan las empresas en corregir eso: los permisos excesivos y el acceso mal configurado tardan una mediana de casi ocho meses en resolverse. Y el 26% de las organizaciones aún carga brechas de escalamiento de privilegios abiertas desde 2021. No es un problema nuevo. Es un problema con el que la mayoría de las empresas decidió convivir.
Ese hábito no nació con la IA, pero la IA corporativa es donde más se repite ahora. Cuando un equipo conecta un asistente a un sistema interno, la pregunta rara vez es "de cuáles de las cien funciones de ese sistema necesita el equipo realmente". Es "¿de alguna forma se puede conectar esto?". Y la forma más rápida, casi siempre, es abrir todo.
Una deuda que la IA está reactivando
El principio detrás de esto tiene nombre y no es nuevo: el modelo de confianza cero del NIST, en su documento de referencia SP 800-207, trata el acceso mínimo necesario como uno de sus pilares: conceder privilegio por sesión, de forma temporal, y elevarlo solo cuando la tarea realmente lo exija. Ninguna empresa está en desacuerdo con el principio en teoría. La dificultad está en aplicarlo cuando alguien necesita entregar algo hoy y abrir todo resuelve más rápido que configurar bien.
Con sistemas usados por personas, ese atajo ya es costoso, es justo lo que el modelo del NIST intenta corregir. Con agentes de IA, el riesgo crece en otra dirección: el Microsoft Digital Defense Report de 2025 registra que las identidades de sistemas, aplicaciones y agentes automatizados ya superan a las identidades de personas en buena parte de las empresas, y que esas identidades suelen cargar más privilegio del necesario y controles más débiles que la cuenta de una persona. Un agente conectado a una herramienta entera, con una sola credencial que abre todas sus funciones, es exactamente ese patrón, solo que ahora conversa en lenguaje natural con cualquier persona del equipo.
Por qué "conectar todo" parece la salida más simple
Cuando el equipo de tecnología necesita conectar un asistente de IA a un sistema de gestión, la documentación de la integración suele describir decenas de funciones: consultar, crear, editar, aprobar, cancelar, exportar. El equipo que pidió la integración quizás necesite dos: consultar pedidos y ver el estado de la entrega. Configurar exactamente esas dos da trabajo: exige mapear qué hace cada función, decidir quién recibe qué, y mantenerlo actualizado cuando el equipo cambia. Abrir la credencial entera resuelve al instante.
El problema aparece después, y nunca aparece solo: aparece cuando alguien pregunta, en una auditoría o tras un incidente, "quién podía cancelar pedidos por aquí". Si la respuesta es "todos los que tenían acceso al asistente, porque así se hizo la integración", no existe rastro para reconstruir quién usó qué. Es exactamente el patrón que describe el informe de Verizon: el problema rara vez es una falla de seguridad sofisticada. Es un acceso que quedó demasiado amplio y nadie revisó.
Este tipo de decisión tampoco escala. Cada nueva herramienta conectada de la misma forma multiplica la superficie que una sola credencial comprometida, o un solo error de configuración de un agente, puede alcanzar. En algún momento la lista de "qué podría hacer técnicamente este asistente" crece más de lo que cualquiera puede explicar de memoria.
Lo que tiene que existir en la práctica
Un entorno de IA con acceso bien diseñado se apoya en mecanismos concretos, no en la buena intención de configurar bien "cuando haya tiempo".
Acceso función por función, no la herramienta entera. Si una integración tiene treinta funciones y el equipo de soporte usa dos, se conceden esas dos. El resto queda disponible para cuando —y si— otro equipo realmente lo necesite, no por defecto.
Alcance en capas. No todo acceso necesita nacer definitivo y válido para toda la empresa. Un acceso puede empezar personal, para una prueba o una tarea puntual, y solo después "crecer" a acceso oficial de un equipo o de la empresa, mediante decisión de quien aprueba, no por inercia.
Credencial propia por herramienta y por persona. Nadie comparte una sola clave de acceso entre varias personas o varios agentes. Cuando una credencial desaparece del cuadro —porque la persona se fue, porque el agente se desactivó— desaparece sola, sin depender de que alguien recuerde revocar algo manualmente.
Aprobación cuando el alcance de un acceso aumenta. Pedir más permiso del inicial no es automático: alguien decide, y esa decisión queda registrada. Es la diferencia entre un acceso que crece porque tenía sentido crecer, y uno que crece porque nadie prestó atención.
Un rastro de quién tiene qué, revisable en cualquier momento. Si la pregunta "quién puede cancelar pedidos por el asistente" necesita dos semanas de investigación para responderse, el diseño de acceso ya falló, exista o no un incidente de por medio.
Así fue diseñada la Skyller: liberación función por función dentro de cada herramienta conectada, alcance en capas entre empresa, agente, equipo y persona, y credencial propia por herramienta en lugar de una sola clave compartida.
Lo que cambia para quien decide el acceso
Cuando el acceso se concede función por función, quien aprueba una nueva integración deja de firmar un cheque en blanco. La pregunta deja de ser "¿puedo confiar en esta herramienta de IA?" —demasiado amplia para responder con seguridad— y pasa a ser "¿estas dos funciones específicas tienen sentido para este equipo?". Es una decisión mucho más fácil de tomar, y mucho más fácil de defender después.
La ganancia también aparece en la velocidad de reacción. Cuando una persona cambia de función o deja la empresa, ajustar su acceso deja de ser un proyecto de revisión manual en varias herramientas distintas y pasa a ser consecuencia directa de cambiar un rol en un solo lugar. Y cuando un agente de IA necesita una función nueva, el equipo de tecnología no elige entre "abrir todo de nuevo" o "frenar al equipo", porque conceder justo esa función ya es el camino más rápido, no el más laborioso.
Una guía para revisar el acceso de su primer asistente conectado
- Liste las herramientas ya conectadas a algún asistente de IA en la empresa. Si la respuesta es "no lo sé con certeza", ese ya es el primer hallazgo, y el motivo para empezar por aquí.
- Para cada una, pregunte cuántas funciones usa realmente el asistente hoy. Compárelo con cuántas permite la credencial actual. La diferencia entre los dos números es el permiso que sobra sin necesidad.
- Verifique si existe una credencial única compartida entre personas o entre agentes. Si existe, es el primer punto a corregir: es lo que impide reconstruir quién hizo qué.
- Confirme quién aprueba cuando un acceso pide crecer. Si la respuesta es "nadie, es automático", el alcance de la IA en la empresa está creciendo sin decisión de nadie.
- Pregunte cuánto tiempo lleva cada acceso sin revisarse. Un acceso concedido hace dos años, para una tarea que ya cambió, es exactamente el tipo de brecha que el informe de Verizon describe como algo que tarda meses en corregirse.
