Un agente no es un usuario con una interfaz inteligente. Es una carga de trabajo capaz de heredar intención, recuperar estado y ejercer autoridad entre sistemas.
Los programas tradicionales de Zero Trust se construyeron alrededor de identidades, dispositivos, redes, aplicaciones y datos. Los sistemas agénticos no sustituyen esas capas; crean nuevas formas de atravesarlas.
La guía de Microsoft de agosto de 2026 sobre Zero Trust para IA identifica agentes, memoria de IA, herramientas de desarrollo y flujos de trabajo autónomos como nuevas fronteras de confianza. El modelo emergente de gobernanza de Databricks coloca igualmente modelos, servicios MCP y agentes detrás de privilegios, políticas y telemetría centralizados.
La implicación común es arquitectónica: la seguridad tiene que seguir el recorrido de la acción, no solo el login.
La identidad debe sobrevivir a la delegación
Imaginemos que un empleado pide a un agente cambiar un registro de proveedor. El agente puede llamar a un orquestador, que invoca un agente especializado de compras, que accede a una herramienta MCP, que escribe en el ERP.
En esa cadena pueden existir cinco identidades:
- humano solicitante;
- agente conversacional;
- orquestador;
- agente delegado;
- service principal o credencial de herramienta.
Si la escritura final solo registra la cuenta de servicio, se pierde responsabilidad. Si todos los componentes heredan todo el acceso del empleado, el privilegio se propaga demasiado.
El patrón correcto es delegación acotada: preservar quién inició la petición, qué agente actúa, qué propósito se autorizó y qué subconjunto de autoridad fue delegado.
El mínimo privilegio pasa a ser específico de la tarea
Un rol general puede permitir leer cientos de objetos. Un agente que ejecuta un flujo de trabajo suele necesitar menos.
En lugar de conceder “acceso a compras”, definir capacidades como:
- leer ficha de proveedor;
- leer facturas del caso X;
- proponer cambio de cuenta bancaria;
- crear actualización en borrador;
- solicitar aprobación;
- confirmar actualización aprobada.
Aquí confluyen diseño de herramientas y seguridad. Una herramienta ERP genérica y gigantesca dificulta el mínimo privilegio. Capacidades pequeñas y semánticamente claras dan a la política algo concreto que permitir o denegar.
La memoria es una frontera de seguridad
La memoria agéntica es útil porque conserva contexto entre pasos y sesiones. También es un nuevo lugar donde pueden persistir datos sensibles, instrucciones envenenadas y autoridad obsoleta.
Una capa de memoria gobernada necesita:
- procedencia;
- propósito;
- retención;
- clasificación;
- control de acceso;
- revocación;
- separación entre preferencia del usuario y dato empresarial autoritativo;
- visibilidad sobre qué se recuerda y por qué.
“Recordarlo todo” no es una estrategia de memoria empresarial.
Verificar continuamente, no una sola vez
El principio de Zero Trust “verificar explícitamente” se vuelve dinámico con agentes.
Una tool call puede ser válida a las 10:01 e inválida a las 10:05 porque:
- cambió el estado del caso;
- expiró la aprobación;
- la fuente quedó obsoleta;
- el usuario perdió acceso;
- el agente superó presupuesto;
- cambió una señal de riesgo;
- la secuencia entró en un estado privilegiado.
Por eso las políticas necesitan contexto de runtime. Autenticar al comienzo de la sesión es necesario e insuficiente.
“Assume breach” significa diseñar contención
Un fallo o compromiso agéntico debe tener un blast radius limitado.
Controles de producción posibles:
- ejecución aislada;
- allowlists de egress;
- credenciales de vida corta;
- permisos por herramienta;
- límites transaccionales;
- escrituras reversibles;
- gates humanos para privilegios;
- rate limits;
- kill switches independientes del modelo;
- trazas completas de acción.
Un agente seguro no es aquel del que se presupone buen comportamiento, sino aquel cuyo mal comportamiento puede contenerse.
Los agentes de desarrollo pertenecen al mismo modelo
Los coding agents merecen especial atención porque pueden leer código fuente, proponer dependencias, modificar infraestructura y activar rutas de despliegue. Tratarlos como editores de texto mejorados infravalora su autoridad.
Acceso a repositorios, allowlisting de paquetes, secretos, permisos CI/CD y supply chain deben formar parte explícita de la política.
La experiencia puede ser conversacional. El modelo de seguridad debería parecerse a automatización privilegiada.
La visión de Lexdatum
Zero Trust para IA se entiende mejor como un plano de control que abarca identidad, herramientas, memoria, modelos, datos y comportamiento de runtime.
La pregunta empresarial ya no es solo “¿quién eres?”. Es:
¿quién pidió esto, qué agente actúa, con qué propósito, con qué autoridad delegada, contra qué estado actual y qué evidencia quedará después?
Cuando esas respuestas viajan con cada acción, la autonomía se vuelve gobernable y no simplemente poderosa.
Sources
- Microsoft Security — Advance Zero Trust for AI: New tools and guidance to secure AI agents and DevSecOps (2026-08-04)
- Databricks — AI governance guide (2026-08-21)
Nota de investigación: este análisis se basa en información pública disponible el 1 de septiembre de 2026. Las capacidades de producto, precios e interpretaciones regulatorias pueden cambiar. Las afirmaciones de proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad, financiero ni de inversión.