An alert fires at 2am. A Triage Agent inside Splunk enriches it in seconds. Then the workflow stops. Someone has to open a second tool to trigger the response. Someone has to open a third to create the ticket. The agent did its job perfectly, and the SOC still waited on a human to walk the output from one system to the next.
That handoff problem is not a Splunk problem. It is every vendor’s problem right now, and it is the reason Agent2Agent, or A2A, matters more than any single agent announcement.
Splunk’s new agents Triage, Detection Builder, SOP, Guided Response, Automation Builder, Malware Threat Reversing each do one job well. The interesting question is not what any one of them does alone. It is what happens when agents built by different teams, on different platforms, can hand work to each other directly. That is what A2A is for. And it is worth being direct about where things stand: A2A-mediated handoffs between production security agents are not shipping anywhere yet. What follows is the conceptual architecture, and why it is worth putting the building blocks in place now.
Two protocols, not one
A2A does not work alone. It sits alongside MCP, the Model Context Protocol, and the two solve different problems.
MCP connects an agent to its data and tools. Splunk’s MCP Server, generally available since February 2026, gives any MCP-compatible agent a governed way to run searches, pull asset context, and surface enrichment data from Splunk, no custom integration required.
A2A connects agents to each other, across vendor and platform boundaries. Where MCP is vertical agent to data. A2A is horizontal agent to agent. A production multi-agent SOC needs both. Triage happens in one context, containment in another, ticketing in a third. An agent that can only complete its own step and then wait for a human to restart the next one has compressed the task, not the workflow. A2A is the protocol built to make the full workflow move without that wait.
Use MCP when an agent needs to reach into Splunk’s data. Use A2A when one agent needs to hand work to another. This is not SOAR by another name. SOAR orchestrates fixed playbooks through integrations built one vendor at a time, and the logic lives centrally, in the SOAR platform. A2A is peer-to-peer: any A2A agent can discover and call any other A2A agent through a self-published Agent Card, no custom connector required, and the receiving agent applies its own reasoning rather than following a static script. The two are not in competition. A2A is how autonomous agents from different vendors decide what to do and hand work to each other; SOAR remains a natural place for the resulting actions to execute.
How A2A works
A2A runs on HTTP, Server-Sent Events, and JSON-RPC 2.0 existing web standards, chosen deliberately so infrastructure teams can adopt it without rearchitecting network controls.
- Agents publish an Agent Card. Every A2A-compliant agent exposes a JSON manifest at a well-known URL (/.well-known/agent-card.json) describing what it can do, what inputs it takes, and what authentication it requires. A2A v1.0 added Signed Agent Cards, so a receiving agent can cryptographically verify the card actually came from the domain that issued it the mechanism that stops a fraudulent agent from inserting itself into a workflow.
- A client agent delegates a Task. Fast operations return a result immediately. Long-running ones, a multi-stage investigation, a deep correlation across weeks of telemetry stream status updates over SSE, through a defined lifecycle: submitted, working, input-required, completed, failed, cancelled.
- The remote agent returns an Artifact. The structured output text, data, or files that the client agent routes forward, acts on, or surfaces to an analyst.
- Authentication rides on infrastructure you already govern. OAuth 2.0, API keys, mTLS, the same schemes your API management layer already enforces. A2A does not require a parallel trust system.
What security teams need to build now
Three things intersect directly with controls your team already owns, and they are worth starting before any agent in this stack reaches GA.
Agent identity is a PAM problem. Which agent may call which other agent, under what conditions, is a privileged access management question, not a new category. The recommendation would be to extend your existing IAM governance, apply to service accounts to cover agent identities.
Agent-to-agent traffic is audit material. Every task delegation, source, target, content, artifact, timestamp belongs in a durable log before volume makes retrofitting expensive. The Splunk platform can ingest and index this data today with no special integration; that part is straightforward. Getting analyst-grade value out of it inside Enterprise Security — correlation searches, notable events, risk scoring is a separate step. It means mapping agent traffic onto an existing CIM data model or building a custom one, the same onboarding work any new data source requires in ES.
Prompt injection is a common attack pattern and A2A does not sanitize task content. If an agent processes attacker-controlled data, a crafted log entry, a malicious filename and delegates a task based on it, the payload travels along. Input validation is an application-layer responsibility that needs to be designed in before any agent delegates via A2A, not added after.
**Final thoughts **
A2A is likely the next step where the agentic SOC needs to go next. The single-purpose agents are great, another dashboard is good but a protocol layer that lets every agent in an enterprise runs, regardless of vendor, work as one system instead of a shelf of disconnected point solutions. The first generation of agentic security was about giving one tool a brain. The next generation is about giving the entire stack a nervous system and Security leaders should continue to watch the A2A protocol closely as it matures.