El primer artículo presentó el Protocolo Principal-Agente y recorrió los ejemplos de prueba de concepto. Las primitivas del protocolo funcionan. La pregunta que importa ahora: ¿qué construirías realmente con esto?
Este artículo responde esa pregunta con cinco escenarios concretos. Cada uno ejercita una combinación distinta de características del protocolo. Cada uno está diseñado para hacer un problema específico visceralmente evidente, y luego mostrar cómo se ve la misma interacción cuando el principal humano controla la cadena de confianza.
El panorama: protocolos sin privacidad
Antes de los escenarios, una orientación rápida sobre por qué existe PAP.
A seis meses de la carrera de protocolos de agentes, aquí es donde estamos:
Google A2A define tarjetas de agente y el ciclo de vida de las tareas. La privacidad es un "principio de opacidad": aspiracional, no impuesto. Sin minimización de contexto. Sin efimeridad de sesión. La formalización de la autenticación sigue en la hoja de ruta.
Anthropic MCP conecta modelos con herramientas y fuentes de datos. Lo hace bien. Pero no es un protocolo de agente a agente. No existe el concepto de agentes negociando con otros agentes, no hay divulgación selectiva, y no hay mecanismo para que el principal restrinja a nivel de protocolo lo que el modelo comparte con las herramientas. Los principios de seguridad de MCP están enunciados, no impuestos: la propia especificación lo dice.
Microsoft Semantic Kernel / AutoGen asume que todos los agentes del sistema confían entre sí. La identidad es Azure AD. El límite de confianza es el ecosistema de Microsoft.
ACP gestiona la interoperabilidad de agentes basada en REST. Capa de confianza endeble. Sin identidad criptográfica. Ahora fusionando su gobernanza con A2A.
Todos los frameworks —CrewAI, LangGraph, OpenAI Agents SDK— tratan la privacidad como un detalle de implementación. El patrón por defecto de LangGraph es un bloc de notas compartido donde cada agente ve todo. Ninguno impone la minimización de contexto. Ninguno define la efimeridad de sesión. Ninguno tiene primitivas económicas.
El hilo común: ningún protocolo existente impone la minimización de contexto a nivel de protocolo. La divulgación siempre es voluntaria. El residuo de la sesión siempre queda indefinido. La privacidad siempre es problema de alguien más.
PAP la convierte en el problema del protocolo.
Escenario 1: Tu asistente de IA usa herramientas sin filtrar tu identidad
El escenario más simple. El que todo desarrollador que construya sobre un LLM local encontrará de inmediato.
La situación: Ejecutas Mistral (o Llama, o Phi) mediante Ollama en tu portátil. Preguntas: "¿Qué clima hace en Seattle y cuáles son las últimas noticias sobre energía renovable?"
Lo que sucede hoy: Tu asistente llama a OpenWeatherMap y Brave Search con tus claves de API. Esos servicios registran tu IP, tu identidad de autenticación y cada consulta. Tus búsquedas de clima se correlacionan con tu historial de búsqueda. Con el tiempo, los servicios construyen un perfil de tus intereses y patrones de ubicación.
Lo que sucede con PAP: Tu agente orquestador emite un mandato con alcance [SearchAction, CheckAction] y un TTL de 8 horas. Consulta al marketplace local en busca de proveedores. SearXNG (autoalojado, cero divulgación) gestiona la búsqueda. OpenWeatherMap gestiona el clima, pero recibe solo un DID de sesión efímero y la palabra "Seattle" mediante divulgación selectiva con SD-JWT. Tu nombre, tu IP y el ID de tu dispositivo se retienen criptográficamente. La sesión se cierra. El DID se descarta. La consulta de clima de mañana es invinculable a la de hoy.
[mandate] Scope: [SearchAction, CheckAction], TTL: 8h, Disclosure: minimal [marketplace] Found 3 providers for SearchAction (0 require personal disclosure) [marketplace] Found 1 provider for CheckAction (requires: Place.name only) [session] Weather: disclosed [Place.name] via SD-JWT. Values: never in receipt. [session] Search: disclosed [] (nothing). [receipt] Signed by both parties. Auditable. Contains zero personal data.
La versión con docker-compose está en el repositorio: examples/local-ai-assistant/. Ollama, SearXNG, un marketplace PAP, tres agentes proveedores (búsqueda, clima, enciclopedia), un orquestador y un visor de recibos. docker compose up -d y ya lo estás ejecutando.
Lo que esto demuestra: el uso de herramientas no requiere la divulgación de identidad. El protocolo lo impone. El desarrollador de la aplicación no tiene que acordarse de eliminar encabezados o rotar claves de API. El mandato dice qué puede divulgarse. El SD-JWT hace estructuralmente imposible divulgar más.
Escenario 2: Comprar sin convertirte en un objetivo
Buscaste un cochecito de bebé una vez. Ahora todos los sitios web creen que estás embarazada. Durante seis meses.
Esto no es una exageración. Así funciona la publicidad conductual. Una sola consulta de búsqueda dispara actualizaciones de perfil en decenas de intermediarios de datos. Tu "puntuación de embarazo" afecta las cotizaciones de seguros, la segmentación de anuncios y las recomendaciones de productos financieros. No puedes deshacerlo.
Con PAP: Tu agente personal busca cochecitos mediante SearXNG (cero divulgación). Contacta a agentes de comercios mediante el marketplace. El mandato permite la divulgación de: región de envío (solo prefijo del código postal) y rango de presupuesto. Los agentes de comercios compiten en precio y características sin saber quién eres.
El marketplace hace el filtrado antes de que comience la negociación. ¿Un agente que exige tu nombre completo, correo y teléfono para mostrarte precios de cochecitos? Nunca aparece en los resultados. El mandato no puede satisfacer sus requisitos de divulgación, así que el marketplace lo excluye.
Tres comercios responden. Eliges uno. Tu agente gestiona el pago mediante un canal que preserva la privacidad (prueba de ecash chaumiano: el vendedor recibe la prueba de la transferencia de valor pero nada que identifique al pagador). El cochecito llega. Internet no tiene memoria de tu búsqueda.
Lo que muestra la demo: Una pantalla dividida. Lado izquierdo: el flujo normal, tu consulta propagándose a través de intermediarios de datos, actualizaciones de perfil, segmentación de anuncios. Lado derecho: el flujo PAP, tres agentes de vendedores compitiendo, requisitos de divulgación codificados por color (verde = mínimo, rojo = excesivo), sesiones efímeras y un recibo final que muestra exactamente qué se compartió. El contraste es el argumento completo.
Escenario 3: Tu hijo en línea sin capitalismo de vigilancia
Tu hijo de 11 años quiere buscar información sobre volcanes para un trabajo escolar. Quieres que esté seguro. YouTube quiere construir un perfil psicológico que lo seguirá por el resto de su vida.
Para los 13 años, un niño tiene un perfil en la sombra a través de decenas de plataformas que predice sus vulnerabilidades, inseguridades y detonantes de gasto. COPPA técnicamente requiere consentimiento. El "consentimiento" es una casilla que marcaste una vez.
Con PAP: Tú eres la raíz de confianza. El agente de tu hijo porta un mandato delegado desde tu par de claves. El mandato especifica:
- Alcance:
education.content(no social, no compras, no entretenimiento) - Divulgación:
age_range: 10-12mediante SD-JWT. Nada más. Sin nombre, sin escuela, sin ID persistente. - TTL: 2 horas por sesión. Autoexpira. No se emiten tokens de continuidad.
- Política: aprobar contenido educativo automáticamente, marcar el entretenimiento, bloquear compras dentro de la aplicación.
Cada solicitud de contenido usa un nuevo DID de sesión. La plataforma no puede correlacionar la búsqueda de volcanes del lunes con la búsqueda de dinosaurios del martes. No hay perfil conductual longitudinal porque no hay continuidad que el protocolo pueda filtrar.
La característica del protocolo que importa: el filtrado de divulgación del marketplace. Los proveedores de contenido que requieren la identidad del estudiante, datos conductuales o métricas de interacción se excluyen antes de que se establezca cualquier conexión. Tu hijo ni siquiera ve la opción hostil a la privacidad.
Escenario 4: Preguntas médicas sin un registro permanente
Tienes un lunar raro. Quieres saber si es algo de qué preocuparse. Lo buscas en Google.
Acabas de alterar tu perfil de riesgo de seguro. Los intermediarios de datos relacionados con la salud te marcan como "preocupación por cáncer". Si solicitas un seguro de vida, el proveedor de datos del asegurador podría hacer aflorar tu historial de búsqueda como una señal de riesgo. Nunca tuviste cáncer. Tuviste un lunar normal. Pero los datos dicen que estabas preocupado, y esos datos nunca caducan.
Con PAP: Tu LLM local hace el triaje inicial, sin llamada a la red. Si necesita datos externos, consulta un servicio de conocimiento médico mediante PAP. El SD-JWT divulga: adult, dermatological inquiry. Nada más. El DID de sesión es efímero. El servicio no puede vincular esta consulta con ninguna identidad. El recibo registra [subject: dermatology], nunca la pregunta que hiciste ni la respuesta que recibiste.
Reservas una cita con el dermatólogo. Solo en ese momento tu agente pregunta: "El servicio de reservas necesita tu nombre y tu ID de seguro. ¿Apruebas?" Apruebas. El agente de reservas recibe exactamente dos campos. El servicio de conocimiento médico nunca conoce tu nombre. Tu compañía de seguros ve una visita dermatológica de rutina, no un susto de cáncer.
La característica del protocolo que importa: el aislamiento del flujo de información entre alcances. Los datos obtenidos bajo el alcance health.research no pueden cruzar al alcance health.booking. Esto lo impone la cadena de mandatos, no la lógica de la aplicación.
Escenario 5: Intercambio de datos B2B con acceso revocable y acotado
Durante la debida diligencia de una fusión o adquisición, el agente legal de la Empresa A necesita compartir documentos financieros con el agente de análisis de la Empresa B. Requisitos que OAuth no puede satisfacer:
- El acceso debe ser revocable en cualquier momento por el principal de la Empresa A.
- El agente de la Empresa B debería ver campos específicos (ingresos, plantilla) pero no otros (nombres de clientes, contratos).
- Cada acceso debe producir un recibo no repudiable.
- La relación debe sobrevivir durante semanas sin volver a autenticarse.
Con PAP: La Empresa A emite un token de continuidad al agente de la Empresa B. El token porta un TTL de 30 días establecido por la Empresa A (no por la preferencia de la Empresa B). El mandato permite acceso ReadOnly a los resúmenes financieros. La divulgación selectiva con SD-JWT asegura que la Empresa B vea revenue: $15M, headcount: 120 pero nunca nombres de clientes ni detalles de contratos: la carga del SD-JWT estructuralmente no puede revelar campos excluidos por el mandato.
Cada acceso genera un recibo firmado: [accessed: financials.revenue, financials.headcount at 14:32 UTC]. Sin valores en el recibo, solo referencias a propiedades. Durante una auditoría regulatoria, la Empresa A puede probar exactamente qué categorías de datos se compartieron y cuándo, sin exponer las cifras reales.
¿La Empresa A revoca el acceso a mitad de la diligencia? Elimina el token de continuidad. La siguiente solicitud de la Empresa B falla con una prueba de revocación firmada. No hay ningún token obsoleto flotando en una caché en algún lugar. La revocación es instantánea porque el token es la relación.
La característica del protocolo que importa: los tokens de continuidad con TTL controlado por el principal. El proveedor (Empresa B) no retiene nada. La relación existe únicamente porque el principal (Empresa A) posee el token y elige presentarlo.
Qué tienen en común estos escenarios
Cada escenario sigue el mismo patrón:
[Principal] -> [Mandate with scoped permissions] -> [Orchestrator discovers providers via marketplace] -> [SD-JWT selective disclosure per interaction] -> [Ephemeral session DIDs, no correlation] -> [Signed receipts, no stored values] -> [Session closes, keys discarded]
Y cada escenario plantea el mismo argumento: la brecha de privacidad en la comunicación de agente a agente no es una solicitud de característica. Es una falla arquitectónica en todos los protocolos desplegados actualmente. La privacidad basada en políticas fracasa a escala de agentes porque los agentes siguen instrucciones, y las instrucciones provienen de quien diseñó el agente, no necesariamente del principal al que el agente dice servir.
PAP hace que la intención del principal quede criptográficamente vinculada a cada interacción. No por política. No por configuración. Por la cadena de mandatos que todo agente posterior debe verificar antes de poder actuar.
Pruébalo
El repositorio tiene siete ejemplos funcionales. Cuatro ejercitan el protocolo central (search, travel-booking, delegation-chain, payment). Tres ejercitan las capas de transporte y federación (networked-search, federated-discovery, webauthn-ceremony). El docker-compose del asistente de IA local los reúne con servicios reales.
git clone https://github.com/Baur-Software/pap.git cd pap cargo test # all tests cargo run --bin search # zero disclosure cargo run --bin travel-booking # selective disclosure cargo run --bin delegation-chain # hierarchical trust cargo run --bin payment # protocol extensions cargo run --bin networked-search # HTTP transport cargo run --bin federated-discovery # marketplace federation
El protocolo está en los tipos. Las restricciones están en el compilador. El modelo de confianza está en las firmas.
Si construyes agentes, la pregunta no es si pueden hablar entre sí. La pregunta es a quién le responden.
Todd Baur es el fundador de Baur Software. PAP es de código abierto bajo licencia MIT/Apache-2.0. El repositorio está en github.com/Baur-Software/pap. Los comentarios, las objeciones y las propuestas alternativas son el objetivo de publicar en etapa de borrador.