Los agentes de IA ya son usuarios internos: Microsoft propone identidad, permisos y contención
Un agente que consulta facturas, aprueba gastos o actualiza un inventario no es solo una herramienta: tiene acceso, toma decisiones y deja efectos en sistemas reales. Microsoft propone tratarlo como un nuevo tipo de usuario interno, con identidad propia y una autoridad que pueda reducirse o retirarse mientras trabaja.
01
El riesgo no empieza cuando alguien ataca al agente
Microsoft presentó el 19 de octubre de 2026 una ampliación de Project Perception orientada a los agentes que ya operan dentro de las organizaciones. La compañía los define como agentes internos: sistemas que acceden a datos, aplicaciones, herramientas y otros agentes para ejecutar tareas de negocio.
La idea no presupone que el modelo sea malicioso. El problema es más cotidiano: puede equivocarse, recibir una instrucción manipulada, cambiar de plan al encontrar nueva información o heredar permisos demasiado amplios. Un agente que empieza revisando una factura podría terminar intentando modificar un recurso que nunca necesitó para esa tarea.
Por eso, Microsoft plantea separar inteligencia y autoridad. El modelo puede proponer y razonar, pero las reglas sobre qué puede leer, escribir, aprobar o invocar deben vivir fuera del propio modelo, en una capa que no pueda desactivar ni eludir.
02
Cada agente necesita una identidad distinta de la persona que lo utiliza
La primera condición para controlar un agente es saber que existe, quién es su responsable y para qué fue creado. Microsoft afirma que sus sistemas podrán descubrir 60 tipos de agentes locales, incluidos Claude Code, OpenAI Codex y GitHub Copilot, e incorporarlos a un registro común.
Después, Microsoft Entra Agent ID asigna al agente una identidad separada de la cuenta humana que lo patrocina. Esa separación permite atribuir acciones, definir un ciclo de vida y evitar que el agente herede automáticamente todos los privilegios del empleado.
El principio es importante incluso en una pyme sin una plataforma de seguridad compleja. Una automatización que concilia cobros no debería usar las mismas credenciales con las que el propietario administra el banco, el correo y el almacenamiento. Su cuenta debería limitarse a los documentos, periodos y operaciones estrictamente necesarios.
03
Permisos temporales y proporcionales a una tarea
Microsoft introduce Dynamic Permissions para que la autoridad del agente esté vinculada a una tarea y a un periodo concreto. La política de la organización establece el límite máximo; dentro de él, el agente recibe solo los permisos necesarios y los pierde cuando termina el trabajo o cambia el contexto.
El enfoque reemplaza el acceso permanente por una autorización progresiva. Leer una carpeta de facturas puede estar permitido, registrar una propuesta de conciliación puede requerir una comprobación adicional y ordenar un pago debe quedar fuera del alcance del agente o exigir una aprobación humana verificable.
La misma lógica sirve para inventario, reservas, compras, soporte o producción audiovisual. No todos los pasos tienen el mismo impacto: consultar, proponer, modificar y comprometer recursos deberían ser niveles distintos de autoridad.
04
El permiso correcto al inicio puede dejar de ser seguro después
Un control de acceso tradicional comprueba quién entra y con qué permiso. Un agente puede necesitar algo más dinámico porque su riesgo cambia durante la ejecución. Puede leer un documento externo con una inyección de instrucciones, desviarse del objetivo o intentar conectar una herramienta no prevista.
Dynamic Agent Risk combina señales de identidad, datos, red, nube, dispositivo, entorno de ejecución y actividad del agente. Dynamic Conditional Access utiliza ese riesgo para responder de forma gradual: mantener la lectura y bloquear la escritura, reducir los recursos accesibles, exigir aprobación, aislar el entorno o detener la ejecución.
Este planteamiento evita dos extremos poco útiles: confiar en el agente hasta que ocurra un incidente o apagar toda la automatización ante cualquier anomalía. La contención puede adaptarse a la gravedad y conservar las funciones seguras.
05
Qué arquitectura puede adoptar una empresa sin comprar toda la plataforma
Project Perception es una propuesta de Microsoft para entornos de gran escala, pero sus principios se pueden aplicar con herramientas más sencillas. El inventario de agentes puede ser un registro de automatizaciones y responsables; la identidad puede ser una cuenta de servicio independiente; los permisos pueden limitarse por carpeta, API, operación y tiempo.
La ejecución debería producir evidencias comprensibles: datos consultados, acciones solicitadas, decisiones tomadas, errores y aprobaciones. Los pasos irreversibles necesitan un punto de control externo al modelo, y las credenciales no deberían aparecer en instrucciones, conversaciones ni archivos que el agente pueda editar.
El objetivo no es convertir cada automatización en un proyecto de ciberseguridad. Es diseñarla para que un fallo tenga un alcance limitado, sea visible y pueda detenerse. Cuanto más capaz sea el agente, menos razonable resulta usar la confianza en el modelo como única barrera.
Fuentes
Las funciones y cifras descritas proceden de publicaciones oficiales de Microsoft. Las aplicaciones para organizaciones pequeñas son análisis editorial y no implican que Project Perception sea necesario para implementarlas. Consulta: 20 de octubre de 2026.
¿Qué automatizaciones pueden operar con un riesgo limitado?
Un diagnóstico breve permite localizar tareas repetitivas y definir desde el principio accesos, aprobaciones y límites.