Cisco ha planteado una arquitectura para coordinar varios agentes de inteligencia artificial dentro de un centro de operaciones de seguridad (SOC). Su propuesta combina dos protocolos abiertos con cometidos distintos: MCP conecta cada agente con las herramientas y los datos que necesita, mientras A2A permite delegar trabajo entre agentes desarrollados sobre plataformas diferentes.
La idea busca resolver un cuello de botella concreto. Un agente puede enriquecer una alerta en segundos, pero el flujo vuelve a depender de una persona si es necesario abrir otra herramienta para contener la amenaza y una tercera para crear una incidencia. Automatizar una etapa reduce su duración; conectar todas las etapas permitiría actuar sobre el proceso completo.
Dos protocolos para relaciones diferentes
Model Context Protocol (MCP) cubre la relación vertical entre un agente y sus recursos. Cisco afirma que Splunk MCP Server está disponible de forma general desde febrero de 2026. Un agente compatible puede utilizarlo para ejecutar búsquedas, recuperar contexto sobre activos y consultar datos de enriquecimiento de Splunk mediante un acceso gobernado.
Agent2Agent (A2A) aborda la relación horizontal. Su función es permitir que un agente descubra a otro y le encargue una tarea incluso cuando ambos proceden de proveedores o plataformas distintos. A2A no reemplaza a MCP: un SOC multiagente necesitaría ambos para consultar telemetría, trasladar una investigación y entregar su resultado al siguiente componente.
Este enfoque tampoco convierte A2A en un sustituto de SOAR. En la arquitectura descrita por Cisco, A2A serviría para que los agentes razonen y se repartan el trabajo, mientras que una plataforma SOAR podría seguir ejecutando las acciones resultantes mediante sus integraciones y procedimientos definidos.
La distinción también ayuda a situar el anuncio en su contexto: los traspasos A2A entre agentes de seguridad en producción todavía no se comercializan. Cisco presenta una arquitectura conceptual y recomienda preparar sus componentes, pero no demuestra todavía un sistema operativo en el que agentes de diferentes fabricantes funcionen como una única unidad.
Cómo se delegaría una investigación
A2A utiliza tecnologías web existentes: HTTP, Server-Sent Events (SSE) y JSON-RPC 2.0. Cada agente publica una Agent Card, un manifiesto JSON situado en una dirección conocida que describe sus capacidades, las entradas aceptadas y los requisitos de autenticación. La versión 1.0 incorpora Signed Agent Cards para verificar criptográficamente que la tarjeta procede del dominio que declara haberla emitido.
Después del descubrimiento, un agente cliente delega una tarea. Las operaciones rápidas pueden devolver directamente el resultado, mientras que una investigación prolongada puede comunicar por SSE estados como enviada, en curso, pendiente de información, completada, fallida o cancelada. Al terminar, el agente remoto entrega un artefacto estructurado —texto, datos o archivos— que puede pasar al siguiente agente o mostrarse a un analista.
Este modelo encaja con una evolución más amplia hacia la infraestructura soberana y aislada de Cisco en Canadá. La autenticación de A2A puede apoyarse en OAuth 2.0, claves de API o mTLS, pero utilizar mecanismos conocidos no elimina la necesidad de gobernar quién puede solicitar cada tarea.
Identidad, auditoría e inyección de prompts
Como recomendación conceptual, Cisco propone extender las políticas existentes de IAM y cuentas de servicio a las identidades de los agentes. El objetivo sería definir qué agente puede llamar a otro y bajo qué condiciones. También recomienda conservar de manera duradera el origen, el destino, el contenido, los artefactos y la marca temporal de cada delegación para reconstruir las decisiones y analizarlas posteriormente.
Splunk puede ingerir e indexar ese tráfico, según Cisco, aunque convertirlo en búsquedas de correlación, eventos relevantes o puntuaciones de riesgo exigiría mapear los registros a un modelo de datos existente o crear uno específico. Registrar intercambios no equivale por sí solo a obtener una auditoría útil: hacen falta una estructura común y reglas que permitan interpretar la actividad.
El riesgo más inmediato está en el contenido. A2A no sanea las tareas antes de trasladarlas. Si un agente procesa una entrada controlada por un atacante —por ejemplo, un registro manipulado o un nombre de archivo malicioso—, una carga diseñada para provocar una inyección de prompts puede viajar con la delegación. Cisco sostiene que la validación debe diseñarse en la capa de aplicación antes de activar estos flujos.
Según la previsión conceptual de Cisco, la utilidad práctica de A2A dependería tanto de la interoperabilidad como de los límites implantados a su alrededor. La identidad verificable, el registro completo y la validación de entradas son requisitos previos, no prestaciones que el protocolo resuelva automáticamente. Mientras maduran los flujos de producción, esa preparación determinaría si la automatización reduce esperas sin multiplicar privilegios ni propagar instrucciones hostiles.
