La palabra "agente" no vino de la IA.
Vino del derecho.
Un principal autoriza a un agente para actuar en su nombre. Los actos del agente vinculan al principal. El principal es responsable de lo que el agente hace dentro de su ámbito. Esta estructura rige el sector inmobiliario, el gobierno corporativo, los servicios financieros y el derecho contractual. Los ha regido durante siglos.
Respondeat superior, o que responda el señor, se remonta al derecho romano.
Cuando un sistema de IA actúa en tu nombre, no estás dentro de una nueva categoría de producto. Estás dentro de una relación jurídica que se ha litigado durante cientos de años.
El derecho no necesitó conceptos nuevos para los agentes de IA. Ya los tenía. Lo que la industria tecnológica no tiene es confianza, y están aprendiendo rápido que no cuentan con las protecciones legales que antes indemnizaban a las plataformas.
El arco
Toda abstracción de software importante sigue el mismo patrón. La experiencia se reubica. No desaparece.
El SaaS trasladó la entrega de software a la nube. Dejaste de instalar. Saber qué software necesitabas siguió siendo tuyo.
El PaaS trasladó la infraestructura a la nube. Dejaste de montar servidores en racks. Saber qué construir siguió siendo tuyo.
Service-as-a-Software traslada la ejecución a la nube. Tú declaras la intención. Los agentes producen resultados. Saber qué resultado necesitas y si el agente lo logró sigue siendo tuyo.
Tu portátil ya no es el entorno de ejecución. Es la superficie de intención.
El cómputo que importa vive en sistemas en la nube que tu dispositivo no puede replicar. Modelos de 200 mil millones de parámetros a velocidad de inferencia. Canalizaciones de orquestación de 500 agentes. Síntesis en tiempo real a través de decenas de APIs de forma simultánea. El escritorio es el punto de autorización. La ejecución ocurre en otro lugar.
Esto no es una predicción. Es la arquitectura que está en producción ahora mismo, sin una capa de confianza. En nuestra opinión, por eso hay un aumento dinámico de incidentes de ciberseguridad: tecnologías maduras atornilladas sobre capas inmaduras que nunca se diseñaron para soportarlas.
La web agéntica ya se estaba construyendo
Los humanos construyeron la web agéntica sin ponerle nombre.
Los service workers interceptan solicitudes y actúan en nombre del principal fuera de su atención en tiempo real. Zapier e IFTTT son orquestación de agentes; un principal, múltiples agentes, ejecución basada en eventos, sin ninguna persona en el bucle. Stripe es un agente de pagos. Los operadores de Kubernetes gestionan el estado de la infraestructura de forma autónoma. ¡Los cron jobs son los agentes más antiguos de internet! Cron está programado, es autónomo y actúa sin supervisión desde los años setenta. Los rastreadores de búsqueda, los resolutores de DNS, los nodos de borde de las CDN, las autoridades de certificación: todos son agentes, todos actúan dentro de un ámbito definido mientras la atención del principal está en otra parte. Esta es la promesa de la automatización; el tiempo invertido en crear automatización le paga a nuestro yo futuro en tiempo libre.
El primer intento de delegación principal-agente a escala web se llamó OAuth.
OAuth demostró que la delegación era necesaria. También demostró el problema estructural de centralizar el ancla de autorización.
OAuth requiere un servidor de autorización común entre la parte que delega y la parte que recibe. Cuando la transacción se mantiene dentro de la órbita de una sola plataforma —por ejemplo, un usuario que autoriza a una app a leer su Google Calendar—, el modelo funciona. El IdP es Google. Ambas partes confían en Google. El token se emite, se acota y es revocable.
Cuando la transacción cruza fronteras entre principales, las cosas se desmoronan. El Agente A actuando por la Empresa X, el Agente B actuando por la Empresa Y, ninguno compartiendo un proveedor de identidad: entonces OAuth no tiene respuesta de implementación. Puedes federar el proveedor de identidad, lo que recrea el problema de centralización en una capa superior. La otra opción es que la transacción no puede realizarse con integridad.
Los flujos de trabajo agénticos cruzan fronteras entre principales por diseño. Ese es el caso de uso. El modelo de autorización que no puede manejarlo es el modelo equivocado. Por eso tus datos ya no están seguros en la nube sin garantías criptográficas de su vigencia.
Qué cambiaron la "IA" y los LLM
Los agentes existentes eran deterministas. Su ámbito era binario.
Un cron job se dispara o no. Un webhook coincide con el evento o no. El ámbito está codificado en la regla. Las reglas no tienen superficie de interpretación.
Los agentes LLM tienen —y siguen ganando— juicio delegado.
Interpretan la intención. Extrapolan a partir del contexto. Toman decisiones que el principal nunca anticipó de forma explícita.
Un token de OAuth concede "leer calendario". Eso es un permiso binario. No puede excederse por interpretación.
Un agente LLM al que se le da "gestiona mi calendario" puede interpretar que eso incluye rechazar invitaciones, enviar respuestas en tu nombre, compartir tu disponibilidad con terceros y agendar reuniones que nunca revisaste. Ninguna de esas acciones estaba explícita en la concesión. Todas están dentro de la interpretación que un modelo probabilístico hace de la instrucción.
Ese desplazamiento, de la regla al juicio, es lo que rompió la infraestructura de confianza existente.
La web ya tenía agentes. Nunca necesitó una aplicación criptográfica del ámbito porque los agentes deterministas no pueden exceder reglas binarias. Los agentes probabilísticos sí pueden.
Esa es la brecha que cierra PAP.
La inversión sobre la que se construye el Principal-Agent Protocol
La identidad humana está descentralizada. La identidad de los agentes está centralizada. Esta es una decisión arquitectónica deliberada, no una concesión. La razón es sencilla: los sistemas de autenticación existentes intentan simular organizaciones humanas, lo que a primera vista parece razonable, pero está mostrando debilidades y el acceso no autorizado ocurre a un ritmo alarmante. Las personas son terribles siguiendo reglas de seguridad, pero los agentes son excelentes siguiendo reglas. PAP se diseñó teniendo eso en cuenta.
La identidad de un principal es una passkey: un par de claves Ed25519 vinculado al dispositivo. El did:key se deriva directamente de la clave pública: sin registro, sin DNS, sin emisor, sin plataforma que pueda revocarla. La identidad vive en el hardware que el principal elige. No es posible ninguna expulsión de plataforma porque no hay plataforma de la que expulsar.
La identidad del agente es responsable. Los agentes se registran en Chrysalis con DID verificables y anuncios de capacidad firmados con passkey. La admisión basada en avales requiere que pares de confianza existentes pongan en juego su reputación por un nuevo entrante. Una solicitud que llega sin un mandato PAP válido se rechaza antes de que comience la ejecución. Incluso un agente que se ejecuta localmente está "en plataforma" en este sentido: tiene una identidad registrada, capacidades declaradas y opera dentro de una estructura de confianza responsable. El ordenador local es la plataforma de los agentes locales. La responsabilidad no requiere dependencia externa.
Esta inversión resuelve el problema que OAuth no pudo.
Cuando dos agentes de principales independientes necesitan transaccionar, no hay un IdP común al que invocar. No hay acuerdo de federación que negociar. La transacción es un apretón de manos entre dos cadenas de mandato. Cada agente porta un mandato criptográfico de su propio principal. Un token de divulgación selectiva negocia qué revela cada lado; limitado por lo que permite el mandato de cada principal. El recibo cofirmado es auditable por ambos principales de forma independiente.
La confianza fluye desde los principales hacia afuera a través de sus respectivas cadenas de mandato. Las dos cadenas se encuentran en el límite de la sesión. Ninguna parte central está en el camino.
El problema de enrutamiento que la web no fue construida para resolver
El enrutamiento HTTP encuentra un servidor. El enrutamiento DNS resuelve un nombre.
Ninguno resuelve una capacidad, negocia un ámbito de divulgación, acota criptográficamente una autorización ni devuelve una prueba verificable de que un agente se mantuvo dentro de su mandato.
Service-as-a-Software requiere un enrutamiento que la web no fue construida para proporcionar. Enrutamiento consciente de las capacidades que encuentra el agente adecuado para la tarea. Negociación que preserva la privacidad, de modo que el agente reciba solo lo que necesita. Aplicación criptográfica del ámbito, de modo que el agente no pueda actuar más allá de la concesión del principal. Manejo de sesiones efímeras, de modo que las interacciones no puedan correlacionarse. Recibos cofirmados que prueban qué ocurrió.
El enrutador de intención de PAP es una cadena determinista de tres niveles. Ruta rápida por URL con latencia casi nula; sin modelo, sin inferencia, sin red. Índice semántico BM25 a 50 microsegundos en Rust puro. Lo construimos con cero dependencias externas y sin pesos de modelo en la ruta de enrutamiento. Respaldo de IA en el dispositivo para consultas ambiguas, ejecutándose localmente, sin tocar nunca una API en la nube.
El modelo es opcional en la ruta de enrutamiento. El apretón de manos criptográfico no lo es.
Chrysalis gestiona el registro. Los agentes se registran con DID verificables y anuncios de capacidad firmados. La admisión basada en avales requiere que tres pares existentes pongan en juego su reputación por un nuevo entrante. Una solicitud que llega sin un mandato PAP válido se rechaza antes de que comience la ejecución.
En resumen, no necesitas IA para usar PAP. Pero si la usas, la capa de solicitud queda completamente intacta por el instrumental de IA. Tú declaras la intención. El protocolo enruta. El agente ejecuta. El recibo vuelve cofirmado. Tu par de claves vinculado al dispositivo sigue siendo la raíz de la confianza. El cómputo vive en la nube. La autorización vive en tu dispositivo.
La inversión de la vigilancia
Sin una capa de confianza, Service-as-a-Software es surveillance-as-a-software (vigilancia como software).
Cada agente en la nube que ejecuta una tarea aprende algo sobre el principal que la pidió. A lo largo de suficientes tareas, suficientes sesiones, suficientes agentes, se construye el perfil de comportamiento. La plataforma que aloja a los agentes ve el agregado.
OAuth empeoró esto en la capa de identidad. Google sabe en cada lugar y a cada servicio al que concediste acceso, cada ámbito, cada token, cada revocación. El proveedor de identidad (idp) que aloja es, por diseño, el agregador de comportamiento. No hacen esto porque sean una empresa amable. Lo hacen porque alimenta sus necesidades de publicidad, compensando así el servicio de inicio de sesión y obteniendo beneficio de él. La autorización centralizada produce visibilidad centralizada, lo que proporciona vigilancia central, que luego se revende y se monetiza.
Este es el problema del cochecito a escala de agentes. Una sola consulta de búsqueda de un humano detrás de un navegador dejaba un rastro de comportamiento de seis meses. Miles de consultas de agentes por día; correlacionadas, con marca de tiempo, atribuidas a una identidad persistente. Construyen un perfil de intención que ningún humano ha divulgado voluntariamente a una sola parte. Investigación médica. Decisiones financieras. Cuestiones legales. Movimientos profesionales. Todo ello fluyendo a través de plataformas que se benefician del agregado. Todo ello diseñado para captar tu atención a costa de tu confianza. Es entrenamiento conductual experimental a escala masiva.
PAP hace que esta correlación sea estructuralmente costosa.
La identidad descentralizada del principal significa que ninguna parte puede ver el agregado de tus autorizaciones de agentes. Las claves de sesión efímeras rompen el enlace entre sesiones. Cada sesión genera un par de claves nuevo, descartado al cierre. OHTTP rompe la correlación IP-consulta en la capa de red. SD-JWT rompe la sobredivulgación a nivel de campo. El agente obtiene las propiedades y valores que necesita para esta tarea porque anuncia sus necesidades. Una vez completada la ejecución, los recibos almacenan referencias a propiedades, nunca valores. El almacenamiento de recibos está desactivado por defecto y se señala cuando se solicita.
No dejas ningún perfil de comportamiento que la plataforma pueda monetizar, ningún rastro de sesión que pueda correlacionarse como una unidad, ningún registro de divulgación que exceda lo que cada tarea requirió.
La web agéntica que están construyendo los actores dominantes optimiza para lo contrario. Cada interacción es dato de entrenamiento. Cada sesión es atribución. Cada llamada de agente acrecienta el perfil.
La capa de confianza determina si Service-as-a-Software te sirve a ti o a la plataforma.
El derecho ya tiene el marco
Los tribunales no necesitan conceptos nuevos para gobernar a los agentes de IA. Tienen la doctrina principal-agente, y la están aplicando ahora.
Si tu agente genera un resultado, tú lo autorizaste. Si lo autorizaste, eres responsable de él. El fiscal general de California es explícito: la conducta que es ilegal sin la participación de la IA es igualmente ilícita con ella. La IA no es una defensa. El operador es la parte responsable.
La pregunta hacia la que convergen los tribunales: ¿qué autorizó este principal, bajo qué ámbito, y se mantuvo el agente dentro de él?
Un historial de prompts no puede responder eso. Es un registro de solicitudes. No establece el ámbito, la duración, ni si el agente excedió lo que pretendías.
Una cadena de mandato criptográfica responde las tres cosas. Firmaste qué podía hacer el agente, a qué datos podía acceder y cuánto tiempo era válida la concesión. Scope::contains() impone la contención en cada paso de delegación. El recibo cofirmado prueba qué ocurrió. El TTL del mandato prueba cuándo expiró la concesión.
Esto es el sistema funcionando correctamente, de la misma forma en que la doctrina principal-agente siempre ha exigido que los principales definan, acoten y respondan por lo que autorizaron.
El protocolo que la web agéntica siempre necesitó
La gente en el sector tecnológico construyó la V1 de la web agéntica sin ponerle nombre.
Service workers para la agencia local. Stripe para la agencia financiera. Operadores de Kubernetes para la agencia de infraestructura. OAuth para la delegación, hasta que la delegación necesitó cruzar fronteras de plataforma y el ancla centralizada se convirtió en la restricción.
La infraestructura existía. Los agentes eran deterministas. La capa de confianza estaba implícita en el ámbito binario de las reglas que seguían. Cuando el modelo de autorización estaba centralizado, el centro se convirtió en el punto de captura.
Los LLM hicieron probabilísticos a los agentes. Los agentes probabilísticos requieren una autorización explícita, criptográfica y vinculada al principal. La confianza implícita del ámbito determinista no sobrevive a un modelo que interpreta su camino hacia acciones que el principal nunca pretendió. La autorización centralizada no sobrevive a flujos de trabajo que cruzan fronteras entre principales por diseño.
La era del SaaS necesitaba infraestructura de facturación. Stripe la construyó. La era del PaaS necesitaba orquestación de contenedores. Kubernetes la construyó. La era de Service-as-a-Software necesita gobernanza principal-agente en la capa de protocolo.
Cada abstracción produjo infraestructura que la capa inferior no podía proporcionar y sin la cual la capa superior no podía funcionar. La infraestructura siempre llega después de que la abstracción esté en producción y antes de que los fallos que previene se vuelvan catastróficos.
Estamos dentro de esa ventana ahora mismo.
PAP no es una respuesta a un problema nuevo. Es la formalización de la infraestructura de confianza que la web agéntica siempre implicó y nunca requirió, hasta que los agentes empezaron a tomar decisiones de juicio a través de fronteras entre principales.
pap:// es cómo vuelves a poner al principal en la relación principal-agente.
PAP es de código abierto. MIT/Apache-2.0. La especificación es pública.