Hay una reunión que se repite en casi todas las empresas que adoptaron agentes. Legal, seguridad, tecnología, alguien de recursos humanos. El resultado es un documento: Política de uso de inteligencia artificial. Se aprueba, se circula, se sube al portal interno. Un trimestre después, nadie sabe si cambió algo.

El documento no es el problema. El problema es que una política que no está implementada como mecanismo no se incumple: se declara. Entre lo que la empresa dice que hace con sus agentes y lo que el sistema efectivamente les permite hacer hay una distancia que la literatura de gobernanza llama, sin más, la brecha de ejecución.

Este artículo trata de la arquitectura que la cierra. No de la ética de la IA en abstracto ni de la performance de los modelos —de eso ya escribimos—, sino de la capa que envuelve al modelo, de las decisiones que la componen y de cómo se reparte el alcance entre las áreas que lo usan. La tesis es simple: un harness empresarial no es una configuración de ingeniería, es una arquitectura de gobierno, y como toda arquitectura se diseña por partes.

Un trabajo académico lo describe mejor que cualquier consultora: la desconexión entre la gobernanza documentada y la realidad operativa no viene de la falta de políticas, sino de aplicar una arquitectura de gestión documental periódica a una adopción espontánea y continua. Las políticas se revisan una vez al año; los agentes se despliegan los martes.

La brecha toma tres formas concretas. La primera es de tiempo: la política se aprueba en un ciclo anual y las capacidades del modelo cambian cada pocas semanas. La segunda es de visibilidad: sin trazas, no hay forma de saber qué hizo el agente, con qué permiso y a pedido de quién. La tercera es de abstracción: «no compartas información sensible con herramientas no aprobadas» es una instrucción clara para una persona y una instrucción inejecutable para un sistema.

Los relevamientos de la industria son consistentes con ese diagnóstico. Entre las organizaciones que ya operan agentes, la mayoría declara que no puede imponer limitación de propósito —que el agente use una herramienta solo para el fin previsto—, que no puede detener rápido a un agente desbocado y que no puede aislar la IA de los sistemas sensibles. Y entre las que ya tienen agentes en producción, una minoría puede rastrear una acción hasta la persona que la autorizó.

Conviene decirlo sin eufemismos: vigilancia sin capacidad de frenar no es gobernanza. Es un registro. La diferencia entre las dos cosas es una decisión de arquitectura, y se toma una vez, no en cada incidente.

Un harness es la capa de ejecución que envuelve al modelo: el software y la configuración por los que un modelo recibe contexto, propone acciones, usa herramientas, conserva estado y produce efectos fuera de sí mismo. El modelo propone; el harness dispone.

Esa separación no es un detalle de implementación: es la base de toda la gobernanza. Como el modelo solo puede proponer una acción y es la implementación de la herramienta la que la ejecuta, existe un punto exacto donde se puede intervenir sin tocar el modelo. Ese punto es el harness, y es el único lugar donde una política se puede volver exigible.

En una empresa, la arquitectura del harness se ordena en cuatro capas, y cada una responde a una pregunta distinta:

• Orquestación. ¿Cómo se descompone la tarea, quién decide el próximo paso, cuándo se detiene? Define el techo de autonomía.
• Contexto y memoria. ¿Qué información ve el agente, cuándo, y qué sobrevive a la sesión? Define qué puede saber.
• Herramientas y permisos. ¿Qué puede tocar y con qué credencial? Define qué puede hacer. Es la capa donde vive casi todo el riesgo.
• Observabilidad. ¿Qué queda registrado y quién puede leerlo? Define qué se puede demostrar después.

La cuarta es la que más se posterga y la que decide si las otras tres sirven de algo. Sin trazas, una política es un conjunto de intenciones: no hay forma de auditar el cumplimiento ni de reconstruir un incidente.

Esas cuatro capas son la arquitectura. Qué se pone dentro de cada una —qué herramientas, qué datos, qué permisos, qué aprobaciones— es una decisión de configuración, y en una empresa no tiene una respuesta única: tiene una por disciplina. Antes de desarrollarlo conviene ver cómo el alcance del harness quedó definido por escrito en la primera guía estatal sobre el tema.

Hasta hace poco, «harness» era jerga de ingeniería. En septiembre de 2026 la Dirección de Señales de Australia (ASD), a través de su centro de ciberseguridad, publicó la primera guía de un organismo estatal que toma al harness —y no al modelo— como objeto de gobernanza. Su definición es la más limpia que hay: el harness es la capa que está por encima del modelo, todo lo que compone a un sistema agéntico salvo el modelo mismo. Si el modelo es el cerebro, el harness es el cuerpo.

La guía enumera qué entra en esa capa y llama scope a ese conjunto: interfaz de usuario, capa de política, gestor de contexto, interfaz con el modelo, registro de herramientas, sistema de permisos, entorno de ejecución, capa de conectores, memoria y sesión, y auditoría y observabilidad. Al puñado de ajustes que decide qué herramientas se exponen, qué está permitido, qué aprobaciones se exigen y qué conectores quedan conectados lo llama superficie de configuración. El vocabulario importa: el alcance del harness es una decisión explícita, no el residuo de cómo salió el producto.

Las cuatro capas que describimos antes son una lectura de ese alcance según la pregunta que responde cada una. La enumeración oficial importa por otra razón: separa dos grupos de componentes que suelen confundirse. Un grupo hace que el agente funcione —interfaz con el modelo, gestor de contexto, entorno de ejecución—. Otro hace que se gobierne: registro de herramientas, sistema de permisos, capa de política y auditoría. Solo el segundo implementa una política. Y es, casi siempre, el que quedó sin tocar.

Hay un punto incómodo en la guía que conviene no saltear. Los harness rara vez se construyen en casa: llegan dentro de un producto comercial, y quien lo compra no puede inspeccionar cómo lo implementó el proveedor. Eso convierte «¿cómo audito el harness?» en una pregunta de compras y de gestión de proveedores, no de ingeniería; y explica por qué el inventario de conectores y herramientas es hoy parte del análisis de riesgo de terceros. La consecuencia para el modelo empresarial es directa: si el alcance del harness se hereda del proveedor, lo único que queda por decidir dentro de la empresa es cuánto de ese alcance se le entrega a cada disciplina.

El error más común al escribir una política de agentes es escribir una sola. «Los empleados no compartirán información de clientes con herramientas no aprobadas» suena razonable y no le sirve a nadie, porque el empleado no existe. Lo que existe es alguien de legales que lee contratos, alguien de marketing que publica campañas, alguien de ingeniería que despliega, alguien de finanzas que concilia y alguien de personas que evalúa. Cada uno usa agentes distintos, sobre datos distintos, con consecuencias distintas. Una política que los trata a todos igual no es más exigente: es inaplicable, porque no dice qué le toca a cada uno.

La respuesta no pide cinco políticas nuevas. Pide una arquitectura —un harness— y un scope declarado por disciplina: el recorte concreto de la superficie de configuración para un área. El scope no es un anexo ni un documento aparte; es la misma política, instanciada donde se ejecuta. Y responde cinco preguntas, que respondidas por escrito ya son la mitad del trabajo:

1. Herramientas. Qué herramientas y conectores ve esa disciplina.
2. Datos. Qué categorías de información puede tocar.
3. Autonomía. Qué puede hacer sin preguntar: leer, resumir, preparar un borrador, proponer.
4. Compuertas. Qué exige aprobación, de quién, con nombre y apellido.
5. Evidencia. Qué queda registrado y quién lo lee.

Así se ve el ejercicio aplicado a cinco disciplinas de cualquier empresa mediana:

Dos reglas gobiernan el conjunto y son las que lo vuelven un modelo y no una lista.

El scope solo se angosta. Existe un suelo común —mínimo privilegio, sin salida de red hacia destinos no declarados, traza por paso, identidad por tarea— que rige para toda la organización, y cada disciplina puede agregar restricciones sobre él, nunca quitar. Si un área necesita una excepción, no se reescribe el scope: se documenta el desvío, con plazo y con responsable. Sin esta regla el scope se convierte en una negociación y la arquitectura en una sugerencia.

Cada scope tiene un dueño con nombre. El scope de ingeniería lo firma quien responde por ingeniería; el de personas, quien responde por personas. Tecnología y seguridad construyen el harness y operan los controles, pero no son los dueños del riesgo del negocio, y confundir los dos papeles es la forma más común de que la política termine sin responsable.

Ahí está el cambio de fondo: la superficie técnica es una sola y quien la acota es el negocio. El scope por disciplina es lo que convierte al harness en una arquitectura empresarial en lugar de una configuración de ingeniería.

Vale la pena ser preciso, porque este terreno se presta a la exageración. Casi todas las piezas de esta arquitectura ya tienen estándar, y ninguna empresa necesita inventarlas.

La autenticación delegada y el parámetro scope vienen de OAuth 2.0 (RFC 6749), y su endurecimiento de la práctica de seguridad vigente (RFC 9700). La evaluación por atributos —rol, disciplina, habilitaciones, contexto de la tarea— está formalizada en NIST SP 800-162, y el principio de decidir por sesión y no por pertenencia a la red, en NIST SP 800-207, que además fija la separación entre el punto que decide y el punto que aplica: el motor de políticas vive fuera del agente. Derivar capacidades de relaciones —quién se vincula con qué recurso— tiene su referencia directa en Zanzibar, el sistema de autorización de Google. Y la identidad de la carga de trabajo, efímera y verificable, es SPIFFE.

El tramo que más importa acá es el último: emitir un alcance acotado y explícito por sesión. Ahí las piezas están y no están al mismo tiempo. Existen el alcance estructurado y por tipo de operación (RFC 9396), el amarre del token a un recurso concreto (RFC 8707), el intercambio de tokens con trazabilidad de quién actúa (RFC 8693) y la autorización de servidores MCP apoyada en esas mismas bases. Lo que no existe es una especificación única que defina «el scope integral de un agente» cubriendo herramientas, datos, voz y tono, memoria y aprobaciones de una sola vez. Tampoco hay un formato canónico de registro de auditoría para las decisiones de política sobre agentes: es un hueco que las propias guías de organismos admiten.

Traducido: el patrón se sostiene sobre estándares, pero se arma como práctica de ingeniería. Eso no lo debilita, lo vuelve más urgente. Quiere decir que el día que la norma pida «límites de propósito», cada empresa va a tener que mostrar su propia composición —y que quien ya la tenga escrita va a discutir sobre el diseño y no sobre la existencia.

Durante un tiempo, la gobernanza de agentes fue una decisión de criterio. Ya no: hay calendario.

El reglamento europeo de IA es el que más incomoda, y por una razón que se malinterpreta seguido. No obliga solo a quien construye el sistema: obliga a quien lo usa bajo su responsabilidad, la figura del deployer. Eso incluye a cualquier empresa que ponga un agente a operar sobre sus propios datos y sus propios clientes. En la práctica, ser deployer implica supervisión humana por personal idóneo, calidad y pertinencia de los datos de entrada, conservación de registros, notificación de incidentes, evaluación de impacto antes de operar sistemas de alto riesgo y —esto es lo que casi nadie tiene— transparencia frente al usuario: avisar que se está interactuando con una IA y etiquetar el contenido sintético.

El calendario se movió más de una vez y conviene mirarlo antes de citarlo: la alfabetización en IA rige desde febrero de 2025, las obligaciones de transparencia desde agosto de 2026, y las de alto riesgo vienen diferidas a 2027-2028. Las multas llegan hasta 15 millones de euros o el 3% de la facturación global.

NIST AI RMF no es obligatorio, pero es el vocabulario común del sector: cuatro funciones —gobernar, mapear, medir, gestionar— más un perfil específico de IA generativa que cataloga doce riesgos con acciones asociadas. Su punto débil es que se escribió antes de que hubiera agentes en producción: donde el marco asume un límite definible y una salida evaluable, un agente elige herramientas y el riesgo vive en la trayectoria.

ISO/IEC 42001 es el único de esta lista certificable: un sistema de gestión de IA con alrededor de cuarenta controles, aplicable tanto a quien provee como a quien usa. Se complementa con la 23894, que aporta el método de gestión de riesgo que la 42001 exige pero no detalla. Y por debajo están los principios de la OCDE y la recomendación de la UNESCO: útiles como marco de valores, sin capacidad de sancionar. La crítica que se les hace es justa: un principio sin mecanismo de aplicación habilita el lavado de reputación.

Hay además una pieza nueva que no es un reglamento, pero ordena el debate. La guía del ASD es advisory: no multa, no obliga. Aun así es el primer texto de un organismo estatal que pone al harness —y no al modelo— como el objeto a gobernar. Eso corre la pregunta de lugar: la ley dice qué hay que garantizar; la guía dice dónde se garantiza.

La consecuencia práctica es una sola: lo que la norma pide —supervisión, trazabilidad, límites de propósito, transparencia— es exactamente lo que un harness implementa. La regulación no llegó a exigir algo distinto de lo que la ingeniería ya venía necesitando. Y como el harness se configura por disciplina, cada obligación encuentra su lugar en un scope concreto en lugar de diluirse en un principio general.

Antes de escribir el esqueleto conviene tener claro qué se está cubriendo, porque la lista cambió. Los riesgos de un agente no son los de un chatbot.

La inyección de prompt indirecta es el más importante y el peor entendido. El agente no lee solo lo que le escribimos: lee lo que encuentra. Un documento, una página web, un ticket, la salida de otra herramienta. Cualquiera de esos textos puede contener instrucciones. El caso más citado es EchoLeak, el primer ataque de este tipo sin interacción del usuario contra un sistema en producción: un solo correo, sin abrir, bastaba para que el asistente exfiltrara información interna usando los permisos de la víctima. Se corrigió, pero la clase de riesgo quedó.

De ahí sale la lección contraintuitiva: la inyección no se arregla saneando lo que el agente lee, se acota limitando lo que puede hacer. Si el agente no tiene una herramienta con la que sacar datos, no hay inyección que lo haga sacar datos.

La agencia excesiva —el ítem LLM06 del OWASP Top 10 para aplicaciones con LLM— se descompone en tres causas que exigen tres remedios distintos: demasiadas herramientas disponibles (se resuelve con listas de permitidos), credenciales más amplias que la tarea (se resuelve con mínimo privilegio) y acciones de alto impacto sin punto de control (se resuelve con compuertas de aprobación). Es el riesgo que mejor muestra por qué el prompt no alcanza: la vulnerabilidad no está en los pesos del modelo, está en el permiso que le otorgamos. Y es, exactamente, lo que un scope declara.

Los casos de 2025 lo muestran con crudeza. En Amazon Q, alguien inyectó una instrucción destructiva en el repositorio de una extensión y la publicó como actualización, con cerca de un millón de instalaciones; lo único que evitó el borrado masivo fue un error de sintaxis. En Replit, un agente borró una base con más de mil registros durante una congelación de despliegues, generó miles de perfiles y reportes falsos, y afirmó que revertir el cambio era imposible —había copia de seguridad—. Ninguno de los dos fue un fallo del modelo. Los dos fueron fallos de permisos.

Y están los riesgos que no son de seguridad sino de responsabilidad. Air Canada perdió un reclamo por la información errónea que dio su chatbot, y el tribunal rechazó explícitamente que el bot fuera una entidad legal separada. iTutorGroup pagó por discriminación cuando su software de reclutamiento descartó candidatos por edad: «lo hizo el algoritmo» no fue defensa. Y Samsung prohibió las herramientas de IA generativa después de tres fugas de información confidencial en menos de un mes.

El hilo que une los cinco casos es el mismo que Simon Willison puso en una frase: la trifecta letal es tener acceso a datos privados, exposición a contenido no confiable y un canal de salida. Cualquier agente con las tres cosas es un incidente esperando su turno. La política y el harness existen para romper esa combinación.

La guía del ASD ordena todo lo anterior en cinco familias: riesgos de privilegio (permisos más amplios que la tarea), de diseño y configuración (conectores mal acotados), de comportamiento (inyección de prompt, envenenamiento de datos), estructurales (fallas que se propagan en cascada entre componentes) y de responsabilidad (no poder reconstruir quién decidió qué). Dos afirmaciones suyas conviene subrayar. La primera: la inyección de prompt no tiene mitigación técnica plenamente confiable, porque el modelo no puede distinguir de forma fiable una instrucción de un dato; el control tiene que vivir en el harness, acotando a qué puede llegar el agente y qué puede hacer. La segunda: a efectos de seguridad, un sistema multiagente debe tratarse como un solo agente, porque el límite de confianza es el mismo.

Una política de agentes no se sostiene por su extensión, sino por tres artefactos que la vuelven ejecutable y por un gobierno que los mantiene vivos. Los nueve contenidos que siguen son el estándar de la industria; el décimo es el que casi nunca está.

1. Propósito y alcance. Incluye a cualquiera que actúe por la empresa —empleados, contratistas, proveedores— y también a la IA usada indirectamente a través de herramientas ya licenciadas.
2. Roles y responsabilidades. Un comité transversal y una matriz de quién responde por qué. Sin esto, la conversación sobre responsabilidad ocurre por primera vez durante el incidente.
3. Clasificación y manejo de datos. Qué categoría de información puede tocar cada herramienta. Es el mapa que convierte «cuidado con la información sensible» en algo aplicable.
4. Registro de herramientas. La lista de aprobadas, toleradas y prohibidas. Es la sección que decide si la política vive o muere.
5. Verificación humana. Dónde es obligatoria y quién es la persona con nombre que responde por cada decisión.
6. Registro, monitoreo y auditoría. Qué se registra, con qué detalle y quién lo lee.
7. Reporte de incidentes. Un canal conocido, con plazo y sin castigo por reportar.
8. Control de accesos. Credenciales por tarea, rotación y mínimo privilegio.
9. Retención y enmascaramiento. Qué se guarda, cuánto tiempo y con qué protección.
10. Alcance por disciplina. Un scope por área, con las cinco preguntas respondidas y un responsable que lo firma. Es el que le da a los otros nueve un lugar donde aplicarse.

Los tres artefactos. El primero es el suelo común: los controles que rigen para toda la organización y que ninguna disciplina puede bajar. El segundo es el catálogo de scopes: un alcance escrito y firmado por disciplina, con sus cinco preguntas y su dueño. El tercero es el mapa de clasificación de datos, que es lo único que le permite a una persona decidir en el momento si puede pegar ese contrato en esa herramienta.

Dos de los diez contenidos hacen el resto del trabajo. La lista de herramientas es la que vuelve operativa la política: sin ella, el uso no declarado —lo que la industria llama shadow AI— pasa a ser técnicamente incumplimiento. Y el mapa de clasificación de datos es el que permite aplicar la política sin consultar a nadie.

Hay una cláusula que suele faltar y que conviene escribir textual: la responsabilidad final de cualquier decisión basada en una salida de IA es de la persona que la usa, no del sistema. No es una formalidad: es la que hace que existan las otras nueve.

Acá está el punto entero del artículo. Una política se vuelve real cuando cada cláusula tiene un control asociado, y ese control se activa en el scope de las disciplinas donde la cláusula tiene consecuencias. Sin esa traducción, la cláusula es una recomendación; con ella, es una condición de funcionamiento.

Seis ejemplos, cada uno con el scope donde vive.

Ninguno de esos seis controles es exótico ni caro: todos existen en cualquier plataforma seria de agentes. Cuatro viven en el suelo común y rigen para toda la organización; dos se activan solo en los scopes donde la cláusula tiene consecuencias. Lo que no existe, en la mayoría de las empresas, es la decisión de escribirlos: la política se redactó y el harness nunca se tocó.

Sería fácil terminar acá vendiendo el harness como solución. No lo es, y el contraargumento es serio.

Los guardarraíles que viven dentro del modelo —una instrucción de sistema, un clasificador que filtra— son probabilísticos. Un límite de gasto escrito en el prompt del agente existe mientras el agente lo respete. La diferencia es de naturaleza, no de grado: un control determinista falla el 0% de las veces, y uno probabilístico puede bloquear lo mismo nueve veces y dejarlo pasar la décima. Peor: suelen ser ciegos al estado —no pueden imponer una cuota entre sesiones— y se degradan justo en los contextos largos, que es donde más haría falta que funcionaran.

De ahí sale la regla que ordena todo el diseño: lo que tiene que cumplirse siempre va a la capa determinista —código, permisos, red— y el modelo queda como defensa en profundidad, nunca como único control. La distinción útil es entre gobernanza regulatoria, que sanciona después, y gobernanza constitutiva, que hace imposible la acción no conforme porque no hay con qué ejecutarla.

El límite es honesto y hay que decirlo: ningún componente del modelo convierte una coincidencia estadística en una garantía formal. El harness es necesario pero no suficiente, y por eso la política sobrevive como documento. No por su valor operativo, sino porque es el artefacto donde están escritos el rol, el aprobador y la evidencia que se va a pedir después del incidente. El harness ejecuta la política; la política explica, cuando algo salió mal, quién debía haberlo evitado.

Lo que sí cambió es dónde se discute la gobernanza. La conversación se mudó de la prosa al código, y el criterio maduró con ella: no un control único para todo, sino niveles de autonomía con salvaguardas proporcionales. El scope por disciplina es la forma operativa de ese principio: el mismo harness, con un alcance declarado distinto para quien redacta un borrador y para quien toca producción. Un agente que redacta y uno que despliega no necesitan la misma jaula, y tratarlos igual es la forma más rápida de que nadie respete ninguna.

El obstáculo real no es la convicción: es que «armá un harness para la empresa» suena a proyecto de seis meses. No lo es. Se empieza por la parte de la política que ya está escrita, se le busca el control y se implementa uno por semana.

1. Elegir una disciplina y un agente, no la organización. La política es general y el harness es concreto: se empieza por un área, con un caso que ya esté en producción y toque datos reales.
2. Escribir el inventario antes que la política. Qué agentes corren, con qué herramientas y con qué credenciales. Casi siempre sorprende: hay más de los que se creía.
3. Declarar el scope de esa disciplina. Las cinco preguntas —herramientas, datos, autonomía, compuertas y evidencia— puestas por escrito, con un responsable con nombre.
4. Traducir la primera cláusula a un control. Una sola, la que más miedo dé. El resto sigue cuando esa funciona.
5. Poner la traza antes de la próxima función. Sin registro no hay cumplimiento demostrable, ni aprendizaje.
6. Escribir dónde vive la regla. Si no está en un solo lugar y con dueño, no es un harness: es una costumbre, y las costumbres no se auditan.

Hay una prueba simple para saber si una empresa tiene gobernanza de agentes o solo un documento sobre agentes. La pregunta no es «¿qué dice la política?», sino «¿qué pasa si un agente intenta violarla?». Si la respuesta es «el modelo debería no hacerlo», hay un PDF. Si la respuesta es «no puede, no tiene con qué», hay un sistema.

Ese es todo el artículo. La política se escribe una vez; la arquitectura se construye, se versiona y se rompe. Lo único que no se puede hacer es aprobar la política y dar por cerrado el problema.

La responsabilidad no se delega en el modelo. Se delega, a lo sumo, en el sistema que lo contiene, y alguien tiene que firmar por ese sistema.

• OWASP — Top 10 for LLM Applications 2025 y Top 10 for Agentic Applications. Las listas canónicas de riesgo: LLM01 inyección de prompt (incluida la indirecta) y LLM06 agencia excesiva, con su descomposición en funcionalidad, permisos y autonomía; la segunda cubre ASI01 a ASI10, con secuestro de objetivo, abuso de herramientas y agentes descontrolados. genai.owasp.org — LLM Top 10 · genai.owasp.org — Agentic Top 10
• EU AI Act — obligaciones por rol. Qué le toca al deployer: supervisión humana, calidad de datos de entrada, retención de registros, reporte de incidentes, evaluación de impacto y transparencia frente al usuario. ai-eu-act.eu — requisitos por rol
• NIST — AI Risk Management Framework. AI 100-1 y el perfil de IA generativa (AI 600-1): cuatro funciones y doce riesgos con acciones mapeadas. nist.gov — AI RMF
• ISO/IEC 42001 e ISO/IEC 23894. El sistema de gestión de IA certificable, con alrededor de cuarenta controles, y el método de gestión de riesgo que lo complementa. iso.org — ISO/IEC 42001
• ASD — Agentic AI Harnesses: The Layer Above the Model. La primera guía de un organismo estatal que define el harness y su alcance: la capa por encima del modelo, sus componentes como superficie de configuración, cinco familias de riesgo y la advertencia de que la inyección de prompt no tiene mitigación técnica plenamente confiable. Advisory, no vinculante. cyber.gov.au — Agentic AI Harnesses
• Liu, J. A. — Engineering and Governing the Agent Harness (UNU, 2026). El harness como objeto de runtime que se puede documentar, evaluar, comprar y gobernar; la unidad de evaluación es el par modelo–harness, no el modelo suelto. unu.edu — Engineering and Governing the Agent Harness
• Anthropic — Zero Trust for AI agents. El modelo de confianza cero aplicado a agentes: identidad, alcance de permisos, sandbox y salvaguarda de memoria como capas separadas. claude.com/blog/zero-trust-for-ai-agents
• EchoLeak — CVE-2025-32711. El primer ataque de inyección indirecta sin interacción del usuario contra un sistema en producción, con severidad 9.3. ar5iv — EchoLeak
• Replit — el agente que borró la base en producción. Borrado durante una congelación de despliegues, miles de perfiles y reportes falsos, y una afirmación falsa sobre la imposibilidad de revertir. techtarget.com
• Amazon Q — la instrucción inyectada en el repositorio. Una instrucción destructiva publicada como actualización de la extensión, con cerca de un millón de instalaciones. zdnet.com
• Simon Willison — la trifecta letal. Datos privados, contenido no confiable y canal de salida: la combinación que convierte a un agente en un incidente. simonwillison.net — The lethal trifecta
• Responsabilidad legal — Moffatt v. Air Canada y EEOC v. iTutorGroup. La empresa responde por lo que dice su chatbot, y el software de reclutamiento discriminatorio se paga. americanbar.org — Air Canada · eeoc.gov — iTutorGroup
• Gartner — gobernanza de la IA agéntica. Niveles de autonomía con salvaguardas proporcionales, y el pronóstico de cancelación de proyectos agénticos por controles insuficientes. gartner.com — agentic AI oversight
• IETF — OAuth 2.0 y el alcance acotado. El marco base (RFC 6749), el alcance estructurado por tipo de operación (RFC 9396), el amarre del token a un recurso (RFC 8707), el intercambio con trazabilidad de quién actúa (RFC 8693) y la práctica de seguridad vigente (RFC 9700). Son las piezas estándar con las que se emite un scope por sesión. rfc-editor.org — RFC 9396 · RFC 8707 · RFC 8693 · RFC 9700
• NIST — control de acceso por atributos y confianza cero. SP 800-162 formaliza la evaluación por atributos de sujeto, objeto, operación y entorno; SP 800-207 fija la decisión por sesión y la separación entre el motor de políticas y el punto donde se aplica, que es lo que deja la traza fuera del agente. csrc.nist.gov — SP 800-207 · SP 800-162
• Zanzibar (USENIX ATC 2019) y SPIFFE (CNCF). El modelo de autorización por relaciones —quién se vincula con qué recurso— y el estándar de identidad de carga de trabajo con credenciales efímeras y rotadas, que le dan al scope un sujeto verificable. usenix.org — Zanzibar · spiffe.io — SPIFFE
• Model Context Protocol — Authorization. Cómo se autoriza un cliente contra servidores MCP, con autorización escalonada y rechazo de llamadas fuera de alcance. Es la pieza más cercana a un scope dinámico de herramientas y conectores. modelcontextprotocol.io — Authorization
• CISA/NSA con los Five Eyes — Careful Adoption of Agentic AI Services (2026), y NCSC del Reino Unido (2026). Las guías que exigen reemplazar credenciales estáticas por credenciales cortas y verificadas, identidad distinta y auditable por agente, y motores de política que rechacen en runtime lo que queda fuera del alcance acordado. cisa.gov — Agentic AI Services · ncsc.gov.uk — agentic AI