La autoridad no se posee, se hereda

Imaginemos un agente de IA al que se le pide resumir un documento. La tarea parece inofensiva: leer, sintetizar, devolver un texto más corto. Pero el documento contiene, oculta entre líneas, una instrucción que no proviene del usuario: elimina este archivo, exfiltra ese secreto. Es uno de los escenarios que el informático Nicola Gallo utiliza en su artículo Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents, publicado en arXiv el 9 de julio de 2026, y resulta útil comenzar precisamente por ahí porque muestra con precisión dónde se incuba el problema.

El agente, para realizar su trabajo, sostiene varias fuentes de autoridad al mismo tiempo: sus propias credenciales de servicio, un token delegado por el usuario y permisos específicos para cada herramienta que invoca. Cuando ejecuta la acción solicitada por el documento, no está necesariamente infringiendo ninguna regla técnica: posee, en algún lugar de su equipaje de credenciales, el permiso para eliminar archivos o acceder a ese secreto. El problema no es que le falte autorización. Es que ese permiso pertenece a una cadena de ejecución distinta de la que originó la solicitud en curso, y un control tradicional —que solo comprueba si el permiso existe y no de dónde proviene— no consigue distinguir ambos casos.

Gallo propone responder a esta cuestión con una estructura formal que denomina Proof-of-Continuity, construida dentro de un modelo más amplio bautizado como PIC, acrónimo de Provenance Identity Continuity. La tesis, simplificando al máximo: debéis dejar de razonar únicamente en términos de "quién tiene el pase en la mano" y comenzar a razonar también en términos de "cómo se ha propagado la autoridad desde el origen hasta aquí". Vale la pena comprender por qué y qué cambiaría realmente.

El problema de fondo: cuando tener el token ya no basta

Muchos sistemas de autorización transfieren la autoridad a través de objetos como tokens y credenciales: si poseéis el objeto adecuado, podéis hacer lo que el objeto autoriza. Existen ya familias de sistemas, los denominados sistemas basados en capacidades (capability-based systems), que resuelven bien la forma más sencilla de este problema —aquella con un solo paso entre quien solicita y quien ejecuta— porque vinculan de forma indisociable el permiso al acto mismo de invocarlo. La pregunta que plantea PIC concierne a un caso diferente: cuando la autoridad atraviesa múltiples servicios, múltiples agentes y múltiples fronteras de ejecución en secuencia, ¿puede quien la recibe verificar realmente que esa autoridad pertenece precisamente a la cadena que se está continuando, o solo está comprobando que el objeto es válido?

El nombre técnico de este problema tiene casi cuarenta años. En 1988, el ingeniero Norm Hardy relató, en un breve artículo convertido en clásico de la seguridad informática, The Confused Deputy, un episodio real ocurrido en la empresa de tiempo compartido Tymshare. Un compilador FORTRAN, instalado en un directorio privilegiado, tenía permiso para escribir estadísticas de uso en un archivo propio. Un usuario lo invocó pidiéndole escribir la salida de depuración en un archivo que, por un simple error de ruta, coincidía con el archivo de facturación de la empresa. El compilador, utilizando su autoridad sobre el directorio, sobrescribió los datos de facturación. El usuario nunca había tenido permiso para tocar ese archivo y, por lo tanto, nunca habría podido autorizar esa acción. El compilador, en cambio, sí poseía ese permiso por cuenta propia y lo ejerció como consecuencia directa de una solicitud que no lo justificaba. He aquí el "diputado confundido": un intermediario que posee una autoridad ajena a la solicitud que está atendiendo y la utiliza de todos modos, con total buena fe, produciendo una acción que el solicitante nunca habría podido autorizar por sí solo.

Hay una película que narra exactamente esta patología con una precisión casi profética, y es Brazil de Terry Gilliam: toda la trama gira en torno a un insecto aplastado sobre una impresora que transforma el nombre "Tuttle" en "Buttle", y a partir de ese momento el aparato burocrático del estado, actuando escrupulosamente según sus procedimientos, detiene y persigue al hombre equivocado. Ningún funcionario de la película es malvado o corrupto: cada uno ejerce fielmente la autoridad que posee, formalmente válida, pero ha perdido el vínculo con la causa correcta. Es la misma distancia entre posesión y continuidad que el artículo formaliza para el software.

De la "posesión" a la "continuidad": la idea central

Aquí reside el núcleo de la propuesta. En lugar de preguntarse únicamente "quién posee la autoridad para hacer esto", el modelo pregunta "¿es esta autoridad una continuación verificable de la que generó toda la cadena, o bien procede de otra ejecución, o de una fuente independiente aparecida a lo largo del camino?".

La metáfora más intuitiva es la del pase de concierto con varios accesos: en cada puerta se sella, y cada sello solo puede añadir restricciones, nunca quitarlas. Un pase que da acceso a la pista puede ser reducido, en el segundo acceso, a un acceso solo a la grada, nunca lo contrario. Si un paso intenta presentar más autoridad de la recibida, la seguridad lo detiene: la cadena se ha roto y la ejecución no prosigue.

Pero restringir por sí solo no basta. Hace falta también que cada paso demuestre estar realmente conectado, causalmente, con el paso inmediatamente anterior, y no con otro similar por azar. Es la combinación de ambas cosas —restricción de permisos y vínculo causal probado— lo que garantiza que ningún privilegio ausente en el origen pueda aparecer más adelante haciéndose pasar por parte de la misma continuación legítima.

Bajo el capó: los tres principios del modelo PIC

El nombre PIC no es una etiqueta casual, y vale la pena desglosarlo porque ayuda a recordar la estructura de todo el modelo. El sitio web oficial del proyecto, pic-protocol.org, lo presenta como tres principios distintos que trabajan juntos.

Provenance, la procedencia: la cadena causal debe ser siempre rastreable, de principio a fin, y si se interrumpe, la ejecución se detiene. Identity, la identidad: identifica al sujeto del que puede originarse la autoridad, ya sea el inicio de sesión de un usuario o una directiva empresarial, pero no exige que esa identidad se propague inalterada en cada paso posterior. Lo que debe seguir siendo verificable es que la autoridad ejercida pertenezca aún a la cadena de ejecución específica que se está continuando. Continuity, la continuidad: en cada paso debéis demostrar que estáis conectados causalmente con el paso anterior, y la autoridad solo puede restringirse, nunca expandirse.

Aquí conviene aclarar también una posible confusión terminológica. En el artículo, PIC es el nombre del modelo formal en su conjunto, mientras que Proof-of-Continuity es la propiedad de extremo a extremo que se obtiene componiendo dos elementos a lo largo de toda la cadena: cada prueba individual de relación local —lo que el artículo denomina Proof-of-Relationship— y la restricción de que la autoridad nunca se expanda de un paso al siguiente. En una frase: demostráis cada vínculo local, verificáis que la autoridad nunca crezca, y la suma de estas dos condiciones establece la continuidad desde el origen hasta el paso actual.

Hay un detalle que el propio autor aclara en las conclusiones del artículo porque previene un malentendido común: el término "Identity" no significa que la identidad del usuario deba viajar, repetida en cada paso, a lo largo de toda la cadena. La misma identidad, con exactamente los mismos privilegios, puede participar en ejecuciones completamente distintas: lo que las distingue no es la identidad, es la cadena causal específica a la que pertenecen. Es un cambio conceptual sutil pero importante: la carga de la autorización se desplaza de la constante reinterpretación de "quién sois" a la verificación de "¿es esto realmente una continuación legítima de esa ejecución específica?".

El teorema que cierra las puertas

La parte más elegante del artículo, y también la de mayor peso para quienes diseñan sistemas reales, es un teorema que demuestra cómo tres propiedades, todas deseables, no pueden coexistir en ningún sistema de propagación de autoridad: primero, que la autorización sea invariable respecto a la historia, es decir, que no importe cómo se ha llegado a cierta acción sino solo si se posee el permiso; segundo, que un servicio pueda mantener legítimamente una autoridad propia independiente de la de la solicitud, lo cual en la práctica es casi siempre necesario; tercero, que el diputado confundido sea estructuralmente imposible.

La demostración es más un razonamiento por exclusión que un cálculo: si un ejecutor puede mezclar su propia autoridad con la de la solicitud, y si el control de autorización no lee de ningún modo qué cadena específica ha causado la acción, entonces existirán situaciones en las que una autoridad auténtica, pero perteneciente a otra ejecución, acabe atribuida a la solicitud equivocada. No es un defecto de implementación; es una consecuencia directa de qué información elige ignorar la decisión de autorización.

La consecuencia práctica es más interesante que el propio teorema. Renunciar a la segunda propiedad (prohibir que un servicio tenga autoridad propia) es casi siempre inviable: una pasarela de pago debe poder mover fondos con su propia autorización bancaria, no solo con la del usuario. Renunciar a la tercera significa aceptar que el diputado confundido siga siendo posible, lo cual es sencillamente inseguro. Para los sistemas que desean mantener ambas propiedades —autoridad independiente de los ejecutores y protección frente al diputado confundido—, la elección practicable pasa a ser renunciar a la primera: hacer que la autorización sea sensible a la cadena causal específica que ha generado la acción, y no invariable respecto a su historia. El artículo resume este punto con una frase eficaz: una acción puede ser espacialmente válida pero temporalmente inválida, es decir, el permiso existe y es auténtico, pero pertenece a la causa equivocada.

PoR y PoC: los bloques operativos

El modelo se construye sobre dos conceptos distintos pero articulados. El Proof-of-Relationship es la prueba local, de un solo salto: demuestra que un paso de la ejecución es la continuación causal legítima del paso inmediatamente anterior, no de uno cualquiera que se le parezca. El Proof-of-Continuity es, en cambio, la composición de todos estos vínculos a lo largo de toda la secuencia, junto con la verificación de que la autoridad nunca se ha expandido: si cada eslabón individual se mantiene y ningún paso ha ganado privilegios, toda la cadena está verificablemente conectada al origen.

Una aclaración útil: Proof-of-Relationship no es una categoría particular de token; es una propiedad verificable de la relación entre dos pasos. Un artefacto de continuación vinculado al predecesor específico puede aportar la evidencia necesaria para realizar concretamente esta propiedad, pero solo bajo una condición: que quien lo reciba verifique efectivamente ese vínculo en su decisión. La simple posesión del artefacto, por sí sola, no basta. Este detalle desmiente la idea de que Proof-of-Possession y Proof-of-Continuity sean enfoques rivales: el primero prueba el control sobre un objeto en un instante, el segundo prueba que ese instante está realmente conectado causalmente con todos los que lo precedieron. Una arquitectura de aplicación (enforcement) acompaña a la ejecución generando y verificando las pruebas para esta tarea según el artículo, sin que el modelo imponga necesariamente un componente físicamente separado.

El caso que el artículo pone realmente sobre la mesa

Volvamos al escenario del agente y del documento con la instrucción oculta, porque el artículo lo trata con un rigor que merece ser transmitido fielmente. Si el contexto de autoridad de origen solo autoriza la operación "resumir este documento", entonces, bajo Proof-of-Continuity, una operación como "eliminar este recurso" o "exfiltrar este secreto" nunca podrá resultar una continuación válida, independientemente de lo que el documento intente sugerir. El agente puede incluso intentar físicamente la acción: el modelo no pretende hacerla físicamente imposible, pero un sistema conforme no puede aceptarla como un resultado legítimo de esa cadena, porque ese privilegio simplemente no figura en el conjunto heredado del origen.

El artículo propone también un caso más sutil, útil para comprender la precisión de la restricción: un ejecutor tiene acceso legítimo a dos permisos distintos, uno de lectura y uno de escritura, cada uno válido para una solicitud diferente en curso al mismo tiempo. Si ese ejecutor combina ambos permisos atribuyéndolos a una sola de las dos solicitudes, cada permiso individual sigue siendo auténtico, pero la combinación pertenece a la cadena equivocada. Es el mismo principio que el ejemplo del documento, aplicado a un caso aún más traicionero porque ninguno de los dos permisos, tomado por separado, parece sospechoso.

Este no es un escenario de laboratorio aislado. La inyección de prompts indirecta, es decir, instrucciones maliciosas ocultas en contenidos que el agente procesa, es hoy uno de los vectores de ataque más debatidos para los sistemas basados en agentes. La especificación de autorización del Model Context Protocol, el estándar con el que los agentes de IA se conectan hoy a herramientas externas, impone que cada token esté vinculado a un destinatario preciso y prohíbe explícitamente transmitir un token recibido para un servicio hacia otro servicio diferente más adelante. Es un remedio real, ya en producción, pero sigue siendo un control puntual, verificado salto a salto: establece para qué servicio se ha emitido un token, no demuestra por sí solo que la acción actual sea la continuación causal de toda la cadena que originó esa autoridad. Es de nuevo la diferencia entre posesión vinculada y continuidad demostrada.

El problema de los diferentes vocabularios

Existe un obstáculo práctico que el artículo aborda explícitamente: en un sistema real, cada salto habla a menudo un lenguaje diferente. Un endpoint REST describe los permisos de una forma, un scope OAuth de otra, un rol de base de datos de una tercera. El artículo introduce así una función de traducción entre vocabularios, que permite hacer pasar la autoridad de un sistema de permisos a otro sin violar nunca la restricción de no expansión.

Sin embargo, hay una condición importante que se debe tener en cuenta: el modelo considera esta traducción como un dato de partida, una elección de directiva (policy), no algo que demuestre por sí solo. Si la traducción es demasiado generosa y termina concediendo más de lo debido, se trata de un error en la configuración de esa traducción específica, no de una falla en la lógica del modelo. Es como traducir un contrato de un idioma a otro: si la traducción añade derechos que el original no preveía, el error reside en la traducción, no en el principio de que un contrato debe respetarse.

Cómo podría construirse realmente

El artículo es explícitamente un modelo, no un manual de implementación: la construcción concreta del Proof-of-Relationship se declara fuera de alcance y se delega a una arquitectura de aplicación complementaria. Para la escalabilidad, sugiere que no es necesario revalidar toda la historia en cada salto; bastan puntos de control (checkpoints) o pruebas resumidas que permitan a cada paso demostrar su lugar en la cadena sin arrastrar todo el pasado.

Lo que hace que este trabajo sea más que un ejercicio académico es que ya hay una implementación concreta en marcha bajo el mismo paraguas. El proyecto PIC-X parte de una autoridad ya existente, por ejemplo un token OAuth, deriva un contexto de autoridad PIC inicial y produce artefactos firmados concretos, como tokens JWT dedicados y estructuras COSE, manteniendo la restricción de no expansión a lo largo de todo el recorrido. En el terreno del código público, existen ya paquetes de código abierto vinculados al proyecto, como una librería en Rust que implementa la lógica de verificación de las pruebas de continuidad, junto con una especificación técnica publicada abiertamente. Todavía no es un estándar, pero es la prueba de que el salto de la teoría a la práctica ya ha comenzado.

Los límites que el propio autor reconoce

Debe señalarse con la misma claridad lo que el modelo aún no cubre, porque el propio artículo dedica una sección honesta a sus límites. El modelo formal publicado en el artículo del 9 de julio, por admisión propia, solo describe cadenas lineales: un paso tras otro, sin ramificaciones. Los escenarios en los que un agente delega una tarea a dos subagentes en paralelo se mantienen indicados como extensión futura en ese texto. Desde entonces, el proyecto ha comenzado a abordar, en materiales formales posteriores, el caso más sencillo de fan-out —dos continuaciones "hermanas" que nacen del mismo punto de la cadena—; la composición, es decir, la convergencia de cadenas independientes en un único resultado, sigue siendo en cambio un problema distinto, con reglas aún por definir.

Resulta tentador pensar aquí en Jorge Luis Borges y su El jardín de senderos que se bifurcan: el relato imagina una novela, y en el fondo un destino, en el que cada bifurcación no elimina las alternativas, sino que las hace coexistir en tiempos paralelos. El modelo de Gallo, por el momento, sabe caminar bien por un solo sendero a la vez; conseguir que sea capaz de gestionar las bifurcaciones sin perder la garantía de que ninguna rama adquiera más autoridad que el tronco del que nace sigue siendo el problema abierto.

Existen otros límites declarados. La revocación no se trata como una operación retroactiva sobre una cadena ya en curso: queda por definir si revocar bloquea solo las transiciones futuras o invalida también las ya emitidas. Y existe un riesgo de seguridad más sutil, señalado por el propio autor: el modelo vincula la autoridad dentro de una cadena ya iniciada, pero no decide por sí solo cuándo un ejecutor puede abrir legítimamente una nueva cadena propia. Distinguir una acción realmente autónoma de una que solo está disfrazada de tal —es decir, causada en realidad por una solicitud externa— sigue siendo, por admisión explícita del artículo, una responsabilidad de la arquitectura de aplicación, no del modelo en sí.

Qué cambia para quienes desarrollan, diseñan o deciden

Para quienes escriben agentes y herramientas, la pregunta útil que deben hacerse ante cada acción se vuelve sencilla de formular, aunque no trivial de responder: cuál es el origen de esta autoridad, si esta operación es realmente una continuación directa de la intención inicial y si, al mezclar varias fuentes de autoridad, las están manteniendo separadas o fusionándolas sin darse cuenta.

Para quienes diseñan plataformas e infraestructuras, el artículo sugiere introducir metadatos de procedencia en las llamadas entre servicios, evaluar componentes de aplicación dedicados (ya sean sidecars, pasarelas o middleware) y considerar la continuidad como un criterio con el que juzgar los marcos de orquestación multiagente antes de adoptarlos.

Para quienes se ocupan de la seguridad y toman decisiones a nivel empresarial, el modelo ofrece un léxico preciso para evaluar el riesgo de escalada silenciosa en las canalizaciones automatizadas, y un argumento sólido para incluir la trazabilidad de la cadena causal entre los requisitos mínimos de seguridad de los sistemas autónomos, no como información útil únicamente para una auditoría posterior, sino como una propiedad que la decisión de autorización utiliza activamente.

Conclusiones

Permanece abierta la pregunta más grande, la que el propio artículo plantea sin responder: qué estándares existentes, desde OIDC hasta OAuth o los sistemas de capacidades, terminarán incorporando algo similar a la continuidad, y con qué coste en términos de complejidad para quienes desarrollan.

Sin embargo, el artículo es claro en un punto que conviene mantener como clave de lectura final: posesión, relación y continuidad no demuestran la misma cosa. La posesión demuestra el control sobre un objeto en un instante dado. La relación demuestra el vínculo causal entre dos pasos consecutivos. La continuidad demuestra que la autoridad ha atravesado toda la cadena sin expandirse nunca. Esto no hace que los tokens, las credenciales o las pruebas de posesión sean erróneos: simplemente traslada la pregunta a otra dimensión. Dos acciones pueden tener el mismo sujeto, el mismo token, incluso el mismo permiso, pero arrojar resultados de autorización diferentes porque proceden de causas distintas.

Este es el cambio conceptual central: la autoridad ya no es únicamente algo que un sujeto posee en un instante dado. Cuando se propaga a través de una ejecución distribuida, debe seguir siendo una continuación verificable de la autoridad que causó esa ejecución específica, no afirmarse una sola vez al principio para darla por sentada hasta el final.