Propagación de la autorización: por qué el control de acceso a nivel de solicitud no es suficiente

El debate sobre la seguridad en torno a los agentes de IA ha estado dominado durante tanto tiempo por un único ataque —la inyección de prompts— que un problema estructural más silencioso ha pasado desapercibido. Ahora tiene nombre: propagación de la autorización, propuesto en un preprint de arXiv de mayo de 2026 de un solo autor de Kamiwaza (que informa sobre evidencia de implementación preliminar), "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Tallam, arXiv:2605.05440), cuya tesis podemos exponer con sus propias seis palabras citadas —"We call this problem authorization propagation"— y parafrasear en una sola frase: a medida que los principales no humanos recuperan datos, delegan tareas y sintetizan resultados a través de límites cambiantes, el problema difícil es mantener los invariantes de autorización a lo largo de la cadena, y no es reducible a la inyección de prompts ni está totalmente resuelto por los modelos clásicos de control de acceso —RBAC, ABAC, ReBAC— que las empresas ya utilizan. El documento descompone el problema en tres subproblemas con nombre que cualquier operador de múltiples agentes reconocerá en cuanto se planteen. Delegación transitiva: el agente A, autorizado para una tarea, delega una subtarea al agente B: ¿qué puede hacer B, bajo la autoridad de quién y qué impide que la cadena se amplíe en cada salto? Inferencia de agregación: cada recuperación en un flujo de trabajo está permitida individualmente, pero la síntesis reúne algo que ningún principal estaba autorizado a ver. Validez temporal: la autorización era válida cuando comenzó el flujo de trabajo; ¿sigue siendo válida en el paso cuarenta, una hora después, tras haber sido revocada la concesión? Estas son propiedades a nivel de flujo de trabajo, no a nivel de solicitud, que es precisamente la razón por la que la maquinaria de nivel de solicitud de las últimas dos décadas no las resuelve. Esta guía es la referencia empresarial para el término: qué es la propagación de la autorización, de dónde viene, en qué se diferencia de los problemas en los que se suele clasificar, y la infraestructura que puede respaldar invariantes seleccionados para las operaciones participantes, mientras que la inferencia de agregación sigue siendo, según el propio documento, un problema abierto que ninguna arquitectura actual resuelve por completo; según el propio subtítulo del documento: gobernanza de la identidad como infraestructura. Como ocurre con todas nuestras referencias de términos recientes, mantendremos esta página actualizada a medida que evolucionen la investigación y el vocabulario.

¿Qué es la propagación de la autorización? Una definición

La propagación de la autorización es el problema de preservar invariantes de autorización — las garantías sobre quién puede acceder a qué, establecidas al inicio de un flujo de trabajo, a medida que el trabajo de dicho flujo es ejecutado por múltiples agentes no humanos que recuperan datos, se delegan tareas entre sí y sintetizan resultados a través de los límites del sistema. El paso definitorio que hace que el término sea útil es el cambio en la unidad de análisis: el control de acceso clásico evalúa una solicitud (este agente, este recurso, este momento) y se resuelve en gran medida en ese nivel de granularidad; la propagación de la autorización evalúa un flujo de trabajo — la cadena de solicitudes, delegaciones y combinaciones — y se pregunta si la autoridad presente al inicio se mantiene fielmente en cada salto y hasta el resultado final. Los tres subproblemas nombran las formas en que esto falla. Delegación transitiva: cuando el agente A delega en B y B en C, cada salto es una oportunidad para que la autoridad se amplíe — B operando con las credenciales de A más las suyas propias, C acumulando ambas — hasta que una acción en lo profundo de la cadena se ejecuta con un conjunto de permisos efectivos que ningún humano otorgó jamás; el clásico "diputado confuso" es el ancestro de un solo salto de este problema, que ahora se complica según la longitud de la cadena. Inferencia de agregación: las cinco recuperaciones de un agente de investigación están autorizadas individualmente, pero la síntesis — bandas salariales combinadas con organigramas y notas de rendimiento — constituye una divulgación a un nivel de sensibilidad que ninguna de las concesiones individuales implicaba; las comprobaciones a nivel de solicitud pasan cinco veces mientras que el invariante a nivel de flujo de trabajo falla una vez, de forma invisible. Validez temporal: los flujos de trabajo de los agentes se ejecutan durante mucho tiempo — horas, días, de forma permanente — mientras que las concesiones se revocan, los roles cambian y los tokens caducan; una autorización comprobada solo en el primer paso es una instantánea presentada como una garantía. Una aclaración para búsquedas relacionadas: esto no es autenticación (probar quién es un agente — el prerrequisito, cubierto en la literatura sobre MCP-auth), no es inyección de prompts (un ataque de manipulación; este problema no necesita un atacante), y no es autorización en general — es específicamente la propagación de la autorización a través de un trabajo de múltiples agentes, múltiples pasos y que cruza límites.

Una breve historia: de los diputados confusos a los agentes no humanos

La ascendencia del problema es décadas más antigua que el término, lo cual es parte de la razón por la que la denominación es importante. El diputado confuso — un programa privilegiado al que se engaña para que haga un uso indebido de su autoridad en nombre de quien lo llama — fue descrito en 1988 y dio forma al pensamiento sobre seguridad basada en capacidades durante una generación; los flujos de delegación de OAuth, las aserciones SAML y los debates sobre suplantación frente a delegación de la era SOA fueron respuestas parciales para un mundo donde los agentes eran aplicaciones y las cadenas eran cortas. La década de 2010 añadió escala pero no forma: los microservicios convirtieron la identidad de servicio a servicio en una disciplina (mTLS, SPIFFE, identidad de carga de trabajo), y la industria de IAM comenzó a hablar de identidades no humanas superando en número a las humanas. Lo que cambió entre 2024 y 2026 es que los agentes no humanos se volvieron autónomos y composicionalesagentes que deciden en tiempo de ejecución qué herramientas invocar, generan subagentes con subconjuntos (o superconjuntos accidentales) de su autoridad y sintetizan todo lo que han tocado; cadenas largas, dinámicas y no planificadas, exactamente de las formas que la maquinaria clásica descartaba. El discurso siguió esta deriva de forma fragmentada: guías de autenticación y autorización de MCP, marcos de trabajo de confianza cero para agentes, la ola de seguridad centrada en la identidad, nuestro propio censo de identidad de agentes — hasta mayo de 2026, cuando el informe Kamiwaza delimitó todo el asunto: nombró el problema, lo separó de la inyección, formalizó los tres subproblemas y derivó siete requisitos estructurales para arquitecturas que mantienen los invariantes. Nuestro marco de referencia actual se mantiene: la denominación sigue a la práctica —toda empresa que ejecuta flujos de trabajo multiagente tiene estos tres problemas hoy, con nombre o sin él— y la denominación es el momento en que las preguntas de adquisición comienzan a plantearse en la unidad de análisis correcta, que es el flujo de trabajo, no la solicitud.

Propagación de autorización frente a inyección de prompts, RBAC y autenticación

Tres contrastes sitúan el término, y cada uno es un error de clasificación común que se corrige. Frente a la inyección de prompts: la inyección es un ataque —un adversario que manipula a un agente para que haga un uso indebido de la autoridad que posee legítimamente—; los fallos de propagación no necesitan un adversario: la delegación ordinaria, la síntesis útil y los flujos de trabajo de larga duración los producen por defecto, lo que significa que un entorno puede estar protegido contra inyecciones y aun así sufrir filtraciones a través de su propia infraestructura de permisos. Se cruzan (un agente inyectado con un conjunto de permisos efectivos ampliado es un incidente peor), pero resolver uno no afecta al otro, y la queja central del informe es que el enfoque de la conversación sobre seguridad en la inyección dejó el problema estructural sin nombre. Frente a RBAC/ABAC/ReBAC: los modelos clásicos son lenguajes de políticas en tiempo de solicitud: entradas potentes y necesarias que, por sí solas, no prueban los invariantes a nivel de flujo de trabajo, porque una comprobación de rol no puede ver que la autoridad se acumuló a través de saltos, una regla por recurso no puede ver lo que la síntesis ensambló, y una política evaluada en el momento de la solicitud no puede ver que el flujo de trabajo al que pertenece comenzó bajo concesiones que ya han sido revocadas. Los modelos son entradas para una solución, no la solución en sí: los invariantes residen en una capa que esos modelos no evalúan. Frente a la autenticación: saber quién es cada principal —los flujos OAuth, el intercambio de tokens, la identidad de la carga de trabajo— es el requisito previo sobre el que se construye este problema; la propagación es lo que debe mantenerse después de que todos estén correctamente identificados, razón por la cual "tenemos SSO para nuestros agentes" responde a una pregunta diferente a la que plantea este término . El resumen en una línea de los tres contrastes: la industria ha pasado dos años asegurando la solicitud y el prompt; la propagación de autorización es la seguridad de la cadena.

Propagación de la autorización en la empresa: la gobernanza de la identidad como infraestructura

Aquí es donde entra TrueFoundry, y el subtítulo del artículo ya ha definido la forma del argumento: los invariantes no pueden mantenerse pidiendo a cada equipo de agentes que los implemente; deben ser propiedades de la capa que atraviesa cada llamada de agente. Analicemos los tres subproblemas frente al mecanismo documentado. Delegación transitiva se rige donde ocurre la delegación: el alcance de la herramienta del agente fluye a través del MCP Gateway, donde la delegación por usuario significa que una llamada descendente lleva la autoridad del principal de origen hacia cada sistema —el CRM ve los permisos del usuario, no los del agente— y el alcance basado en tareas significa que lo que recibe un agente generado es un reducido arrendamiento derivado del de su padre, nunca un superconjunto acumulado; el invariante "la autoridad puede reducirse, nunca ampliarse" se convierte en una propiedad estructural de cómo se emiten las credenciales en lugar de una convención que los equipos deban recordar, la disciplina que nuestro análisis TBACyOAuth en la capa MCP trabajo desarrolla en profundidad. Validez temporal se convierte en una propiedad del token en lugar de una promesa del flujo de trabajo: las credenciales de corta duración, autorrenovables y revocables centralmente significan que una concesión revocada en el paso doce hace que la llamada a la herramienta falle en el paso trece; la comprobación se vuelve a ejecutar en cada salto porque cada salto cruza el plano, que es el único lugar donde se puede responder continuamente a "¿sigue siendo válido ahora?" para un flujo de trabajo que sobrevive a sus condiciones iniciales. Inferencia por agregación es el caso difícil y honesto —ninguna puerta de enlace calcula la sensibilidad de una síntesis en términos generales— y la contribución de la infraestructura es hacerlo gobernable: a nivel de cadena trazas de solicitud registra las recuperaciones mediadas y las llamadas con sus identidades resueltas (evidencia para la revisión de auditoría de las operaciones participantes, no un veredicto de autorización automática sobre lo que el flujo de trabajo ha ensamblado); los mecanismos de protección en las salidas de las herramientas y las respuestas del modelo refuerzan los límites expresables (clases de PII, fuentes restringidas que pasan a salidas no restringidas); y la capa de coordinación multiagente que nuestro gobernanza A2A trabajo cubre mantiene los saltos entre agentes en el mismo plano auditado que los saltos de herramientas, de modo que la cadena no tenga segmentos oscuros. El documento solicita arquitecturas con requisitos estructurales; el plano es donde esos requisitos dejan de ser ingeniería por equipo y pasan a ser configuración.

Lista de verificación de propagación de autorización empresarial

Seis preguntas para cualquier entorno multiagente: ¿Cada salto de agente a herramienta y de agente a agente atraviesa una capa gobernada, o existen integraciones directas donde la cadena se vuelve oscura? ¿La delegación se implementa como derivación de credenciales — ¿ámbitos secundarios estrictamente dentro de ámbitos principales — en lugar de compartir credenciales? ¿Los sistemas intermedios ven la autoridad del principal de origen (delegación por usuario) en lugar de la autoridad ambiental de una cuenta de servicio? ¿Son las credenciales de corta duración y revocables centralmente, de modo que la validez temporal se restablezca en cada salto en lugar de asumirse desde el primer paso? ¿Puede un auditor reconstruir la huella completa de recuperación y síntesis de cualquier flujo de trabajo a partir de los registros? ¿Y hay alguien responsable de la cuestión de la agregación: revisar lo que ensamblan los flujos de trabajo de altos privilegios, no solo a lo que acceden? Seis respuestas afirmativas equivalen a una gobernanza de identidad como infraestructura; las negativas son donde el cumplimiento de la cadena es pura coincidencia.

El futuro de la propagación de la autorización: lo que estaremos observando

Predicciones, con cautela. Es de esperar que el término recorra rápidamente el camino de la investigación a la práctica, porque —al igual que la degradación de la gobernanza, su término hermano de la temporada— nombra fallos que los operadores ya tienen: el subagente con permisos excesivos detectado en una auditoría, la síntesis que hizo estremecer al departamento legal, el flujo de trabajo que siguió ejecutándose con una concesión revocada; el vocabulario que explica los incidentes existentes se adopta en los análisis post-mortem. Cabe esperar que los organismos de normalización lo asimilen: los ecosistemas MCP y A2A ya están convergiendo en la semántica de delegación, y "¿cómo mantiene su protocolo los invariantes de autorización a través de los saltos?" es la pregunta precisa que el documento prepara a los revisores para hacer; apostaríamos a que el lenguaje de propagación aparecerá en las revisiones de seguridad de los protocolos de agentes a lo largo del año. Cabe esperar que la inferencia de agregación sea la frontera más difícil: la delegación y la validez temporal tienen respuestas estructurales claras; el "¿qué reveló la síntesis?" es un problema semántico que atraerá a los proveedores de clasificación de datos, DLP y barreras de salida a la conversación sobre agentes, con los registros a nivel de cadena como el sustrato que todos necesitarán. Cabe esperar que la ola de identidades no humanas de la industria IAM choque de forma productiva con este marco —la gobernanza NHI da nombres a los principales; la propagación es lo que los principales nombrados deben preservar— y cabe esperar que las adquisiciones compriman todo esto en una sola pregunta que esta página existe para ayudar a responder: no "¿tienen sus agentes identidades?" sino "¿mantienen sus cadenas sus invariantes?". Mantendremos esta guía actualizada a medida que evolucionen la investigación y el vocabulario; la afirmación duradera es el replanteamiento que el documento se ganó: los últimos dos años aseguraron la solicitud y el prompt; los próximos dos se centrarán en asegurar la cadena.

Preguntas frecuentes sobre la propagación de la autorización

¿Qué es la propagación de la autorización en los sistemas de IA?

La propagación de la autorización es el problema de mantener los invariantes de autorización a medida que múltiples agentes de IA recuperan datos, delegan tareas y sintetizan resultados a través de los límites del sistema, garantizando que la autoridad con la que comenzó un flujo de trabajo se preserve fielmente en cada salto. El término fue propuesto en un preimpreso de autor único de mayo de 2026 (arXiv:2605.05440), que lo descompone en delegación transitiva, inferencia de agregación y validez temporal.

¿En qué se diferencia la propagación de la autorización de la inyección de prompts?

La inyección de prompts es un ataque en el que un adversario manipula a un agente para que haga un mal uso de la autoridad que posee legítimamente. Los fallos de propagación de la autorización no necesitan un atacante: las cadenas de delegación ordinarias amplían la autoridad, las recuperaciones permitidas individualmente se sintetizan en divulgaciones no permitidas y los flujos de trabajo largos sobreviven a sus concesiones. Un entorno protegido contra inyecciones aún puede filtrar información a través de su propia infraestructura de permisos.

¿Por qué el RBAC o el ABAC no resuelven la propagación de la autorización?

Porque son modelos de tiempo de solicitud: una comprobación de rol o atributo evalúa a un principal, un recurso y un momento. Los fallos de propagación son a nivel de flujo de trabajo —autoridad que se acumula a través de los saltos, síntesis que exceden cualquier concesión individual, validez que expira a mitad de la cadena—, lo cual las comprobaciones a nivel de solicitud no pueden ver estructuralmente. Los modelos clásicos siguen siendo entradas necesarias; los invariantes deben aplicarse en la capa que cruza toda la cadena.

¿Cómo mantienen las empresas los invariantes de autorización a través de las cadenas de delegación de agentes?

Haciendo que los invariantes sean propiedades de la infraestructura: enrutar cada salto de agente a herramienta y de agente a agente a través de una puerta de enlace gobernada; implementar la delegación como derivación de credenciales con ámbito (para llamadas registradas de agente a agente enrutadas a través de la puerta de enlace de agentes, el intercambio de tokens con ámbito puede ayudar a preservar el sujeto, el actor, la audiencia y el ámbito autorizado, mientras que los subagentes de Harness actualmente comparten las herramientas y el entorno aislado de la ejecución raíz en lugar de recibir sobres de permisos restringidos de forma independiente); utilizar la delegación por usuario configurada cuando sea compatible, para que los sistemas intermedios puedan ver la autoridad del principal de origen; mantener las credenciales de corta duración y revocables centralmente para que la validez temporal pueda restablecerse en los saltos mediados, sujeto a la vida útil del token y a la semántica de validación posterior; y registrar los rastros de las operaciones mediadas para que la huella de recuperación y síntesis de un flujo de trabajo sea revisable para el plano participante.

Referencias

• Anchor — Tallam, "Propagación de la autorización en sistemas de IA multiagente: gobernanza de identidad como infraestructura" (Kamiwaza AI, arXiv:2605.05440, mayo de 2026: la acuñación; los argumentos de no reducibilidad a la inyección y más allá de RBAC/ABAC/ReBAC; los tres subproblemas; los siete requisitos estructurales).
• documentación de TrueFoundry —Puerta de enlace MCP (delegación por usuario; diagrama de arquitectura oficial);Autenticación y seguridad de MCP;rastros de solicitud y análisis (imagen oficial);barreras de seguridad.
• Este blog —TBAC: control de acceso basado en tareas;OAuth y gestión de tokens en la capa MCP;gobernanza multiagente A2A;el censo de identidad de agentes;puerta de enlace, proxy y router MCP.

Se utiliza una cita directa de menos de quince palabras, extraída del documento citado y atribuida en el texto; el resto de los argumentos, subproblemas y requisitos del documento se han parafraseado, por lo que se recomienda a los lectores consultar el original para obtener un tratamiento formal. La correspondencia entre los requisitos del documento y los mecanismos de TrueFoundry es una interpretación editorial nuestra; ni el autor del documento ni Kamiwaza AI mencionan ni respaldan a TrueFoundry. Las capacidades del producto se han parafraseado a partir de la documentación pública disponible en el momento de la redacción; las imágenes del producto son activos de la propia documentación de TrueFoundry, reproducidos con la debida atribución. Esta es una referencia viva que se revisará a medida que evolucionen la investigación y el vocabulario.

‍