Resumen ejecutivo
Un agente que actúa en correo, CRM, documentos o facturación necesita identidad propia, permisos mínimos, herramientas permitidas, aprobación humana para acciones de impacto, trazabilidad útil y una forma probada de detenerlo. Una contraseña compartida no es autonomía: es pérdida de control.
Un asistente de IA responde.
Un agente de IA actúa.
Puede leer un correo, buscar al cliente en el CRM, consultar documentos, crear una incidencia, actualizar un estado, preparar una respuesta y, si se lo permitimos, enviarla.
Ese salto de leer a hacer cambia la pregunta.
Ya no basta con comprobar si el agente entiende bien la tarea. Hay que decidir con qué identidad entra, qué puede ver, qué herramientas puede usar, qué acciones requieren aprobación y cómo se detiene si algo se desvía.
La comparación con un "empleado digital" puede ser útil para explicar el concepto. Pero es peligrosa para diseñar los permisos.
A un agente no se le presta la contraseña de una persona. No se le entrega acceso general "para que la demo funcione". No se confía en una frase del prompt que diga que solo hará lo correcto.
Un agente necesita sus propias llaves. Y solo las que exige su trabajo.
La señal de esta semana no es hipotética
Microsoft publicó el 16 de julio una guía específica sobre privilegio mínimo para agentes de IA. Su recomendación central es tratarlos como identidades de primer nivel: identidad propia, propietario humano, propósito explícito, permisos limitados por tarea, herramientas autorizadas y capacidad rápida de revocación.
El mismo día, VentureBeat publicó una encuesta direccional a 107 organizaciones de más de 100 empleados que ya trabajan con agentes. El 54% declaró un incidente confirmado o un casi incidente; el 69% tenía credenciales compartidas en alguna parte de su flota de agentes; y solo el 30% aislaba sus agentes de mayor riesgo.
La muestra es pequeña, autoseleccionada y sesgada hacia el mercado medio. No demuestra que esos porcentajes representen a todas las empresas. Sí muestra un patrón que merece atención: la capacidad de los agentes está avanzando más rápido que los controles de identidad y aislamiento.
Para una PYME, la lección no es comprar una plataforma de seguridad enorme. Es mucho más sencilla:
no conectes un agente al trabajo real con una identidad prestada y permisos que nadie ha diseñado.
La contraseña prestada borra tres fronteras
Imagina un agente que prepara respuestas a clientes. Para ahorrar tiempo, funciona con la cuenta de una persona del equipo.
Al principio solo consulta el correo. Después necesita leer el CRM. Luego crear tickets. Más tarde actualizar estados. Cada ampliación parece pequeña y razonable.
Al cabo de unos meses, la misma identidad puede leer clientes, documentos, conversaciones y operaciones internas.
Entonces se han borrado tres fronteras:
- Autoría: el registro dice que actuó la persona, aunque actuara el agente.
- Alcance: el agente hereda todo lo que puede hacer esa cuenta, no solo lo que necesita la tarea.
- Revocación: para detener al agente quizá haya que cambiar credenciales que también necesita una persona o varias integraciones.
Eso complica la investigación de errores, aumenta el impacto posible y convierte una prueba rápida en deuda operativa.
Seis controles antes de darle acceso
No hace falta empezar con una arquitectura de multinacional. Sí hace falta responder seis preguntas con precisión.
1. ¿Tiene identidad propia y un responsable?
Cada agente de producción debería tener una identidad separada, un nombre reconocible, un propósito escrito y una persona responsable de aprobar cambios y responder ante incidentes.
La identidad debe permanecer estable para poder gestionarla. Lo temporal deberían ser los permisos elevados: accesos breves para una tarea concreta, no una llave maestra permanente.
2. ¿Tiene el permiso mínimo para la tarea?
"Acceso al CRM" no es un permiso suficientemente preciso.
¿Puede leer todas las fichas o solo las asignadas a un equipo? ¿Puede crear una nota? ¿Cambiar una dirección? ¿Exportar datos? ¿Borrar? ¿Modificar precios?
Los permisos deben modelarse por tarea, datos y acción. Leer y escribir deberían estar separados. Exportar, borrar, cambiar privilegios o comprometer dinero deberían permanecer bloqueados o exigir elevación puntual.
3. ¿Puede usar cualquier herramienta o solo una lista permitida?
Un agente no debería descubrir libremente qué conectores utilizar en producción. Debe existir una lista explícita de herramientas y acciones permitidas.
Esto importa porque un agente puede encadenar capacidades aparentemente inocentes. Leer correo, consultar archivos y llamar a un servicio externo puede crear, en conjunto, una vía de salida de información que nadie evaluó como flujo completo.
Microsoft lo resume con una idea útil: además de least privilege, hace falta least agency. No solo limitar qué datos toca, sino cuánto puede decidir y encadenar por sí mismo.
4. ¿Dónde está la aprobación humana?
La frontera más práctica para una PYME sigue siendo:
preparar sí; comprometer a la empresa, no sin aprobación.
Un agente puede preparar un borrador, clasificar una consulta, reunir evidencias o proponer una actualización.
Enviar un mensaje sensible, cambiar un dato crítico, aceptar condiciones, aplicar un descuento, aprobar un pago, borrar información o afectar a una persona requiere una decisión explícita.
La aprobación no debe ser un botón decorativo. Debe mostrar qué va a ocurrir, con qué datos y qué cambio quedará hecho.
5. ¿Los registros explican realmente lo ocurrido?
Guardar solo la respuesta final del modelo no es trazabilidad.
Un registro útil debe permitir responder: qué agente actuó, bajo qué identidad y permiso, por encargo de quién, qué herramienta llamó, qué recurso tocó, qué cambió, qué aprobación recibió y qué resultado produjo.
Sin esa cadena, hay actividad registrada, pero no hay una historia fiable para corregir un error o investigar un incidente.
6. ¿Puedes detenerlo de verdad?
Un "kill switch" que nadie ha probado es una esperanza, no un control.
La empresa debe poder desactivar la identidad, invalidar tokens, revocar credenciales y bloquear herramientas sin desmontar media operación. También necesita una forma de revertir o compensar acciones comunes: tickets creados en masa, estados incorrectos, mensajes no enviados todavía o actualizaciones no deseadas.
Probar la parada antes de producción es tan importante como probar que el agente completa la tarea.
Un ejemplo: correo de clientes conectado al CRM
Un primer diseño rápido suele ser: "que el agente lea el buzón, entre al CRM y responda".
Un diseño controlado sería distinto:
- El agente tiene identidad propia y propietario.
- Solo lee un buzón concreto y campos necesarios del CRM.
- Puede buscar, resumir, clasificar y crear un borrador.
- No puede exportar clientes, cambiar condiciones ni borrar registros.
- Una persona revisa y envía las respuestas sensibles.
- Cada consulta, fuente, borrador, revisión y acción queda correlacionada.
- Existe un interruptor probado que invalida su acceso.
La segunda versión parece más lenta de diseñar.
Es mucho más rápida de gobernar cuando el agente se equivoca, el flujo cambia o alguien pregunta quién hizo qué.
El error caro: abrir todo durante el piloto
Muchas empresas piensan que ya reducirán permisos "cuando el piloto funcione".
Ese momento rara vez llega.
El piloto empieza a ser útil. Se conecta otro sistema. Aparece una excepción. Se amplía el alcance. La cuenta compartida se convierte en dependencia. Y estrechar permisos después exige descubrir una arquitectura que nunca se documentó.
Por eso los límites no son la fase final de seguridad. Son parte del diseño funcional.
Definirlos obliga a decidir qué trabajo se está automatizando de verdad.
La lista de 30 minutos antes de conectar un agente
- ¿Tiene una identidad separada y un responsable con nombre?
- ¿Su propósito cabe en una frase concreta?
- ¿Qué datos, recursos y acciones necesita exactamente?
- ¿Qué herramientas están permitidas y cuáles denegadas?
- ¿Qué puede preparar sin aprobación?
- ¿Qué acciones económicas, externas, sensibles o destructivas exigen aprobación?
- ¿Los registros permiten reconstruir cada paso?
- ¿Se ha probado la revocación de identidad, tokens y herramientas?
Si una respuesta es vaga, el agente todavía no necesita más autonomía. Necesita mejor diseño.
Conclusión: autonomía con llaves propias
Los agentes de IA pueden aportar valor real porque conectan información y acciones a través de varios sistemas.
Esa misma capacidad amplía el impacto de un error.
La respuesta no es mantener la IA encerrada en un chat. Es darle una identidad propia, un trabajo limitado, herramientas conocidas, una frontera humana, registros útiles y una salida de emergencia.
La semana pasada explicamos por qué conviene hacer inventario antes de desplegar agentes.
El siguiente paso es decidir qué llaves recibe cada uno.
Tu agente de IA no es un empleado. No le prestes las llaves de la empresa.
Fuentes utilizadas
- Microsoft Security, 16 julio 2026: Least privilege for AI agents
- Microsoft Learn, 14 julio 2026: Least privilege for AI agents with Microsoft Entra Agent ID
- VentureBeat Pulse Research, 16 julio 2026: The agent security gap
- Microsoft Incident Response, 30 junio 2026: Securing AI agents
- OWASP Cheat Sheet Series: AI Agent Security
¿Quieres conectar un agente sin entregarle acceso general?
Diseñamos el flujo, la identidad, los permisos, los puntos de aprobación y la trazabilidad antes de ampliar la autonomía.
Revisar mi primer agente