1. Panorama actual
La industria ha demostrado que es posible estandarizar partes importantes de la arquitectura agéntica. MCP se ha consolidado como interfaz de facto para conectar agentes con herramientas, datos y aplicaciones. Sin embargo, todavía no existe un estándar equivalente, ampliamente adoptado, que resuelva la interoperabilidad general entre agentes independientes.
El problema pendiente no es simplemente conseguir que dos agentes intercambien mensajes. Es lograr que puedan descubrirse, identificar a sus operadores, describir capacidades de forma comparable, delegarse tareas y autoridad, limitar permisos y producir resultados trazables mediante reglas comunes.
1.1 - MCP - Protocolo consolidado agente-herramienta
Model Context Protocol normaliza cómo una aplicación o agente accede a herramientas, recursos y servicios. La versión de julio de 2026 sustituyó el núcleo del protocolo basado en sesiones por un modelo stateless de petición-respuesta, reforzó la autorización y dejó el descubrimiento mediante server/discover como capacidad opcional. El ciclo de tareas pasó del núcleo experimental a una extensión.1
Su adopción transversal, sus SDK oficiales y su gobernanza dentro de la Agentic AI Foundation permiten considerarlo un estándar de facto en este ámbito concreto.2
MCP demuestra dos cosas relevantes para el debate:
- los proveedores pueden converger sobre una interfaz abierta.
- OAuth y los estándares web existentes pueden utilizarse como base de seguridad.
MCP no resuelve, por sí solo, la relación completa entre agentes autónomos. Un servidor MCP expone capacidades al cliente, no obstante no representa necesariamente a otro agente con identidad, autonomía, objetivos, ciclo de tareas y capacidad de delegación propios.
1.2 - A2A Protocol. En producción, con adopción en expansión
A2A Protocol fue creado por Google para la comunicación entre agentes independientes. Google lo lanzó en abril de 2025, lo donó a la Linux Foundation y, en agosto de ese año, el Agent Communication Protocol de IBM se integró en A2A. Desde agosto de 2026 es un proyecto de la Agentic AI Foundation, no una extensión privada de Google.3
Su versión 1.0, primera especificación estable, define:
- Descubrimiento mediante Agent Cards.
- Descripción de capacidades y mecanismos de seguridad.
- Negociación de versión, multitenencia y Agent Cards firmadas.
- Mensajes, tareas y artefactos.
- Estados, cancelación y seguimiento.
- Interacción síncrona, streaming y notificaciones.
- Bindings HTTP/JSON, JSON-RPC y gRPC.4
Es un protocolo abierto que ya cuenta con implementaciones en producción. El proyecto dispone de un Technology Compatibility Kit para sus tres bindings y de un repositorio de pruebas para sus SDK oficiales que reúne dos suites, ITK, para comprobar la interoperabilidad entre SDK, y ACTS, para comprobar su conformidad con la especificación.5,6 Superar estas pruebas no equivale a una certificación independiente ni demuestra, por sí solo, quién originó una solicitud, qué autoridad se delegó en cada salto o qué datos y operaciones sustentan el resultado. La Linux Foundation informa de más de 150 organizaciones que lo respaldan y de implementaciones en producción. Ese respaldo no permite cuantificar cuántas organizaciones lo utilizan efectivamente.7
Está integrado en las plataformas de agentes de Google Cloud, Microsoft Azure AI Foundry y Amazon Bedrock AgentCore, y Huawei lo ha adoptado como protocolo entre su asistente de sistema y los agentes de aplicación en HarmonyOS.3
Una experiencia de producción basada en A2A 0.3, escrita por una integrante del equipo de ingeniería de Eon y publicada en el blog de la fundación, identificó además carencias para transportar la identidad del solicitante y la procedencia necesaria para comprobar los resultados.8
1.3 - Otras iniciativas: descubrimiento y control del tráfico
AGNTCY, aportado por Cisco a la Linux Foundation9, ofrece un servicio de directorio de agentes (Agent Directory Service) con descubrimiento federado, metadatos descritos mediante el esquema OASF (Open Agentic Schema Framework)10 y firma y verificación criptográfica de los registros.11 Se ocupa del descubrimiento y de la descripción de capacidades e incorpora mecanismos de confianza federada mediante SPIFFE (Secure Production Identity Framework for Everyone) y su implementación de referencia SPIRE (SPIFFE Runtime Environment), entre dominios configurados para federarse. Esto no establece por sí solo confianza entre partes que no se conocen.12
Agentgateway, proyecto de la Agentic AI Foundation desde junio de 2026, aplica políticas de seguridad y observabilidad al tráfico MCP y A2A; es infraestructura de control, no un estándar de interoperabilidad.13
1.4 - Identidad y autorización. Existen las piezas, falta el perfil común
OAuth, OpenID Connect, JWT, PKCE, mTLS, DPoP y OAuth Token Exchange proporcionan mecanismos maduros para autenticar clientes, limitar acceso y delegar credenciales.
El problema aparece al encadenar agentes. Deben diferenciarse:
- la persona u organización que origina la instrucción;
- la aplicación cliente;
- el agente que decide;
- el operador del agente;
- los agentes delegados;
- el recurso final sobre el que se actúa.
El OpenID Foundation considera que OAuth funciona adecuadamente en escenarios sencillos y dentro de un mismo dominio de confianza, pero puede resultar insuficiente en operaciones autónomas, asíncronas, multiusuario o entre organizaciones.14
En el IETF conviven trabajos de distinta madurez. OAuth Identity Chaining es un borrador del grupo OAuth en la vía de estándares y se encuentra en la cola del RFC Editor; Transaction Tokens también es trabajo del grupo y ha alcanzado consenso interno.15,16 El perfil DAAP, específicamente orientado a agentes, sigue siendo una propuesta individual y no un documento adoptado por el grupo.17
Ninguno constituye todavía el perfil universal de identidad y delegación multiagente.
2. Qué funciona hoy: reservas, compras y pagos
Ya existen flujos operativos de compra y reserva ejecutados por agentes. Para valorar qué resuelven, conviene distinguir el acceso a un servicio, la autorización de una transacción y la interoperabilidad general entre agentes.
2.1 - Acceso mediante API o navegador
Un agente puede utilizar la API de un proveedor, directamente o expuesta como herramienta MCP, para realizar las operaciones que ese servicio permita. Esa integración no requiere comunicación entre dos agentes autónomos, el agente actúa como cliente de un servicio mediante una interfaz definida.
También puede operar formularios y controles de una web. Cuando utiliza la sesión del usuario sin acreditar una identidad propia, el servicio no dispone necesariamente de una distinción verificable entre usuario y agente, ni de los límites de la delegación. Es el problema de representación opaca que señala OpenID Foundation. Tampoco implica que todo agente de navegador sea indetectable.14
2.2 - Protocolos sectoriales de comercio y pagos
ACP (Agentic Commerce Protocol). Desarrollado conjuntamente por OpenAI y Stripe, sustenta Instant Checkout en ChatGPT proporcionando especificaciones abiertas para integrar procesos de compra entre agentes y comercios integrados.18 Define sesiones de compra mediante API, solicitudes firmadas, claves de idempotencia para evitar duplicados y notificaciones del estado del pedido.19 El comercio conserva la decisión de aceptar el pedido y procesa el cobro con su proveedor de pagos. El pago delegado establece un importe máximo y una caducidad para la autorización de cobro.20 Este ACP comercial es distinto del Agent Communication Protocol de IBM citado anteriormente.
AP2 (Agent Payments Protocol). Iniciado por Google, añade autorización verificable a los pagos agénticos y puede integrarse con A2A. Su versión 0.2 distingue mandatos de compra (Checkout Mandates) y de pago (Payment Mandates), vinculados mediante el hash del objeto de compra firmado. Admite aprobación de una compra concreta o autorización previa con restricciones para que el agente compre sin el usuario presente.21 La firma puede apoyarse en una credencial del usuario o en un proveedor de agentes de confianza que firma tras obtener su consentimiento; no siempre firma directamente el usuario con una clave propia. La aprobación se obtiene en una interfaz de confianza separada del razonamiento del modelo.22 Esta autorización técnica no acredita por sí sola que se hayan cumplido las condiciones jurídicas del consentimiento del ordenante previstas en la normativa de servicios de pago aplicable.23,24
Los mandatos de AP2 son un ejemplo concreto de intención firmada. Sin embargo, AP2 v0.2 excluye expresamente de su alcance la delegación de mandatos entre agentes y deja fuera las API de catálogo y el protocolo completo de comercio.21 Su desarrollo dentro de FIDO Alliance se recoge más adelante, en la sección de normalización institucional.
Redes de pago. Visa dispone de Trusted Agent Protocol, que utiliza firmas de mensajes HTTP para reconocer agentes admitidos por una red de pagos, incluso si inicialmente son desconocidos para el comercio.25 Mastercard Agent Pay también registra operaciones reales. Santander y Mastercard anunciaron en marzo de 2026 un pago ejecutado sobre infraestructura bancaria real, aunque en un piloto controlado y sin despliegue comercial general.26
Estas soluciones acreditan avances concretos en identidad, intención, límites y evidencia de transacciones. La confianza puede ser bilateral o multilateral, establecida por proveedores, emisores de credenciales y redes de pago. No es necesario que todas las contrapartes se conozcan previamente ni que el usuario apruebe cada pago en tiempo real.
Lo pendiente, y no parece poco, es generalizar esas garantías entre agentes independientes, tareas y dominios de confianza heterogéneos, con delegación sucesiva y reglas comunes.
3. Normalización institucional
En 2026, la interoperabilidad entre agentes forma parte de la agenda de organismos de naturaleza muy distinta como agencias gubernamentales, organismos de normalización internacionales y regionales, y foros técnicos de Internet. Ninguno ha asumido el problema completo. Cada uno lo aborda desde su mandato y con un grado de vinculación diferente. Por eso conviene distinguirlos por su naturaleza, que es la que determina el valor jurídico de lo que producen.
3.1 - Estados Unidos: NIST
El 17 de febrero de 2026, el Center for AI Standards and Innovation (CAISI) del NIST (National Institute of Standards and Technology) lanzó la AI Agent Standards Initiative, en coordinación con el Information Technology Laboratory (ITL) del propio NIST.27
La iniciativa se articula en tres pilares:
- Impulsar normas de agentes desarrolladas por la industria y la presencia estadounidense en los organismos internacionales.
- Fomentar protocolos abiertos de desarrollo comunitario.
- Investigar en seguridad e identidad de agentes.27
El NIST no anuncia un estándar propio de interoperabilidad. Su papel declarado es catalizar normas y protocolos liderados por la industria y la comunidad. 28
En ese marco, el NCCoE (National Cybersecurity Center of Excellence) publicó en febrero de 2026 un documento conceptual sobre identidad y autorización de agentes y recibió más de 600 respuestas. El resumen de comentarios, publicado el 29 de septiembre de 2026, contiene varias constataciones que coinciden con el diagnóstico de este documento:29
- Enfoque evolutivo. La gran mayoría de los participantes prefirió construir sobre estándares existentes, mediante extensiones y perfiles, antes que crear una pila de identidad específica para agentes.
- Identidad sin mecanismo común. Hubo casi unanimidad en que los agentes necesitan identidades no humanas propias y verificables, pero ningún consenso sobre cómo implementarlas.
- Delegación y responsabilidad. Preocupa que surjan lagunas de responsabilidad si las acciones posteriores no pueden vincularse, a lo largo de la cadena, con la persona o institución responsable.
- Intención firmada. Se considera necesaria, pero no existe un estándar ampliamente aceptado para expresarla.
- Auditoría. Los registros actuales recogen qué ocurrió, pero no por qué, bajo qué autoridad, ni con qué información.
El siguiente paso anunciado es un borrador de descripción de proyecto. Habrá una primera fase de uso empresarial, aplicada al desarrollo de software y una fase posterior centrada en agentes de consumidores.29 Los comentarios servirán para decidir si procede un ejercicio de demostración u otros productos del NCCoE.30 El proyecto está en fase de definición, no se ha anunciado una norma de interoperabilidad.
3.2 - Unión Europea: CEN-CENELEC JTC 21
El Reglamento (UE) 2024/1689, modificado por el Reglamento (UE) 2026/1744, no define el término “agente”.31 Las normas armonizadas que elabora el comité técnico conjunto CEN-CENELEC JTC 21 en respuesta a la petición de normalización de la Comisión M/613, que modifica la M/593, son de aplicación voluntaria. Las obligaciones proceden del Reglamento y las normas ofrecen una vía técnica para demostrar su cumplimiento. Conforme al artículo 40.1, una vez publicadas sus referencias en el Diario Oficial de la Unión Europea, el cumplimiento de estas normas otorga presunción de conformidad con los requisitos del Capítulo III, Sección 2, para los sistemas de IA de alto riesgo, y con las obligaciones del Capítulo V, Secciones 2 y 3, para los modelos de IA de uso general, únicamente en la medida en que dichas normas cubran esos requisitos u obligaciones.32,33
Los aspectos agénticos se tratan dentro del alcance de tres proyectos:31
- prEN 18229-1: registro, transparencia y supervisión humana (artículos 12 a 14).
- prEN 18282: ciberseguridad (artículo 15.5), incluida la gestión de privilegios.
- prEN 18228: gestión de riesgos (artículo 9), que tiene en cuenta el nivel de autonomía.
Estas normas concretan técnicamente requisitos que el Reglamento impone a los sistemas de IA de alto riesgo y cuyo cumplimiento corresponde al proveedor. No regulan la interoperabilidad entre agentes de proveedores distintos. Esos requisitos serán aplicables desde el 2 de diciembre de 2027 para los sistemas clasificados como de alto riesgo en virtud del artículo 6.2 y del anexo III, y desde el 2 de agosto de 2028 para los del artículo 6.1 y del anexo I (artículo 113, en la redacción dada por el Reglamento (UE) 2026/1744).32 Según el estudio citado, estos borradores todavía no habían entrado en información pública a principios de 2026. El detalle agéntico procede de ese estudio.31
En el plano supervisor, la Agencia Española de Protección de Datos (AEPD) publicó el 18 de febrero de 2026 unas orientaciones sobre IA agéntica desde la perspectiva de la protección de datos. Analizan las vulnerabilidades y amenazas propias de estos sistemas y proponen medidas para responsables y encargados del tratamiento.34 No son una norma técnica, pero constituyen una referencia administrativa española directamente relacionada.
3.3 - IETF
El IETF (Internet Engineering Task Force) trabaja en tres líneas.
Comunicación entre agentes. El grupo de trabajo agentproto (Agent Communication Protocols) se creó en estado BoF (Birds of a Feather, fase exploratoria previa a un grupo) en junio de 2026, y su carta constitutiva se aprobó el 8 de octubre de 2026.35 Su objeto es un protocolo base de gestión del diálogo agéntico. Define identificadores de diálogo, su ciclo de vida y la propagación del contexto a través de intermediarios y fronteras de confianza, con vinculaciones sobre HTTP, QUIC, WebTransport, WebRTC o MoQ.36
La carta precisa varios límites. El protocolo no sustituye a MCP ni a A2A, que podrán transportar ese contexto con sus propios mecanismos. La identidad, la autenticación y la autorización se resolverán reutilizando piezas existentes, descritas en una arquitectura de referencia informativa. Las estructuras de datos de auditoría quedan expresamente fuera de su alcance. Los hitos previstos son los casos de uso en diciembre de 2026, la arquitectura en febrero de 2027 y el envío del protocolo al IESG (Internet Engineering Steering Group) en marzo de 2028.36
Identidad y autorización. El grupo WIMSE (Workload Identity in Multi-System Environments) publicó en septiembre de 2026, como documento del grupo, el borrador informativo AI Identity Management System.37 Este borrador no crea protocolos nuevos, sino que describe cómo combinar WIMSE, SPIFFE, OAuth y el Shared Signals Framework de OpenID para identificar, autenticar y autorizar agentes.
Para este documento es especialmente relevante el apartado de auditoría del borrador. Este exige, como requisito técnico de la arquitectura propuesta, registros duraderos que permitan detectar manipulaciones, con un contenido mínimo:
- identificador autenticado del agente;
- sujeto delegante, cuando exista;
- recurso afectado;
- acción y decisión de autorización;
- marca temporal e identificador de correlación;
- estado de riesgo;
- eventos de remediación o revocación y su causa.
Este trabajo complementa los borradores del grupo OAuth citados anteriormente en la sección de identidad y autorización.
Descubrimiento. El grupo propuesto DAWN (Discovery of Agents With Names), del área de Internet, tiene su carta en revisión externa. Su alcance se limita al descubrimiento inicial de información pública mínima sobre agentes dentro de redes locales, organizaciones o relaciones de confianza entre organizaciones, y excluye expresamente la búsqueda abierta, la clasificación y la selección por capacidades.38
3.4 - FIDO Alliance
El 28 de abril de 2026, FIDO Alliance anunció trabajos sobre autenticación agéntica y pagos, mediante sus grupos Agentic Authentication Technical Working Group y Payments Technical Working Group. Recibió AP2 de Google y Verifiable Intent de Mastercard, desarrollado conjuntamente con Google y compatible con AP2. El trabajo busca verificar instrucciones del usuario, autenticar agentes y limitar la delegación comercial. Las aportaciones se revisan dentro de su proceso de elaboración de especificaciones.39
3.5 - ITU-T
La Recomendación F.748.93 (Framework and Requirements for AI Agent Interoperability) tuvo su origen en una propuesta de la China Academy of Information and Communications Technology y del Nanjing Research Institute of Next-generation Artificial Intelligence, presentada en septiembre de 2025.40 Obtuvo el consentimiento del Grupo de Estudio 21 el 17 de julio de 2026 y fue aprobada por el procedimiento AAP (Alternative Approval Process) el 29 de agosto de 2026.41 Está en vigor, aunque su publicación definitiva sigue pendiente.42
Según el resumen oficial, la Recomendación establece requisitos para los componentes básicos, la interoperabilidad y las interacciones de aplicación entre agentes.41 Su texto aún no se ha publicado, por lo que su contenido normativo no puede verificarse públicamente.
Dos precisiones son necesarias:
- Naturaleza. Es una recomendación voluntaria de marco y requisitos, no la especificación de un protocolo.
- Enlace con seguridad. El Grupo de Estudio 21 remitió una comunicación de enlace sobre ella al Grupo de Estudio 17 (seguridad), y un miembro presentó una propuesta de respuesta para su reunión de septiembre de 2026.43
En paralelo, el Grupo de Estudio 21 valora una recomendación sobre plataformas de agentes (F.AIAP), prevista para 2027 y en enlace con ISO/IEC JTC 1/SC 42.44
3.6 - ISO/IEC JTC 1 (SC 42 y SC 27)
Según Nannini et al., a abril de 2026, no existía una definición de agente acordada internacionalmente y se preveía que la revisión de ISO/IEC 22989 abordara esas definiciones.31
Del subcomité de inteligencia artificial de ISO y CEI (Comisión Electrotécnica Internacional), ISO/IEC JTC 1/SC 42 (Subcomité 42 del Comité Técnico Conjunto 1, de tecnologías de la información), son relevantes ISO/IEC 42005:2025 (evaluación de impacto) e ISO/IEC FDIS 42105 (supervisión humana, en votación final). El subcomité de seguridad de la información, ISO/IEC JTC 1/SC 27, publicó el 14 de octubre de 2026 ISO/IEC 27090:2026, de carácter orientativo, sobre amenazas de seguridad específicas de los sistemas de IA.45
Los autores identifican limitaciones específicas, por una parte, ISO/IEC 42005 no ofrece una metodología para evaluar los impactos indirectos de la delegación entre subagentes, a su vez el borrador de ISO/IEC 42105 no considera los sistemas agénticos compuestos como unidad de análisis y por último, ISO/IEC 27090 ofrece orientaciones, sin requisitos verificables.31
3.7 - W3C
El W3C (World Wide Web Consortium) acoge el AI Agent Protocol Community Group. Su misión es desarrollar protocolos abiertos para que los agentes se descubran, se identifiquen y colaboren en la Web, y su alcance incluye modelos de identidad de agentes e interoperabilidad con los protocolos web existentes.46 Los grupos comunitarios del W3C no producen Recomendaciones del W3C, por lo que sus especificaciones carecen de estatus normativo formal.47
3.8 - Lectura de conjunto
Si se cruzan los seis vacíos que se exponen en la sección siguiente con la actividad institucional, el resultado es el siguiente:
| Vacío
|
Organismos y proyectos implicados | Estado |
| Descubrimiento confiable | IETF DAWN (propuesto); AGNTCY (código abierto); W3C (grupo comunitario) | DAWN limitado a entornos de confianza; AGNTCY con registros firmados, sin marco de confianza común entre partes desconocidas |
| Semántica de capacidades | OASF de AGNTCY (esquema abierto) | Esquema abierto sin estatus normativo |
| Identidad diferenciada | IETF (WIMSE, OAuth); FIDO; NCCoE | Borradores, trabajos sectoriales y proyecto NCCoE en preparación |
| Delegación multiagente | IETF (OAuth); FIDO (autorización comercial); NCCoE | Soluciones sectoriales de autorización; AP2 excluye la delegación entre agentes; sin perfil general común |
| Procedencia y evidencia | IETF WIMSE; FIDO (mandatos y recibos AP2)21; SCITT (Supply Chain Integrity, Transparency and Trust), citado por el NCCoE29 | Evidencia transaccional sectorial y borradores; sin estándar general de procedencia multiagente; las estructuras de datos de auditoría quedan fuera del alcance de agentproto |
| Conformidad de interoperabilidad multiagente | Ningún esquema institucional general identificado | Pruebas específicas de proyectos e integraciones; sin certificación independiente del perfil multiagente general |
De este cruce se desprenden tres observaciones:
- El reparto es por capas y nadie tiene el mandato completo. El IETF trata el diálogo y la autorización, la ITU-T el marco de requisitos y CEN-CENELEC los requisitos de los sistemas de alto riesgo. Existe coordinación mediante comunicaciones de enlace, pero no se ha identificado un mapa común entre sus requisitos.
- La naturaleza jurídica diverge. Dentro de los instrumentos examinados, solo las normas armonizadas europeas pueden generar presunción de conformidad, una vez citadas en el Diario Oficial, y no tratan la interoperabilidad. Las recomendaciones de la ITU-T y los RFC del IETF son voluntarios.
- El calendario es largo. El envío del protocolo de agentproto al IESG está previsto para marzo de 2028, y el proyecto del NCCoE aún no tiene ni borrador de descripción de proyecto.
Esto confirma que el problema ha entrado en la agenda formal de normalización. No demuestra que exista ya una solución técnica común adoptada por la industria.
4. Qué no está resuelto
Los vacíos pueden resumirse en seis puntos:
- Descubrimiento confiable.A2A y AGNTCY permiten publicar y firmar descriptores de agentes, y el IETF tiene un grupo propuesto para el descubrimiento en entornos de confianza, pero no existe un directorio universal ni un marco de confianza común para verificar conjuntamente identidad, operador y capacidades entre partes que no se conocen.
- Semántica de capacidades.Dos agentes pueden intercambiar JSON y, aun así, interpretar de forma distinta una tarea, sus restricciones o el resultado esperado.
- Identidad diferenciada.No hay un mecanismo universal para distinguir y vincular de forma verificable usuario, aplicación, agente, operador e instancia ejecutora.
- Delegación multiagente.Existen soluciones sectoriales de autorización, como los mandatos AP2, pero falta un perfil general común para conservar la autoridad original, reducir permisos en cada salto, limitar la re-delegación y revocar toda la cadena.
- Procedencia y evidencia.No está normalizado cómo demostrar qué agentes, modelos, herramientas, datos, políticas y autorizaciones produjeron un resultado.
- A2A ya ofrece un TCK y las suites ITK y ACTS para el contrato del protocolo, pero faltan certificación independiente y pruebas generalizadas que incluyan identidad, delegación y procedencia.
4.1 - Amenazas específicas de la comunicación entre agentes
El Top 10 for Agentic Applications de OWASP (Open Worldwide Application Security Project), publicado en diciembre de 2025, recoge varios riesgos que afectan directamente a la comunicación entre agentes, entre ellos: abuso de identidad y privilegios (ASI03), vulnerabilidades de la cadena de suministro en ecosistemas MCP y A2A (ASI04), comunicación insegura entre agentes mediante mensajes suplantados (ASI07) y fallos en cascada (ASI08).48
5. Conclusiones
- Existen estándares consolidados para conectar agentes con herramientas y protocolos operativos para intercambiar tareas entre agentes.
- MCP prueba que la estandarización abierta de la infraestructura agéntica es viable y puede alcanzar adopción transversal.
- A2A Protocol constituye un avance concreto para mensajes y tareas entre agentes, pero todavía no equivale a un estándar industrial consolidado de interoperabilidad general.
- La brecha se encuentra en la capa de confianza, cabe señalar: descubrimiento confiable, identidad verificable, delegación limitada, semántica de capacidades, procedencia y conformidad. Un protocolo mínimo útil podría concentrarse en esas piezas y reutilizar los estándares web existentes.
- Todavía no existe un estándar industrial ampliamente adoptado que permita a agentes independientes descubrirse, identificarse, delegarse autoridad y producir resultados verificables mediante un marco común.
6. Fuentes
- Model Context Protocol, “The 2026-07-28 Specification”. https://blog.modelcontextprotocol.io/posts/2026-07-28/
- Linux Foundation, “Linux Foundation Announces the Formation of the Agentic AI Foundation”. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
- Agentic AI Foundation, “A2A joins AAIF’s open agentic stack”. https://aaif.io/blog/a2a-joins-aaif
- A2A Project, especificación v1.0.1 y cambios introducidos en v1.0. https://a2a-protocol.org/v1.0.1/whats-new-v1/
- A2A Project, a2a-tck, pruebas oficiales de conformidad para HTTP/JSON, JSON-RPC y gRPC. https://github.com/a2aproject/a2a-tck
- A2A Project, a2a-itk, repositorio oficial de pruebas de interoperabilidad —ITK— y conformidad —ACTS— para los SDK oficiales. https://github.com/a2aproject/a2a-itk
- Linux Foundation, “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year”. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
- Agentic AI Foundation, “What We Learned Putting A2A Into Production”. https://aaif.io/blog/what-we-learned-putting-a2a-into-production
- Linux Foundation, “Linux Foundation Welcomes the AGNTCY Project to Standardize Open Multi-Agent System Infrastructure and Break Down AI Agent Silos”, 29 de julio de 2025. https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos
- AGNTCY, “Agent Directory Service”: descubrimiento por capacidades mediante OASF y arquitectura federada. https://dir.agntcy.org/latest/
- AGNTCY, Directory: modelo de confianza y firma y verificación de registros. https://dir.agntcy.org/latest/dir/dir-component-trust-model/
- AGNTCY, Directory: perfiles de federación y requisitos de intercambio de confianza entre dominios. https://dir.agntcy.org/latest/dir/dir-federation-profiles/
- agentgateway, “agentgateway Joins AAIF as an Open Gateway for Agentic AI Infrastructure”, 4 de junio de 2026. https://agentgateway.dev/blog/2026-06-04-agentgateway-joins-aaif/
- OpenID Foundation, “Identity Management for Agentic AI”. https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
- IETF OAuth Working Group, “OAuth Identity and Authorization Chaining Across Domains”, Internet-Draft. https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/
- IETF OAuth Working Group, “Transaction Tokens”, Internet-Draft. https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/
- IETF Datatracker, “OAuth Profile for Delegated AI Agent Authorization”, Internet-Draft individual. https://datatracker.ietf.org/doc/draft-mishra-oauth-agent-grants/
- Stripe, “Developing an open standard for agentic commerce”, 29 de septiembre de 2025. https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce
- OpenAI, “Agentic Checkout Spec”: sesiones, autenticación de solicitudes, idempotencia y notificaciones. https://developers.openai.com/commerce/specs/checkout
- OpenAI, “Key concepts”: funciones del comercio y pago delegado con importe máximo y caducidad. https://developers.openai.com/commerce/guides/key-concepts
- AP2, presentación del protocolo e integración con A2Ay especificación v0.2: mandatos de compra y pago, modalidades directa y autónoma, y exclusión de la delegación entre agentes.
- AP2, “Agent Authorization Framework”: modelos User Credential y Trusted Agent Provider. https://ap2-protocol.org/ap2/agent_authorization/
- Directiva (UE) 2015/2366 (PSD2), artículo 64. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32015L2366
- Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera, artículo 36. https://www.boe.es/buscar/act.php?id=BOE-A-2018-16036
- Visa, “Trusted Agent Protocol — Merchant specifications”: reconocimiento de agentes y modelo de confianza mediante firmas. https://developer.visa.com/docs/trusted-agent-protocol/trusted-agent-protocol-specifications
- Mastercard y Santander, “Santander and Mastercard complete Europe’s first live end-to-end payment executed by an AI agent”, 2 de marzo de 2026; piloto controlado sobre infraestructura real. https://www.mastercard.com/news/europe/en/newsroom/press-releases/en/2026/santander-and-mastercard-complete-europe-s-first-live-end-to-end-payment-executed-by-an-ai-agent/
- NIST, “Announcing the ‘AI Agent Standards Initiative’ for Interoperable and Secure Innovation”, 17 de febrero de 2026. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure
- NIST, “AI Agent Standards Initiative”. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
- NIST NCCoE, “Summary of Comments on the Concept Paper”, 29 de septiembre de 2026. https://pages.nist.gov/nccoe-ai-identity/summary-of-comments.html
- NIST NCCoE, “Software and AI Agent Identity and Authorization”. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
- Nannini et al., “AI Agents Under EU Law: A Compliance Architecture for AI Providers”, arXiv:2604.04604, abril de 2026. https://arxiv.org/abs/2604.04604
- Reglamento (UE) 2024/1689, modificado por el Reglamento (UE) 2026/1744, artículos 40 y 113 (texto consolidado a 27 de julio de 2026). https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:02024R1689-20260727
- CEN-CENELEC, “Artificial Intelligence”, programa de trabajo del JTC 21 y referencia al mandato M/613. https://wp2026.cencenelec.eu/sectors-list/digital-society/
- AEPD, nota de prensa sobre las orientaciones de IA agéntica, 18 de febrero de 2026. https://www.aepd.es/prensa-y-comunicacion/notas-de-prensa/la-agencia-publica-unas-orientaciones-sobre-inteligencia
- IETF, historial del grupo agentproto. https://datatracker.ietf.org/group/agentproto/history/
- IETF, carta constitutiva del grupo de trabajo agentproto. https://datatracker.ietf.org/group/agentproto/about/
- IETF WIMSE Working Group, “AI Identity Management System”, draft-ietf-wimse-aims-00, 15 de septiembre de 2026. https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/
- IETF, grupo propuesto DAWN (Discovery of Agents With Names). https://datatracker.ietf.org/group/dawn/about/
- FIDO Alliance, “FIDO Alliance to Develop Standards for Trusted AI Agent Interactions”, 28 de abril de 2026. https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/
- ITU-T Study Group 21, contribución C-271, propuesta original de F.AAI. https://www.itu.int/md/T25-SG21-C-0271
- ITU-T, ficha AAP de la Recomendación F.748.93. https://www.itu.int/t/aap/recdetails/11657
- ITU-T, Recomendación F.748.93, “Framework and Requirements for AI Agent Interoperability”. https://www.itu.int/rec/T-REC-F.748.93-202608-I/en
- ITU-T SG17, contribución C-656, propuesta de respuesta a la comunicación de enlace del SG21 sobre F.748.93. https://www.itu.int/md/T25-SG17-C-0656/en
- ITU-T, programa de trabajo, F.AIAP. https://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=22129
- ISO, fichas oficiales de ISO/IEC 27090:2026, ISO/IEC 42005:2025e ISO/IEC FDIS 42105.
- W3C, AI Agent Protocol Community Group. https://www.w3.org/groups/cg/agentprotocol
- W3C, FAQ de Community and Business Groups: sus informes no son estándares W3C. https://www.w3.org/community/about/faq/
- OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications”, diciembre de 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
Nota de Redacción de www.elderecho.com: Informar que la imagen que ilustra la publicación de esta tribuna ha sido generada con Inteligencia Artificial.
ElDerecho.com no comparte necesariamente ni se responsabiliza de las opiniones expresadas por los autores o colaboradores de esta publicación