La incorporación de agentes de inteligencia artificial a tareas de trabajo plantea una contradicción de seguridad: los equipos pueden exigir permisos y aprobaciones para ciertas operaciones, pero mantener prácticas que facilitan el acceso a cuentas y servicios compartidos. La encuesta reflejada en el titular apunta a esa distancia entre las reglas formales y el uso cotidiano de las credenciales. El problema no se limita a la tecnología de IA. También afecta a la forma en que las organizaciones conceden, supervisan y retiran accesos.
Los agentes pueden ejecutar instrucciones, consultar aplicaciones y encadenar acciones con una autonomía mayor que la de un asistente que solo responde preguntas. Para hacerlo, necesitan permisos sobre sistemas y datos. Si esos permisos se apoyan en contraseñas compartidas o cuentas genéricas, resulta más difícil determinar quién realizó una acción, limitar su alcance y detenerla a tiempo. La seguridad depende, por tanto, tanto del diseño del agente como de las prácticas de identidad que lo rodean.
La diferencia entre exigir permisos y controlar accesos
Solicitar autorización antes de una operación sensible es una medida útil, pero no equivale por sí sola a tener un modelo de acceso seguro. Un proceso de aprobación puede comprobar que una tarea está permitida; no necesariamente identifica con precisión qué agente la ejecutará, con qué identidad o con qué privilegios. Si varios empleados o sistemas utilizan la misma credencial, el registro de actividad puede perder claridad.
La gestión de identidades y accesos busca responder preguntas concretas: quién o qué solicita una acción, a qué recurso intenta acceder y bajo qué condiciones. En el caso de un agente, la identidad debería corresponder al propio sistema automatizado, no a una persona cuya cuenta se reutiliza para simplificar la integración. De ese modo, las políticas pueden conceder permisos específicos y el registro puede atribuir las operaciones con mayor precisión.
La brecha aparece cuando el discurso de control convive con atajos operativos. Compartir una contraseña puede parecer una solución rápida para que una herramienta lea documentos o actualice un sistema. Sin embargo, ese atajo convierte un acceso individual en un punto común para distintas personas, procesos o agentes. Cuando ocurre un error, identificar el origen puede resultar complicado. Y si la clave queda expuesta, no siempre es sencillo saber qué recursos están en riesgo.
Por qué las credenciales compartidas amplían el riesgo
Una credencial compartida concentra permisos y reduce la trazabilidad. Si se reutiliza en distintos servicios, una filtración puede abrir más puertas de las previstas. Además, cambiar la contraseña puede interrumpir procesos legítimos y obligar a coordinar a quienes dependen de ella. Esa dependencia suele favorecer que las claves se mantengan activas más tiempo del necesario o se almacenen en lugares poco adecuados.
En los agentes de IA, la dificultad se agrava porque una instrucción puede desencadenar varias acciones. Un agente autorizado para consultar una carpeta, por ejemplo, podría usar su acceso dentro de una secuencia de tareas. Si la identidad que utiliza tiene privilegios amplios, una equivocación de configuración o una instrucción maliciosa podría alcanzar datos que no eran necesarios para el objetivo original.
El riesgo no significa que todo agente vaya a actuar de forma incorrecta. Significa que la automatización puede ejecutar operaciones con rapidez y a escala, mientras que una cuenta compartida dificulta atribuir responsabilidades. Los controles deben considerar tanto los fallos técnicos como los errores humanos y las instrucciones que intentan manipular el comportamiento del sistema.
Menos privilegios, más capacidad de auditoría
El principio de mínimo privilegio consiste en otorgar únicamente los permisos necesarios para una tarea, durante el tiempo y bajo las condiciones apropiadas. Para un agente que resume archivos, eso puede significar acceso de lectura a un conjunto delimitado de documentos, sin autorización para borrarlos, compartirlos externamente o modificar permisos.
La separación también debe aplicarse entre entornos y funciones. Un agente de pruebas no debería heredar automáticamente las credenciales de una herramienta de producción. Del mismo modo, el acceso de un proceso de análisis no tiene por qué permitir cambios en registros financieros o información de clientes. Cuanto más acotado es el permiso, menor es el impacto potencial de una acción equivocada.
Las medidas que ayudan a cerrar la brecha
Las organizaciones pueden reducir la exposición combinando controles técnicos con reglas operativas claras. No existe una única medida que resuelva todos los casos, pero algunas prácticas ayudan a evitar que la comodidad de una cuenta compartida se convierta en una dependencia permanente:
- Asignar identidades individuales a los agentes, separadas de las cuentas personales de los empleados.
- Limitar los permisos a los datos y acciones indispensables para cada función.
- Evitar secretos incrustados en instrucciones, código o documentos accesibles para el agente.
- Registrar las operaciones con información que permita reconstruir qué identidad actuó y sobre qué recurso.
- Definir una revocación sencilla para retirar accesos cuando cambie la tarea o se detecte una anomalía.
- Exigir confirmación humana antes de acciones de alto impacto, como borrar información o modificar permisos.
La gestión de secretos debe formar parte del diseño y no añadirse como respuesta tardía. Las claves de acceso han de almacenarse en mecanismos protegidos, con rotación y restricciones acordes al riesgo. También conviene revisar las integraciones que ya funcionan con cuentas genéricas. La transición requiere inventariar qué servicios utilizan esas credenciales y qué procesos podrían interrumpirse al sustituirlas.
La aprobación humana no sustituye a la identidad
La revisión de una persona puede ser esencial para las decisiones sensibles, pero no corrige automáticamente una identidad mal configurada. Si un empleado aprueba una operación ejecutada con una cuenta que comparten varios sistemas, la organización seguirá teniendo dificultades para atribuir el resto de las acciones realizadas con esa cuenta. La aprobación y la identidad son controles complementarios, no alternativas.
También importa el momento de la revisión. Una autorización genérica concedida al inicio de una sesión puede tener menos valor que una confirmación ligada a una acción concreta, con detalles sobre el recurso y el efecto esperado. Esa información permite evaluar mejor el riesgo y reduce la posibilidad de que una aprobación amplia cubra operaciones que el responsable no tenía previstas.
El desafío de llevar las políticas a la práctica
Las normas internas suelen ser más fáciles de redactar que de aplicar en todos los sistemas. Una empresa puede establecer que cada usuario tenga su propia cuenta, pero encontrarse con aplicaciones antiguas que solo admiten accesos compartidos. También puede haber equipos que recurran a una contraseña común para evitar demoras o mantener una automatización en funcionamiento. Esos casos requieren soluciones técnicas y responsables definidos, no solo recordatorios generales.
Una revisión útil empieza por identificar qué agentes están conectados a servicios corporativos, qué datos pueden consultar y qué acciones pueden ejecutar. Después, conviene comparar esos permisos con la finalidad real de cada herramienta. Si un agente solo necesita leer información, cualquier permiso de escritura debe justificarse. Si la tarea exige una capacidad más amplia, pueden añadirse límites, registros y aprobaciones proporcionales al impacto.
El inventario debe incluir también las credenciales que circulan fuera de los sistemas formales. Una contraseña en una nota compartida o en un archivo de configuración puede pasar inadvertida durante una auditoría centrada únicamente en las herramientas oficiales. La seguridad del agente depende de todo el recorrido de la credencial: cómo se crea, quién puede verla, dónde se utiliza y cómo se elimina.
Una cuestión de confianza y responsabilidad empresarial
La adopción de agentes puede aportar eficiencia en tareas repetitivas, pero también cambia la relación entre personas, aplicaciones y datos. Para que esa automatización sea gobernable, las organizaciones necesitan saber qué sistemas están actuando y con qué autoridad. Sin esa visibilidad, una política de permisos puede existir sobre el papel mientras las operaciones se apoyan en accesos difíciles de controlar.
La señal que deja la encuesta del titular es, sobre todo, una llamada a revisar la coherencia entre las exigencias de seguridad y los hábitos de trabajo. El reto no consiste en prohibir por defecto toda automatización ni en confiar sin límites en ella. Consiste en diseñar accesos identificables, acotados y revocables, y en comprobar que las decisiones automatizadas quedan registradas de forma comprensible.
Cuando cada agente dispone de una identidad propia y de permisos ajustados a su función, las empresas pueden investigar incidentes con más precisión y reducir el alcance de un fallo. Si, por el contrario, se comparte una credencial amplia, la aprobación previa pierde parte de su valor: puede controlar una operación concreta, pero no resolver la falta de trazabilidad del sistema. La seguridad de los agentes de IA empieza, así, por una práctica básica: saber quién accede a cada recurso y por qué.
