● Estándares agénticos · el panorama, mapeado
La delegación solo funciona a escala cuando es demostrable — cuando un agente puede mostrar qué tiene permitido hacer antes de actuar, y quién hizo qué, bajo la autoridad de quién después. Estos son los estándares que lo están haciendo realidad, lo que cubre cada uno y cómo encajan entre sí.
Una página, un argumento — léela de arriba abajo
Primero
Lo que operamos
El Proof Pair — la especificación abierta que operamos: entra un mandato, sale un recibo.
Después
Cómo leemos el campo
El Agentic Pulse — la narrativa contrastada con la realidad, cada cifra con su fuente.
Lo que revela
Un carril que abrimos
Claim Provenance — una pregunta sin ocupar que creemos importante, puesta en público como invitación.
En contexto
El mapa completo
El panorama y el mercado — cada riel, y dónde el carril sigue vacío.
● Nuestra especificación de trabajo abierta · v0 · en vivo
Entra un mandato, sale un recibo — la delegación, demostrable en ambos extremos. Un mandato es autoridad que puedes verificar antes del acto: una credencial verificable que una persona otorga a un agente — acotada, con vencimiento, revocable. Un recibo es atribución que puedes verificar después del acto: un registro firmado y encadenado por hash que vincula la acción con el agente y con el mandato que la autorizó. Una sola especificación, porque cada recibo hace referencia a su mandato. Esto es lo que operamos, especificado para que tú también puedas operarlo.
Lee la especificación — the-aios.org/proof-pair → · abierta, CC-BY 4.0, cualquiera puede implementarla
Después — cómo leemos el campoEso es lo que operamos. Para ubicarlo con honestidad, empezamos por leer la economía de agentes tal como realmente es — la historia que cuenta, contrastada con lo que puede demostrar.
Agentic Pulse · narrativa vs. realidad medida
El pulso mide la brecha entre la narrativa agéntica — la ronda de inversión, el whitepaper, la proyección — y la realidad medida: volumen real, estado en producción, si la cosa puede demostrar quién actuó. El fenómeno que revela es lo que el campo llama agent-washing (vender como agéntico lo que no lo es). Es un diagnóstico, no un marcador. Cada cifra remite a una fuente con nombre. Donde un valor no tiene fuente, aparece [TBD-verify] — nunca un número inventado.
~38% → ~20%
de los ejecutivos confía en agentes para análisis rutinarios — pero cae a ~20% en cuanto el agente toca una transacción.
Próximamente — Sell Trust (2026).
$4.6T
el dimensionamiento canónico de la economía agéntica — una proyección top-down de Foundation Capital sobre los salarios del trabajo del conocimiento que son direccionables, explícitamente NO ingresos medidos. “Un mapa del oro, vendido al pie del sendero.”
Foundation Capital — proyección top-down.
Pagos de agentes
NarrativaNarrativa de valuación en miles de millones (marco de ~$7B).
Realidad medida~$28,000/día en volumen real y medido.
¿Puede demostrar quién actuó?[TBD-verify]
Fuente: Próximamente — Sell Trust (2026). El protocolo se omite deliberadamente en la fuente.
Autenticación de herramientas
NarrativaPresentados como infraestructura de herramientas para agentes en producción.
Realidad medida~8,000 servidores escaneados; ~40% no tenía autenticación alguna.
¿Puede demostrar quién actuó?Entre los servidores que SÍ tenían autenticación, prácticamente ninguno puede demostrar quién está del otro lado — “una llave, sí; una identidad, no.”
Fuente: arXiv:2605.22333 — “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers” (2026).
Identidad / autorización de agentes
NarrativaEn la vía de borradores del IETF; presentado como el estándar de autenticación de agentes.
Realidad medida0 despliegues en producción (al 2026-07-06); borrador del IETF rev-09.
¿Puede demostrar quién actuó?Raíz anclada en el DNS del proveedor — no en llaves propiedad de una persona.
Fuente: Borrador público del IETF — AAuth (Dick Hardt); borrador rev-09 al 2026-07-06, actualizar la fecha si avanza antes de publicar.
Identidad de agentes
NarrativaLevantando capital con la tesis de identidad de agentes; afiliado a Anthropic.
Realidad medidaEn etapa de whitepaper; sin producción demostrada — “levantó capital con un whitepaper.”
¿Puede demostrar quién actuó?[TBD-verify]
Fuente: Evaluación del AIOS Observatory — etapa de whitepaper; sin producción demostrada a mediados de 2026.
● Dinero real, como contraste — el piso honesto (no es washing)
El índice también apunta hacia quienes construyen con honestidad. Así se ven los ingresos reales y medidos de agentes — el piso contra el que debería calificarse la narrativa, no solo el techo con el que se vende.
Trabajo de agentes (dinero real)
Realidad medida~$100M en ingresos, con precio por “resolución.”
¿Puede demostrar quién actuó?[TBD-verify]
Fuente: Precios públicos / prensa de la empresa.
Trabajo de agentes (dinero real)
Realidad medida$2.25 por cada 15 minutos (precio público).
¿Puede demostrar quién actuó?[TBD-verify]
Fuente: Precios públicos (Cognition / Devin).
Lo que revela — un carril abiertoLeer el campo así revela dónde están las brechas. En una de ellas todavía no hay nadie — y no es un carril para conquistar, es una pregunta para abrir.
● Un carril abierto · una pregunta que creemos importante, ofrecida, no reclamada
La prueba responde ¿esto es real? No tiene respuesta para ¿debería desconfiar — y quién, exactamente, está detrás de la duda? En una época en la que la IA hace que la sospecha coordinada, verosímil e incansable sea más barata que nunca, tenemos una capa de hechos para lo que las cosas son. No tenemos nada para quien fabrica dudas sobre ellas.
La primitiva que falta: una respuesta verificable a quién está realmente detrás de esta afirmación, desde cuándo, en coordinación con quién — la detección de inautenticidad coordinada como infraestructura pública, no como la caja negra privada de confianza y seguridad de una plataforma. Procedencia que apunta al acusador, no al acusado. Procedencia para la sospecha misma.
Dejamos esta pregunta abierta por escrito — como invitación, no como reclamo. Un carril sin ocupar que creemos importante, nombrado en público para que quienes deberían construirlo puedan encontrarlo — la misma postura de anfitrión que el Proof Pair. La especificación todavía no está escrita. Tampoco la de nadie más, y preferimos ayudar a abrir el carril que cercarlo. Considera esto una puerta abierta.
En contexto — el mapa completoEse es el carril que estamos abriendo. Este es el campo completo en el que se ubica — cada riel jalando en la misma dirección, y dónde el carril todavía se ve vacío.
● El panorama — 14 rieles, una dirección
¿Quién es este agente y quién lo respalda?
Ethereum
Registros on-chain de identidad, reputación y validación de agentes — rieles públicos de anclaje que cualquier framework de agentes puede referenciar. Los registros de identidad y reputación están desplegados en Ethereum mainnet; el registro de validación todavía no, y el EIP sigue siendo un Draft.
Cómo encaja: Los DIDs de agentes se pueden registrar en su registro de identidad, y los checkpoints de la cadena de recibos pueden publicarse en su registro de validación (la ruta de anclaje planeada para la v0.1 del Proof Pair).
Fuente: EIP-8004 (estado: Draft) + repositorio oficial de contratos · verificado 2026-11-02
W3C
El sustrato de identidad: identificadores descentralizados más afirmaciones verificables criptográficamente — el modelo de datos debajo de todo sistema de credenciales serio. VC Data Model 2.0 y DID Core 1.0 son W3C Recommendations; DID 1.1 es una Candidate Recommendation.
Cómo encaja: Cada actor en el Proof Pair es un DID; un mandato es una Verifiable Credential. Esta es la capa sobre la que se sostiene todo el panorama.
Fuente: W3C Recommendation — VC Data Model 2.0 (15 de mayo de 2025) · verificado 2026-11-02
¿Qué puede hacer, para quién, hasta cuándo — y se puede revocar?
IETF (OAuth WG)
Credenciales verificables como JWT con divulgación selectiva a nivel de afirmación y vinculación criptográfica al titular (KB-JWT). El formato base ya es el RFC 9901; el perfil de VC está en evaluación del IESG.
Cómo encaja: El único formato normativo del mandato en el Proof Pair v0 — un agente demuestra “puedo gastar ≤ $X para la organización Y” sin revelar todo su conjunto de permisos.
Fuente: IETF Datatracker — draft-ietf-oauth-sd-jwt-vc (evaluación del IESG) · verificado 2026-11-02
OpenID Foundation
Los transportes de emisión y presentación de credenciales verificables — cómo se mueven las credenciales entre emisores, titulares y verificadores sobre HTTP. Ambas son especificaciones Final 1.0 (OID4VP en julio de 2025, OID4VCI en septiembre de 2025); la adopción todavía está en aumento.
Cómo encaja: Los bindings perfilados del Proof Pair para emitir mandatos y presentarlos a verificadores HTTP. Las wallets de agentes sin interfaz son titulares conformes.
Fuente: OpenID Foundation — OID4VCI 1.0 (Final) · verificado 2026-11-02
DIF
Mensajería cifrada e independiente del transporte entre partes identificadas por DID, con mediadores que encolan mensajes para agentes fuera de línea. La v2.1 es una DIF Ratified Specification.
Cómo encaja: El transporte agente a agente y de buzón: cómo un agente sin interfaz recibe y presenta mandatos mientras su máquina está dormida.
Fuente: DIF — DIDComm Messaging v2.1 (ratificada) · verificado 2026-11-02
W3C
Revocación de credenciales a escala — una forma compacta y respetuosa de la privacidad para que los verificadores comprueben si una credencial sigue vigente. W3C Recommendation desde mayo de 2025.
Cómo encaja: El único mecanismo normativo de revocación del Proof Pair: un agente comprometido debe poder detenerse en segundos, no en las horas de una CRL.
Fuente: W3C Recommendation — Bitstring Status List (15 de mayo de 2025) · verificado 2026-11-02
¿Puede pagar, y se puede vincular el pago con lo que la persona aprobó?
Google → FIDO Alliance
Artefactos firmados de intención del usuario para el comercio de agentes: Intent Mandates (lo que el usuario autorizó al agente a buscar) y Cart Mandates (la transacción específica aprobada). Google lo donó a la FIDO Alliance en abril de 2026, donde lo desarrolla su Payments Technical Working Group; la versión más reciente es la v0.2.
Cómo encaja: Un mandato del Proof Pair se compila a un Intent/Cart Mandate de AP2 para pagos. La diferencia: la cadena de confianza de AP2 termina en una cuenta del procesador; la del Proof Pair termina en una raíz humana o institucional verificable — que es lo que necesita la delegación regulada e interinstitucional.
Fuente: FIDO Alliance — Google dona AP2 (abr 2026) · verificado 2026-11-02
Mastercard
Una cadena de credenciales firmadas (SD-JWT en capas) que demuestra que la compra de un agente se mantuvo dentro de los límites que fijó la persona — monto, comercio, artículos. Publicada en marzo de 2026 como borrador abierto (v0.1), mantenida por Mastercard y abierta a contribuciones de múltiples actores.
Cómo encaja: Construida sobre SD-JWT, la misma familia de formatos que un mandato del Proof Pair, así que cada uno puede expresarse en los términos del otro. Responde la mitad de pagos de la pregunta que el mandato responde en general: ¿la persona autorizó esto, dentro de estos límites?
Fuente: Especificación de Verifiable Intent — README (Draft v0.1) · verificado 2026-11-02
x402 Foundation (Linux Foundation) · incubado por Coinbase
El pago dentro de la propia solicitud HTTP, usando el estado 402 Payment Required, reservado desde hace mucho: un cliente o agente paga por un recurso y lo obtiene en un solo intercambio. Lanzado por Coinbase en 2025; ahora lo gobierna un proyecto de la Linux Foundation que contaba con 40 organizaciones miembro en su lanzamiento de julio de 2026.
Cómo encaja: Liquida el pago; no dice nada sobre quién lo autorizó. Esa es la mitad que aporta un mandato — la prueba de que este gasto fue delegado, por quién y dentro de qué límite.
Fuente: Linux Foundation — lanzamiento operativo de la x402 Foundation (14 jul 2026) · verificado 2026-11-02
¿Quién hizo qué, bajo la autoridad de quién — y cualquiera puede verificarlo?
Coalition for Content Provenance
Manifiestos de procedencia firmados y de solo anexado para contenido multimedia — quién lo hizo, con qué, cómo se modificó. La especificación está en la versión 2.5 (octubre de 2026).
Cómo encaja: La fuente del patrón para la cadena de recibos: la misma disciplina de manifiestos firmados y a prueba de manipulación, aplicada a acciones de agentes en lugar de archivos multimedia.
Fuente: C2PA Technical Specification 2.5 · verificado 2026-11-02
¿Puede demostrar una afirmación sin revelar los datos detrás de ella?
Privacy & Scaling Explorations · Ethereum Foundation
Demuestra que perteneces a un grupo sin revelar qué miembro eres, con un nullifier que impide que el mismo miembro emita una señal dos veces. Va en su cuarta versión mayor (v4, 2024; última versión en octubre de 2026).
Cómo encaja: Membresía sin identidad: un agente podría demostrar que actúa en nombre de algún miembro verificado de una organización sin revelar cuál — el borde del carril de identidad que preserva la privacidad.
Fuente: Documentación + versiones de Semaphore (v4.14.5, oct 2026) · verificado 2026-11-02
W3C
Divulgación selectiva para credenciales verificables con pruebas derivadas no vinculables: un titular revela solo algunos campos, y dos presentaciones de la misma credencial no pueden correlacionarse. Una W3C Candidate Recommendation (septiembre de 2026).
Cómo encaja: La propiedad de privacidad que SD-JWT por sí solo no ofrece: el mismo mandato presentado a dos verificadores no puede vincularse de vuelta a un solo agente.
Fuente: W3C Candidate Recommendation Draft — vc-di-bbs (10 de septiembre de 2026) · verificado 2026-11-02
Campo abierto · EZKL entre los provers más usados
Pruebas de conocimiento cero de que un modelo determinado produjo una salida determinada, sin revelar los pesos ni las entradas. Las herramientas existen y las pruebas pueden verificarse on-chain, en un navegador o en un dispositivo; el costo de generar las pruebas sigue siendo alto y todavía no hay un estándar.
Cómo encaja: Para los recibos, la diferencia entre “un agente hizo esto” y “este modelo, bajo este mandato, hizo esto” — demostrable ante alguien que no puede ver el modelo.
Fuente: EZKL — prover zkML abierto (v23.0.5, feb 2026) · verificado 2026-11-02
Lo que el campo dice que es la brecha.
Anthropic
El encuadre de seguridad publicado en 2026: Zero Trust para agentes significa identidades con raíz criptográfica y permisos acotados por tarea — porque los controles de acceso tradicionales no impedirán que un agente abuse de permisos que tiene legítimamente.
Cómo encaja: Nombra la brecha que llena el Proof Pair. La identidad responde quién. Un mandato responde qué puede hacer este agente, para quién, hasta cuándo. Un recibo responde quién hizo qué, bajo la autoridad de quién.
Fuente: Anthropic — Zero Trust for AI agents (27 de mayo de 2026) · verificado 2026-11-02
● El panorama de identidad de agentes, mapeado
La mayoría de las comparaciones de identidad de agentes enfrentan whitepapers contra whitepapers. Esta está calibrada contra una implementación de punta a punta comprobada — un sistema en funcionamiento en el que a un agente se le emite una credencial acotada y vinculada a su dueño, la presenta a una contraparte de otra organización sin relación previa, y esa credencial se verifica criptográficamente en el canal, con divulgación selectiva y revocación explícita, hoy. Aquí la vara es implementado, no propuesto.
● El carril, dicho primero
Esta es la combinación específica que el campo no ha entregado — una identidad de agente que sea todo esto al mismo tiempo:
Ninguna solución del campo entrega todo lo anterior. El mapa de abajo muestra dónde se detiene cada una.
● Seis soluciones — lo que hacen, dónde se detienen
Una distinción crucial atraviesa el campo: la mayoría no son rivales — son puntos de integración. Cuatro de las seis operan en capas por debajo o al lado de la autoridad del agente (dónde corren los agentes, cómo se controla el tráfico, quién emite dentro de una empresa). Solo una ocupa la misma capa.
Dick Hardt · borrador del IETF
Lo que haceAutorización delegada para agentes. El intento más directo de resolver el mismo problema: permitir que un principal otorgue autoridad acotada a un agente. Incluye un patrón de consentimiento asíncrono realmente bueno (aprobación pendiente / diferida).
Dónde se detieneLa raíz de confianza está anclada en el DNS del proveedor, no en llaves que tenga la persona — así que la autoridad termina en un proveedor, no en un humano. Un borrador en vía de estándar que, al momento de escribir esto, no tiene despliegues en producción. No es verificable fuera de línea.
Rival directo — misma capa. Pero con raíz en DNS y todavía antes de producción.
tokens de delegación / capacidad · [TBD-verify: confirmar nombre completo]
Lo que haceUn esquema de tokens de capacidad para delegar permisos acotados, con una regla firme de solo atenuar: cada salto en una cadena de delegación solo puede reducir la autoridad, nunca ampliarla.
Dónde se detieneResuelve la subdelegación con elegancia, pero no incluye una raíz en la persona, anclaje gubernamental ni verificación interorganizacional sin infraestructura compartida. Adyacente al carril, no dentro de él.
Fuente de una buena idea — vale la pena adoptar el invariante de atenuación; el protocolo no es el mismo producto.
Lo que haceIdentidad empresarial para agentes dentro de una sola organización / tenant — emitir, listar y gobernar los agentes propios de una organización a escala, con herramientas maduras de ciclo de vida.
Dónde se detieneLimitado a la organización que emite. Es un emisor intraorganizacional, no un tejido de confianza interorganizacional; dos agentes de empresas distintas no obtienen verificabilidad mutua a partir de él.
Punto de integración (un emisor con el cual interoperar), con modelos de ciclo de vida de los que vale la pena aprender. Punto a vigilar: si se combina con un producto de credenciales verificadas para la portabilidad interorganizacional, la frontera podría moverse. [TBD-verify: estado de GA]
Lo que haceUna capa de aplicación de políticas para el tráfico de agentes — evalúa expresiones de política ricas en el gateway y permite / niega llamadas. Nativa de la nube, bien distribuida.
Dónde se detieneAplica políticas; no establece quién es el agente ni de dónde viene su autoridad. Necesita una autoridad que aplicar.
Punto de integración — una credencial con raíz en la persona es un token estándar que entra a su motor de políticas con una adaptación mínima. Componer, no competir.
Lo que haceUn runtime de agentes — donde los agentes se construyen y se ejecutan.
Dónde se detieneEjecuta agentes; no dice nada sobre identidad portátil y verificable ni sobre autoridad interorganizacional.
Punto de integración — la capa debajo de la identidad, no un rival de ella.
Lo que haceUn runtime / sustrato de agentes — infraestructura para operar agentes.
Dónde se detieneSustrato operativo, no una capa de identidad ni de autoridad.
Punto de integración — no es un rival.
El conteo: cuatro puntos de integración (dos runtimes, una capa de aplicación de políticas, un emisor intraorganizacional), una fuente de técnica a adoptar y un verdadero rival en la misma capa — AAuth — que tiene raíz en DNS y todavía no llega a producción.
● Dónde se ubica el enfoque con raíz en la persona
Frente a ese mapa, el carril sigue abierto. Una credencial de agente con raíz en la persona — vinculada a su dueño, revocable, con divulgación selectiva, interorganizacional, verificable fuera de línea y anclable a una identidad del mundo real — es la única combinación que nadie más arma. La persona tiene la llave de la que desciende la autoridad: AAuth tiene su raíz en DNS, los emisores empresariales en un tenant, los runtimes no tienen raíz alguna. La verificación fuera de línea es exclusiva de este enfoque en todo el mapa. Esto no afirma que todos los demás estén equivocados — resuelven problemas distintos, y la capa de autoridad que se ubica por encima de todos ellos, con raíz en una persona, está desocupada.
● El límite honesto — dónde la raíz en la persona realmente importa
Un mapa de mercado que solo enumera fortalezas no es creíble. Una raíz de confianza propiedad de una persona tiene demanda real solo donde el contexto exige que un humano haya autorizado algo — actos de gobierno, mandatos con validez legal, transacciones ciudadanas, consentimiento regulado. Donde la autoridad es puramente de máquina a máquina y ningún humano necesita estar demostrablemente detrás, una raíz de proveedor o un emisor organizacional suelen bastar, y son más baratos. Así que este es a la vez el mercado y su borde: el valor es mayor justo donde la ley, una institución o la rendición de cuentas exigen que una persona real respalde la acción del agente — y deliberadamente no intenta ser la opción por defecto para cada llamada automatizada entre dos servicios. Dos análisis separados llegaron de forma independiente a este mismo límite; la convergencia independiente en la frontera honesta de un sistema es una señal de credibilidad, no una debilidad.
● Componer, no competir
La posición a la que apuntamos es ser la capa de autoridad sobre la que todos los demás puedan construir — adoptando las mejores ideas sin adoptar protocolos completos: atenuación por salto (la subdelegación solo puede reducir la autoridad, nunca ampliarla), consentimiento asíncrono (la aprobación diferida / pendiente como flujo de primera clase) y modelos de ciclo de vida de los emisores empresariales. Un mandato con raíz en la persona es la fuente de verdad que se traduce a los protocolos de autorización que el ecosistema ya usa — montándose en los rieles existentes en lugar de pelear contra ellos. La prueba de “componer, no competir” es una integración, no un argumento.
Alineación con estándares: construido sobre los estándares abiertos hacia los que converge la categoría, e interoperable con ellos — ERC-8004, AP2, W3C Verifiable Credentials, SD-JWT y OID4VC — para que la componibilidad venga de diseño, no añadida después.
● Preguntas abiertas para la categoría
Un mapa de un campo vivo, trazado con honestidad, por el equipo que mide la categoría en lugar de hacerle marketing. Comparado contra una implementación de punta a punta en funcionamiento a mediados de 2026; los borradores de estándares y los estados de los productos evolucionan — las afirmaciones sensibles al tiempo se vuelven a verificar antes de publicar.