Todos los protocolos de agente a agente que se están desarrollando actualmente fueron diseñados para servir a los operadores de plataformas, no a los principales humanos.
A2A autentica a los agentes como entidades de plataforma. ACP se enfoca en la interoperabilidad de flujos de trabajo empresariales, donde el principal es la empresa, no el individuo. MCP gestiona el uso de herramientas para una sola sesión de agente: no es un protocolo de negociación entre agentes que representan a distintos principales. AgentConnect optimiza para la topología de despliegue, no para la topología de confianza.
Ninguno de ellos impone la minimización de contexto a nivel de protocolo. La divulgación depende de la implementación. Ninguno define la efimeridad de la sesión como una garantía del protocolo. Todos son compatibles con la monetización de la economía de tokens. Ninguno la impide estructuralmente.
Los modelos de confianza son endebles. Los controles de contexto son voluntarios. El residuo de la sesión queda indefinido. Y el modelo económico que subyace a cada protocolo es la medición del cómputo en la nube: el mismo modelo que convirtió a cada generación anterior de estándares abiertos en un embudo hacia el bloqueo de plataforma.
Construimos algo diferente.
El Protocolo Principal-Agente
PAP está diseñado desde la dirección opuesta. El principal humano es la raíz de confianza. Cada agente en una transacción porta un mandato criptográficamente verificable emitido desde esa raíz. Las sesiones son efímeras por diseño. La divulgación de contexto la impone el protocolo, no una política. La nube es una utilidad sin estado invocada por los agentes, no una relación que acumula el contexto del principal.
Sin criptografía nueva. Sin economía de tokens. Sin registro central.
El repositorio es de código abierto, está escrito en Rust, y puedes clonarlo y ejecutar la prueba de concepto de extremo a extremo ahora mismo.
El modelo de confianza
Human Principal (device-bound keypair, root of trust) └─ Orchestrator Agent (root mandate, full principal context) └─ Downstream Agents (scoped task mandates) └─ Marketplace Agents (own principal chains)
Las transacciones son intercambios (handshakes) entre dos cadenas de mandatos, no entre dos agentes. El orquestador es el único agente que sabe quién eres. Cada agente posterior sabe únicamente lo que su mandato permite explícitamente.
Cinco restricciones se imponen a nivel de protocolo, no a nivel de implementación:
- Denegar por defecto. Un agente solo puede hacer lo que su mandato permite explícitamente. Sin alcance, no hay acción.
- La delegación no puede exceder al padre. El alcance de un mandato hijo está acotado por el alcance de su padre. El TTL de un hijo no puede exceder el TTL de su padre. Esto se verifica criptográficamente, no mediante política.
- Los DID de sesión son efímeros. Ambos agentes generan pares de claves de un solo uso para cada sesión. No están vinculados a ninguna identidad persistente. Cuando la sesión se cierra, las claves se descartan.
- Los recibos solo contienen referencias a propiedades. Un recibo de transacción registra qué tipos de datos se divulgaron, nunca los valores. Ambos principales pueden auditar el registro. Ninguna plataforma lo almacena.
- La no renovación es revocación. Un mandato que no se renueva no necesita un aviso de revocación. Se degrada progresivamente —Active, Degraded, ReadOnly, Suspended— y luego se detiene. El principal ve la degradación, no un corte sorpresivo.
Construido sobre estándares que ya existen
PAP no usa primitivas criptográficas novedosas. Toda la pila del protocolo está construida sobre especificaciones existentes y estandarizadas, mantenidas por organismos sin captura de plataforma:
| Capa | Estándar | Propósito |
|---|---|---|
| Identidad | WebAuthn | Generación de pares de claves vinculados al dispositivo |
| Identidad | W3C DIDs | Identificadores descentralizados (did:key) |
| Credenciales | W3C VC Data Model 2.0 | Envoltorio del mandato |
| Divulgación | SD-JWT (IETF draft-08) | Divulgación selectiva de afirmaciones en el handshake de sesión |
| Vocabulario | Schema.org | Referencias de tipos de capacidad y acción |
| Datos | JSON-LD | Datos enlazados estructurados para anuncios |
| Privacidad | Oblivious HTTP (RFC 9458) | Invinculabilidad de las solicitudes a la nube |
Schema.org describe el qué. El protocolo gobierna bajo qué términos. Estos se mantienen estrictamente separados: sin extensiones de Schema.org, sin contaminación de vocabulario.
La implementación
La implementación en Rust se distribuye como cuatro crates en un espacio de trabajo (workspace) de Cargo, con cuatro ejemplos de extremo a extremo. 63 pruebas. Todas en verde.
git clone https://github.com/Baur-Software/pap.git cd pap cargo test
La prueba de captura
PAP está diseñado contra una amenaza específica: la captura por parte de las plataformas dominantes. Todo protocolo importante de internet que comenzó con el control del usuario ha sido capturado por las entidades con la mayor huella de infraestructura. Esto no es una conspiración. Es el resultado predecible de dejar que las entidades con más que perder ante un protocolo definan su implementación.
XMPP fue abierto y federado hasta que las principales plataformas de mensajería dejaron de federar. OAuth se diseñó para la autorización del usuario hasta que se convirtió en el mecanismo por el cual las plataformas acumularon permiso indefinido para actuar en nombre de los usuarios. Todo protocolo abierto que requería la infraestructura de un actor dominante para funcionar a escala terminó reflejando los intereses de ese actor.
Cualquier propuesta que enrute el contexto del principal a través de infraestructura propiedad de plataformas dominantes queda fuera de alcance, sin importar el marco criptográfico que la rodee.
No-objetivos explícitos: compatibilidad con la monetización de la economía de tokens. Enclave-como-equivalente-a-local. Recuperación de identidad a través de operadores de plataforma. Mecanismos de pago vinculables a la identidad del principal. Registros centrales para el descubrimiento de agentes. Estructuras de mandato que permitan la expansión de alcance en tiempo de ejecución. Estándares de UI que permitan la ejecución de código arbitrario en el contexto del orquestador. Cualquier extensión que canjee garantías de confianza por facilidad de adopción.
Un buen feedback hace que el protocolo sea más difícil de capturar. Las propuestas que introducen nuevos terceros de confianza, centralizan el descubrimiento, suavizan la imposición de la divulgación o crean compatibilidad con modelos de medición deben evaluarse primero como posibles vectores de captura y solo después como mejoras del protocolo.
Qué sucede a continuación
PAP v0.1 es una especificación de arquitectura funcional respaldada por una implementación funcional en Rust. El flujo del protocolo se ejecuta de extremo a extremo en cuatro ejemplos: búsqueda con cero divulgación, divulgación selectiva con SD-JWT, cadenas de delegación de cuatro niveles y pago con preservación de privacidad y continuidad. 63 pruebas cubren toda la superficie del protocolo. Las garantías criptográficas se sostienen.
El repositorio está en github.com/Baur-Software/pap. Clónalo. Ejecuta las pruebas. Ejecuta los ejemplos. Lee el código. El protocolo está en los tipos, las restricciones están en el compilador y el modelo de confianza está en las firmas.
git clone https://github.com/Baur-Software/pap.git cd pap cargo test # 63 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 # extensions
Si construyes agentes, la pregunta no es si tus agentes pueden hablar entre sí. La pregunta es a quién le responden.