All Articles

Basics & Security Analysis of AI Protocols: MCP, A2A, and AP2

Explore the security analysis of AI protocols shaping the future of AI. MCP, A2A, and AP2 form the backbone of agentic systems but without strong safeguards, these protocols could expose the next generation of AI infrastructure to serious security risks.

URL copied

The AI industry is heading into an agent-driven future, and three protocols are emerging as the plumbing for AI: Anthropic's Model Context Protocol (MCP), Google's Agent-to-Agent (A2A) protocol, and the newly announced Agent Payments Protocol (AP2). Protocols like these could underpin a range of agentic workflows, from SOC automation, where AI agents investigate alerts across multiple security tools, to multi-agent collaboration and autonomous payments.

Each is critical for AI infrastructure, but as we've learned repeatedly in cybersecurity, convenience and security rarely come hand in hand.

Having analyzed these protocols from both technical implementation and security perspectives, the picture that emerges is both promising and deeply concerning. We're building the interstate highway system for AI agents, but we're doing it without proper guardrails, traffic controls, or even basic security checkpoints.

The Protocol Trinity: Different Problems, Converging Solutions

Model Context Protocol (MCP): The Universal Connector

MCP functions as a standardized bridge between AI models and external systems through a client-server architecture. MCP clients (embedded in applications like Claude Desktop, Cursor IDE, or custom applications) communicate with MCP servers that expose specific capabilities through a JSON-RPC-based protocol over stdio, SSE, or WebSocket transports.

In layman’s terms, it is essentially a universal connector that enables AI systems to communicate consistently with other software or databases. Apps use an MCP “client” to send requests to an MCP “server,” which performs specific actions in response.

Visual Representation: 

Technical Architecture:

1{
2  "jsonrpc": "2.0",
3  "method": "tools/call",
4  "params": {
5    "name": "database_query",
6    "arguments": {
7      "query": "SELECT * FROM users WHERE department = 'engineering'",
8      "connection": "primary"
9    }
10  },
11  "id": "call_123"
12}
13

‍

Scenario: Automated Threat Investigation and Response

Context: A SOC team wants to speed up the triage of security alerts coming from their SIEM (like Splunk or Chronicle). Instead of analysts manually querying multiple tools, they use MCP as the bridge between their AI assistant and their operational systems.

How MCP Fits In

  1. MCP Client: The SOC’s AI analyst (say, Legion) is the MCP client. It acts as the interface through which analysts ask questions, such as: “Show me the last 10 failed logins for this user and correlate with firewall traffic.”

  2. MCP Server: On the backend, the MCP server exposes connectors to SOC systems, for example:
    • Splunk or ELK (for log searches)
    • CrowdStrike API (for endpoint data)
    • Okta API (for authentication events)
    • Jira or ServiceNow (for case creation)

  3. Each connector is defined as a “tool” in the MCP schema (e.g., query_siem, get_endpoint_status, create_ticket).

Workflow Example: AI Analyst (MCP Client) → MCP Server

method: "tools/call"
params:
  name: "query_siem"
  arguments:
    query: "index=auth failed_login user=jsmith | stats count by src_ip"

The MCP server runs the Splunk query, returns results, and the AI can then call another MCP tool:‍

name: "get_endpoint_status"
arguments:
  host: "192.168.1.22"

The AI correlates results, summarizes findings, and can automatically open an incident via:

name: "create_ticket"
arguments:
  severity: "High"
  summary: "Repeated failed logins detected for jsmith"

‍

Security Considerations

  • Credential aggregation risk: One compromised MCP client could expose multiple API keys (SIEM, EDR, etc.).
  • Schema poisoning: If an attacker injects malicious JSON schema data, it could alter what the AI interprets or requests.
  • Mitigation: Use Docker MCP Gateway interceptors and strict per-tool access scopes.

Agent-to-Agent (A2A): The Coordination Protocol

A2A enables autonomous agents to discover and communicate through standardized Agent Cards served over HTTPS and JSON-RPC communication patterns. The protocol supports three communication models: request/response with polling, Server-Sent Events for real-time updates, and push notifications for asynchronous operations.

Basically, A2A lets AI agents automatically find, connect, and collaborate with each other safely and efficiently, no humans in the loop.

Visual Representation: 

Technical Protocol Structure:

{
  "agent_id": "procurement-agent-v2.1",
  "version": "2.1.0",
  "skills": [
    {
      "name": "vendor_evaluation",
      "description": "Analyze vendor proposals against procurement criteria",
      "parameters": {
        "criteria": {"type": "object"},
        "proposals": {"type": "array"}
      }
    }
  ],
  "communication_modes": ["request_response", "sse", "push"],
  "security_requirements": {
    "authentication": "oauth2",
    "encryption": "tls_1.3_minimum"
  }
}

‍

Scenario: Automated Incident Collaboration Between Security Agents

Context: Your SOC runs multiple specialized AI agents: one monitors network traffic, another investigates suspicious users, another handles remediation actions (like isolating a device or resetting credentials). A2A provides the common protocol that lets these agents talk to each other directly, securely, automatically, and in real time.

How It Works in Practice

  1. Agent Discovery via Agent Cards
    • Each SOC agent publishes an Agent Card, a digital profile that says:
      • “I’m a Threat Detection Agent.”
      • “I can analyze network logs and spot anomalies.”
      • “Here’s how to contact me securely.”
    • The A2A system keeps these cards available over HTTPS, so other agents can find and verify them.

Example:‍

{
  "agent_id": "threat-detector-v2",
  "skills": ["network_log_analysis", "malware_pattern_detection"],
  "authentication": "oauth2",
  "encryption": "tls_1.3"
}

‍

  1. Agent-to-Agent Workflow
    • The Threat Detection Agent flags unusual outbound traffic from a server.
    • It sends a message via A2A to the Endpoint Response Agent, saying:

      “Investigate host server-22 for potential C2 beacon activity.”

    • The Endpoint Agent checks EDR data and replies with a summary or alert.
    • Simultaneously, it notifies the Incident Coordination Agent to open a ticket in ServiceNow.
  2. Communication Models in Action
    • Request/Response: Threat Detector asks → Endpoint Agent replies.
    • Server-Sent Events: Endpoint Agent streams live scan results back.
    • Push Notification: Incident Coordinator gets notified once a full report is ready.

Critical Security Concerns

  • Agent Card Spoofing: Malicious agents advertising false capabilities through manipulated HTTPS-served metadata
  • Capability Hijacking: Compromised agents with inflated skill advertisements capturing disproportionate task assignments
  • Communication Channel Attacks: Man-in-the-middle and session hijacking on agent-to-agent communications
  • Workflow Injection: Malicious agents inserting unauthorized tasks into legitimate multi-agent workflows

Agent Payments Protocol (AP2): The Commerce Enabler

AP2 extends A2A with cryptographically-signed Verifiable Digital Credentials (VDCs) to enable autonomous financial transactions. The protocol implements a two-stage mandate system using ECDSA signatures and supports multiple payment rails, including traditional card networks, real-time payment systems, and blockchain-based settlements.

Basically, AP2 lets AI agents make trusted, auditable payments automatically without a human typing in a credit card number.

Visual Representation: 

Technical Mandate Structure:

{
  "intent_mandate": {
    "mandate_id": "im_7f8e9d2a1b3c4f5e",
    "user_id": "enterprise_user_12345",
    "conditions": {
      "item_category": "cloud_services",
      "max_amount": {"value": 5000, "currency": "USD"},
      "vendor_whitelist": ["aws", "gcp", "azure"],
      "approval_threshold": {"value": 1000, "requires_human": true}
    },
    "signature": "304502210089abc...",
    "timestamp": "2025-01-15T10:30:00Z",
    "expires_at": "2025-01-16T10:30:00Z"
  },
  "cart_mandate": {
    "mandate_id": "cm_8g9h0e3b2c4d5f6g",
    "references_intent": "im_7f8e9d2a1b3c4f5e",
    "line_items": [
      {
        "vendor": "aws",
        "service": "ec2_reserved_instances",
        "amount": {"value": 3500, "currency": "USD"},
        "contract_terms": "1_year_reserved"
      }
    ],
    "payment_method": "corporate_card_ending_1234",
    "signature": "3046022100f4def...",
    "execution_timestamp": "2025-01-15T11:45:00Z"
  }
}

‍

Scenario: Secure Autonomous Cloud Resource Payments

Context: Your company’s AI agents automatically manage cloud infrastructure — spinning up or shutting down virtual machines based on workload. To do that, they sometimes need to authorize and execute payments (e.g., buying more compute time or storage). AP2 allows those agents to make these payments automatically — but with strong security guardrails.

How It Works

  1. Step 1 – Intent Mandate (the plan)
    • The agent first creates an Intent Mandate describing what it wants to do.

      Example:  “Purchase $2,000 worth of AWS compute credits for Project Orion.”

    • This mandate includes:
      • Vendor whitelist (AWS only)
      • Spending cap ($5,000 max)
      • Expiry time (valid for 24 hours)
      • Digital signature (ECDSA) proving it came from an authorized agent
    • A human or rule engine reviews this intent before any money moves.

  2. Step 2 – Cart Mandate (the action)
    • Once the intent is approved, the agent generates a Cart Mandate — the actual payment order.
    • It references the original intent, ensuring the details match (no one changed the vendor or amount).
    • This mandate is also cryptographically signed and executed via a secure payment rail (e.g., corporate card API or blockchain payment).

  3. Security Enforcement During Payment
    • Independent validator checks that:
      • The intent and cart match exactly.
      • The agent’s digital credential is still valid (hasn’t been revoked).
      • The payment doesn’t exceed limits or policy.
    • Real-time monitoring watches for anomalies:
      • Multiple large payments in short time windows
      • Changes to vendor lists
      • Repeated failed authorizations

  4. Audit & Traceability
    • Every mandate (intent and payment) is stored with its cryptographic proof.
    • Auditors can later verify every transaction end-to-end

Security Benefits

Cryptographic Signatures: Ensures that only verified agents can create or authorize payments.

Two-Stage Mandate System: Prevents “prompt injection” or unauthorized payments by requiring two consistent steps (intent → execution).

Vendor Whitelisting & Spending Caps: Limits the blast radius of any compromise.

Cross-Protocol Correlation: AP2 can check MCP/A2A activity logs before allowing a transaction — ensuring payment actions match legitimate workflows.

Immutable Audit Trail: Every payment is traceable, signed, and non-repudiable.

Without these controls, a single compromised AI could:

  • Create fake purchase requests (“buy 1000 GPUs from an attacker’s vendor”)
  • Manipulate prices between intent and payment
  • Execute valid-looking, cryptographically signed frauds

That’s why AP2’s mandate validation and signature chaining are essential. They make it nearly impossible for a rogue or manipulated agent to spend money unchecked.

Architectural Convergence

What's fascinating is how these protocols complement each other in ways that suggest a coordinated vision for agentic infrastructure:

  • MCP provides vertical integration (agent-to-tool)
  • A2A enables horizontal integration (agent-to-agent)
  • AP2 adds transactional capability (agent-to-commerce)

The intended architecture is clear: an AI agent uses MCP to access your calendar and email, A2A to coordinate with specialized booking agents, and AP2 to complete transactions autonomously. It's elegant in theory, but the security implications are staggering.

Implementation Recommendations: Protocol-Specific Security Controls

MCP Security Implementation

Mandatory Tool Validation Framework: Deploy comprehensive MCP server scanning that extends beyond basic description fields:

Static Analysis Requirements:

  1. Scan all tool metadata (names, types, defaults, enums)
  2. Source code analysis for dynamic output generation logic
  3. Linguistic pattern detection for embedded prompts
  4. Schema structure validation against known-good templates

Runtime Protection with Docker MCP Gateway: Implement Docker's MCP Gateway interceptors for surgical attack prevention:

# Example: Repository isolation interceptor
def github_repository_interceptor(request):
    if request.tool == 'github':
        session_repo = get_session_repo()
        if session_repo and request.repo != session_repo:
            raise SecurityError("Cross-repository access blocked")
    return request

‍

Continuous Behavior Monitoring: Deploy real-time MCP activity analysis:

  • Tool call frequency analysis to detect automated attacks
  • Data access pattern monitoring for unusual correlation activities
  • Output analysis for prompt injection indicators
  • Cross-tool interaction mapping to identify attack chains

A2A Security Architecture

Agent Authentication Infrastructure: Implement certificate-based mutual authentication for all agent communications:

Agent Registration Process:

  1. Certificate generation with organizational root CA
  2. Agent Card cryptographic signing with private key
  3. Capability verification through controlled testing
  4. Regular certificate rotation (30-day maximum)

Communication Security Controls: Establish secure communication channels with comprehensive auditing:

Required A2A Security Headers:

  • X-Agent-ID: Cryptographically verified agent identifier
  • X-Capability-Hash: Tamper-evident capability fingerprint  
  • X-Session-Token: Short-lived session authentication
  • X-Audit-ID: Immutable audit trail identifier

Agent Capability Verification System: Never trust advertised capabilities without independent verification:

class AgentCapabilityVerifier:
    def verify_agent(self, agent_card):
        test_results = self.sandbox_test(agent_card.capabilities)
        capability_match = self.validate_capabilities(test_results)
        return self.issue_capability_certificate(capability_match)

‍

AP2 Security Implementation

Mandate Validation Infrastructure: Implement independent mandate validation outside AI agent context:

Multi-Stage Validation Process:

  1. AI-generated Intent Mandate creation
  2. Independent rule-engine validation of mandate logic
  3. Human approval workflow for high-value transactions
  4. Cryptographic signing with organizational keys
  5. Real-time transaction monitoring against mandate parameters

Payment Transaction Monitoring: Deploy comprehensive payment pattern analysis:

class AP2TransactionMonitor:
    def analyze_payment(self, mandate, transaction):
        risk_score = self.calculate_risk_score(
            user_history=self.get_user_patterns(),
            agent_behavior=self.get_agent_patterns(),
            transaction_details=transaction,
            mandate_consistency=self.validate_mandate(mandate)
        )
        if risk_score > THRESHOLD:
            return self.trigger_additional_verification()

‍

Cross-Protocol Security Integration: Deploy unified monitoring across MCP, A2A, and AP2:

class CrossProtocolSecurityOrchestrator:
    def monitor_agent_workflow(self, workflow_id):
        mcp_activity = self.monitor_mcp_calls(workflow_id)
        a2a_communications = self.monitor_agent_interactions(workflow_id)
        ap2_transactions = self.monitor_payment_activity(workflow_id)
        
        # Correlate activities across protocols
        risk_assessment = self.correlate_cross_protocol_activity(
            mcp_activity, a2a_communications, ap2_transactions
        )
        
        if risk_assessment.is_suspicious():
            self.trigger_workflow_isolation(workflow_id)

‍

The Broader IAM Implications

These protocols represent a fundamental shift in identity and access management. We're transitioning from human-centric IAM to agent-centric IAM, and our current security models are insufficient for this shift.

Derived Credentials will become essential as agents need to authenticate not just to services, but to each other. AP2's mandate system is an early attempt at this, but we need comprehensive frameworks for agent identity lifecycle management.

Contextual Authorization must replace simple role-based access control. Agents will need fine-grained permissions that adapt to context, user intent, and risk levels.

Audit Trails become exponentially more complex when multiple agents coordinate across multiple systems to complete user requests. We need new forensic capabilities for multi-agent investigations.

Bottom Line: The Infrastructure We Build Today Shapes Tomorrow's Security Landscape

After spending months analyzing these protocols and watching the industry rush toward agentic implementation, I keep coming back to a fundamental truth: we're not just deploying new technologies. We're architecting the nervous system for autonomous digital commerce and operations.

MCP, A2A, and AP2 aren't just convenient APIs or communication standards. They represent the foundational infrastructure that will determine whether the agentic economy becomes a productivity revolution or a security catastrophe. The decisions we make about implementing these protocols today will echo through decades of digital infrastructure.

The security vulnerabilities I've outlined aren't theoretical concerns, but active attack vectors being demonstrated by researchers right now. Tool poisoning attacks against MCP are working in production environments. A2A agent spoofing is trivial to execute. AP2's mandate system can be subverted through the same prompt injection techniques we've known about for years.

Here's what gives me confidence: the collaborative approach emerging around these protocols. When Google open-sources A2A with 60+ industry partners, when Docker develops security interceptors for MCP, when researchers rapidly disclose vulnerabilities and the community responds with patches. This is how robust infrastructure gets built.

‍

URL copied

TL;DR: SOC automation is designed to help organizations automate manual, repetitive tasks, but it’s not always straightforward to implement said automation. SOC automation projects can stall for reasons including teams lacking the skills or time needed to build workflows, automation tools not having the required integrations, and analysts not trusting the output they can’t inspect. Legion automates your SOC by learning your workflows, watching how your analysts actually investigate, combining those insights with logs, cases, and more, then running proven workflows with autonomous operations.

SOC automation is on every security leader’s agenda. In a recent report, 61% of CISOs said they are currently investing in automation. Our experience is that the true proportion of CISOs thinking about automation as a solution to problems like growing MTTRs or alert overwhelm right now is closer to 100%.

But deciding to invest in (and even getting a budget for) SOC automation is the easy part.

This guide covers what comes after you get the go-ahead to push for automation. It includes the automation approaches available today, which workflows are worth automating, the reasons SOC automation programs stall, and a practical sequence for implementing one. It also covers how and where Legion fits into a SOC automation project.

>> Short on time and want to see what SOC automation looks like in practice? Watch a 3-minute demo of Legion in action.

What Is SOC Automation?

Modern SOC teams look for agentic automation tools like Legion to actually learn how your team works, pull in context from outside the SOC, and recommend and perform automations that improve how SOCs function.    

Of course, automation is not new to the SOC.

At a high level, SOC automation uses technology (including, but not limited to, AI) to perform security operations work that an analyst would otherwise have to do manually. A SOC might want to automate work like gathering context on an alert, running an indicator lookup, opening a ticket, blocking a domain, isolating an endpoint, and writing up the record afterward.

And security teams have been creating their own scripts to automate routine processes and relying on deterministic SIEM automations since at least the late 1990s. Security Orchestration, Automation and Response (SOAR) tools, which automates predetermined playbooks, have been heavily leveraged in SOCs for over a decade now.

But agentic automation is the present and future of SOC automation. It's what enterprises like Virgin Money are using right now to cut alert volumes and support overwhelmed SOC teams.

Learn more about how SOC automation helped Virgin Money reduce its alert backlog by more than 60% in less than two months.

Why Automate in the SOC?

The business case for SOC automation is simple.

Analysts can’t keep up with the number of tasks they have to do on a day-to-day basis, particularly now with the Hugging Face / OpenAI incident indicating fully agentic attacks with tens of thousands of uncorrelated alerts portending that real incidents are getting missed (or spotted too slowly), and breaches happen that should have been stopped.

NIST's incident response guidance (SP 800-61 Rev. 3) notes that the volume of potentially adverse events is generally too high for analysts to review manually, while response speed has to reflect how time-critical an incident is.

Automation helps address both problems by:

  1. Reducing the amount of routine work analysts have to handle themselves. 35% of security teams say they feel overwhelmed with repetitive manual tasks.
  2. Allowing investigations and response actions to happen faster. In one study, organizations using AI and automation extensively across security operations shortened the breach lifecycle by an average of 80 days and reduced breach costs by an average of $1.9 million.  

But speed and volume are not the only reasons for SOC automation. Automation can also make SOC processes more consistent. With an automation layer in place, the same investigation steps can be followed each time an alert occurs, rather than the process varying depending on which analyst handles it.

This aligns with the broader emphasis on repeatability in NIST CSF 2.0, which describes cybersecurity risk management progressing from “irregular, case-by-case basis” at CSF Tier 1 to “Repeatable” practices at CSF Tier 3.

Does SOC automation replace people?

The short answer is no. The long answer is that SOC automation does change the day-to-day for people who work in security operations. It saves the SOC’s best people from burning out on routine tasks and lets them do the interesting investigative work that requires human insights as well as leading them to become less analyst and more orchestrator, so you can retain them for longer and reduce staff churn.

As MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center puts it: “Automation assists, but does not fully replace, the judgment of advanced human analysts.”

7 Automation Technologies SOCs Use

SOC automation ideally is a collection of technologies that, over time, automate more and more of what security analysts do.

Below are some of the most common approaches to SOC automation.

  1. Scripts and APIs. Scripting tools like Python and PowerShell can be used to automate tasks that are repetitive. This can be things like looking up an IP address, collecting information from an endpoint, updating a blocklist, or passing information between different security products. These automations can save time, but they also take time upfront because they need to be built and continuous time to be maintained.
  1. EDR automations. Endpoint detection and response (EDR) is security software that monitors devices like laptops, desktops, and servers for suspicious activity and helps security teams investigate and respond to threats, largely by pattern matching.
  1. Built-in SIEM automations. Security information and event management (SIEM) platforms collect security data from different systems, compare activity across them, and surface an alert when something matches a predefined rule. Security teams can view and analyze that data in one central place rather than having to check every system (e.g., firewalls, endpoints, servers, etc.) individually. Some modern SIEMs can also automatically take certain actions after they detect a threat.
  1. SOAR. SOAR platforms take automation even further than SIEMs. They connect different security tools and run predefined workflows (usually called playbooks).
  1. XDR. Extended Detection and Response (XDR) brings together security data from multiple areas, such as endpoints, email, networks, cloud systems, and identities, to detect and respond to threats across an organization.
  1. Security data pipelines. Security data pipelines manage security data before it reaches the SIEM. They can automatically collect, parse, normalize, enrich, filter, and route telemetry, helping teams control the volume and quality of data reaching their downstream security tools.
  1. AI and security agents (Agentic Security Operations platforms). Artificial intelligence (AI) and security agents automate more complex SOC work that previously needed a human analyst to think through and decide what to do. For example, instead of just following a fixed rule, an AI agent might investigate an alert, gather information from different security tools, work out what likely happened, suggest what to do next, and sometimes take action itself.

See how Legion makes SOC workflows repeatable and consistent.

Agentic Security Operations platforms like Legion don’t necessarily replace SIEM, SOAR, EDR, or similar tools but rather work on top of or within those tools, using their data and capabilities to automate more of the analyst’s job.

In one study, three in four analysts reported that AI tools have already made their work more satisfying by reducing alert fatigue and automating repetitive triage.

57% of organizations report success using AI for alert triage and risk scoring, and 26% report success automating incident response.

Tier 1, 2 and 3 SOC Automation Use Cases

A common way to think about automation is by SOC tier.

Tier 1 (triage)

Tier 1 SOC work is where automation pays back the fastest, because the work is repetitive and the cost of an error is relatively low. Learn more about how Legion automates tier 1 SOC tasks.

Common tier-1 and alert triage workflows include:

  • Alert enrichment.
  • Indicator and reputation lookups.
  • Phishing analysis.
  • Identity and system context gathering
  • Duplicate alert identification
  • Alert classification and prioritization.
  • Ticket creation.
  • Initial false-positive handling.

Automating this type of work also broadens the scope of what can be categorized as Tier 1, because with agents running triage and investigation, security operations centers can take on more noise, more alerts, and worry less about false-positive-burnout.

Tier 2 (investigation and response)

Tier 2 is where analysts move from routine alert handling into deeper investigation and potentially disruptive response actions, so automation needs tighter controls.

An example is rule tuning. Analysts see which detections generate repeat noise, trace it back to the benign activity behind it, and narrow the logic so the rule stops firing on it.

Tier 3 (threat hunting and advanced investigations)

Tier 3 tasks can include running threat-hunting queries, IOC sweeps, cross-environment investigations, hypothesis generation, and advanced forensic analysis.

This is particularly interesting for AI and agentic automation because these investigations do not always follow exactly the same path.

An analyst investigating suspicious authentication activity, for example, may change direction depending on what each query reveals. An agent capable of reasoning across the investigation can potentially do the same rather than relying on one fixed playbook.

But SOC Automation Use Cases Don’t Have to Be Defined By Tier

SOC tiers are a useful way to categorize SOC automation use cases, but the same types of work often appear across different tiers.

A better question is: “What makes a workflow a good fit for automation?”

In our experience, a SOC task is generally a good candidate for automation when it:

  • Repeats. Analysts keep doing essentially the same task over and over again.
  • Happens across different tools. Analysts work in SaaS consoles, EDR dashboards, legacy systems, cloud panels, and internal portals.
  • Needs security context to answer. Someone has to know what the system does, who owns it, and whether the activity is expected or unusual (i.e., judgment that is hard to script).

Why SOC Automation Projects Fail

One of the most common reasons why SOC automation projects fail to deliver value in the enterprise is a lack of skills or time to build workflows.

More than half (52.6%) of organizations cite skills gaps as a barrier to automation, 44% say automation and AI roles are difficult to hire for, and 35% report not having the internal skills needed to build or maintain workflows at all.

Another reason is integration problems. 31% point out integration gaps between tools. If an automation can't access or correctly interpret the information an analyst uses, then it can't reliably replicate the investigation.

Then there’s trust, or lack of it. 47.1% of security leaders distrust automated results. Teams need to be able to see what an automation did and why before they are comfortable with giving it more control.

How Legion Automates The SOC

Legion is the agentic security operations platform that automates enterprise SOC work.

What we’ve found is that most SOC work is repetitive but not yet standardized. Or it might be the case that playbooks exist, but they are likely to have been written by engineers who don’t run the workflow themselves, and they go out of date as soon as a tool or an interface changes.

That’s why Legion doesn’t rely on written process documentation. Instead, we work by learning from what your analysts actually do and combine that with wider context (including documented processes, logs, cases, and more).

We uses vision models to observe how and why experienced people investigate the way that they do, then turn that into a visual workflow the team can inspect and edit. This means there’s no need for you to build API integrations or set up connectors, and Legion can also work with internal tools that have no existing integration.

Every action Legion takes is recorded with the evidence behind it, including screenshots of the actual screens it reads, so you can check how it reached the conclusion instead of trusting that it is correct.

As Neil Robinson, CISO at Virgin Money, put it: "Legion has just completely transformed the way I think about automation. You take your existing operation and really just 10x it."

How to Implement SOC Automation

If we were to advise an organization on how to get automation working (and keep it working) within their SOC, we would suggest the following steps.

1. Decide who owns SOC automation

Traditionally, security engineering teams would build SOC automations for analysts.

The problem with this is that engineers don’t necessarily do those investigations themselves, which means that the automation may or may not reflect how investigations happen in real life. Plus, it leaves analysts dependent on engineering when something needs to be fixed or updated, which creates a bottleneck (this has been a longstanding issue with SOAR tools). It is further exacerbated by the fact that most automation systems require clean APIs, which, particularly for homegrown or legacy systems, simply don’t exist.

There’s also the risk of important knowledge leaving with the person who built the automation. Other people may know what the automation does, but not why it was designed the way that it was. Then, when a security process or tool changes, nobody will know how to update it, and the automation will be abandoned.

The solution is automation owned by analysts. The people who run the investigations should be able to build and update their own automations, they should incorporate ALL tools in the enterprise, and be able to document the reasoning behind each one so that knowledge stays with the organization even when people leave.

Legion is built specifically for this. Analysts create workflows by doing investigations they normally would, without writing any code or integrations, and what comes out is a visual map they can inspect and edit themselves, so updating it doesn’t mean going back to engineering.

2. Record how SOC work is done now

Before you automate your SOC tasks, you first need to understand how analysts actually perform them.

One way to do this is to ask analysts to write down each step they take. We don’t recommend it because what analysts write and what analysts do might be different:

  • Small steps can be forgotten.
  • Two analysts can describe the same workflow differently.
  • The document goes out of date as soon as a tool or interface changes.

A far better approach is to record analysts in real time. That’s what Legion does. It observes analysts while they work, capturing how they investigate alerts, which tools they use, what steps they take, and the decisions they make, then turns these into a workflow diagram that also incorporates best practices and optimal processes that the AI creates so you can reduce inefficiencies created by the ‘duct tape and thumbtack’ approach that is often the status quo.

You get two things at the end of this: a) the actual sequence of steps analysts follow, which you can then automate, and b) a view of how the team works, i.e., which tasks are most time-consuming, where investigations get stuck, and where analysts approach the same situation differently.

3. Choose the first SOC automation candidate

Once you know how your team works, you can then decide which workflow to automate first.

Choose one workflow to begin with, ideally something that analysts deal with frequently and investigate roughly the same way each time.

A good example is phishing alerts. Security teams typically receive a lot of phishing alerts, and the investigation usually follows a fairly standard process, i.e., check the email, inspect links and attachments, look at the sender, determine whether it’s malicious, and decide what to do next.

Leave the more complex cases that depend heavily on human judgment until you’ve built up confidence in your automation process.

4. Map where the context lives

Identify which systems have the information analysts need for their investigations.

For instance, an analyst investigating a suspicious activity might need to check the user’s identity and permissions, information about the affected device, previous incidents, or email records. This information could be spread across several different systems.

Then, make sure that automation can actually retrieve and use this information when it needs to. Traditional SOC automation usually connects to tools via APIs, which can exclude internal or legacy systems that don’t have them, so analysts might still have to perform missing steps manually.

On the other hand, a browser-based automation platform like Legion can access the exact same information that analysts can.

5. Baseline the workflow before you automate it

Measuring how much time a workflow takes before you automate it allows you to later prove that the automation actually saved time.

The calculation is simple:

Time spent = alert volume x handling time per alert.

For example, if your team gets 100 phishing alerts a week and each alert takes 10 minutes to investigate on average, that’s about 1,000 minutes of analyst work. After automation, you can measure that exact same workflow again and compare the number.

6. Whitebox auditability is key

Legion is fully white box, so you can deploy it right away. There’s no supervised on-ramp required, because you can see exactly how it thinks from the start. Every action, every piece of context, and every conclusion is fully visible and editable, never a black box you're asked to trust blindly. That's what makes it predictable immediately: you know why it reached a verdict, you can correct it on the spot, and it'll apply that correction consistently from then on.

7. Expand to other SOC workflows

Once you get one workflow running successfully, start automating another one by taking it through the same process - observing how analysts do it, building the automation, supervising it, and only then considering making it autonomous.

Automate Your SOC with Legion

Ready to automate your SOC? Get a demo of Legion today.

SOC
What SOC Automation Actually Means Today, Plus How to Do It In Your Organization
September 11, 2026
min read

A practical guide to SOC automation — what it means today, why it often fails, and how Legion helps teams automate without integrations.

Legion Team

Security investigations rarely start with all the context needed to reach the right decision, and we see plenty of examples of this in real environments. Let’s look at an anonymized but recent example to show why AI knowledge management matters in security investigations.

Every quarter, a publicly traded enterprise’s finance team uploads the company's still-unreleased earnings package which consists of revenue, forecasts, and results that won't go public until earnings day to a restricted SharePoint site for executive review. The package contains sensitive financial information so the upload triggers a DLP alert for review. Pretty standard stuff.

That alert triggered an analyst investigation where the incident response team confirmed the uploader was indeed a part of the reporting team, the destination was the approved site, and access was limited to only the small group of executives who were supposed to see it. Nothing dangerous, so it was safely closed as benign. This single investigation established the conditions that made the activity safe: who was expected to upload the file, where it was supposed to go, and who was supposed to have access.

But the lingering question is… what should be carried forward and/or codified from that investigation? This question is one that we’re obsessed with answering and helping our customers address.

With Legion, instead of carrying forward a single verdict from a single investigation, enterprises can uniquely capture the conditions that each investigation establishes together with the underlying and complementing evidence behind them. On a continuous basis. This holistic view matters, particularly in today’s world, because the same activity type doesn't always mean the same thing, and this is a constantly moving target as environments change. Using our ‘finance team uploading earnings files into SharePoint’ example, one of the conditions that was met, who had access to the folder, can change very quickly. So perhaps the next time, the package is the same, the site is the same, the timing is the same, but the folder may have been shared with an external account or a new unverified user.

The challenge isn't collecting more data. Most enterprises already have plenty of it, scattered across identity providers, endpoints, SaaS apps, and past investigations. The challenge is turning that raw data into knowledge that's reliable enough, and accessible enough, for agents to actually reason over: preserving what made something true, connecting it to the organizational context around it, and continuously testing whether it still holds as the organization changes.

Knowledge (including AI knowledge) needs conditions, not conclusions

That's why Legion represents organizational knowledge and context as a continuously evolving model that connects identities, teams, systems, data, access, behaviors, and the evidence establishing how they all relate to one another.

Legion’s knowledge isn't built from investigations alone. Legion brings information from across the environment, including identities, access, systems, infrastructure, and the relationships between them, into the same layer. Past investigations add another important source, giving Legion an accumulated history from day one: what analysts already checked, what they found, and the evidence that supported those decisions.

Raw data on its own doesn't tell an agent much. An identity, a login, a file upload, a network connection, in isolation, are just data points. What makes this usable is the relationship it has to everything around it. That's what turns data into knowledge an agent can actually act on: not just what happened, but who was involved, what it touched, what normally follows it, and what it means if it doesn't.

‍

‍

That gap between "looks the same" and "is the same" is hard to manage at enterprise scale, and Legion Knowledge is designed to connect the data flowing in and out of thousands of employees, dozens of teams, hundreds of new and existing tools changing in real time, and access to relationships that change over time. This empowers security teams, and their agents, to stay on top of every legitimate exception, relationship, and operating pattern at agentic scale.

We see all the time that not everything security tools observe should become codified as organizational best practices. Before new information can influence future investigations, there needs to be enough evidence to support it. Otherwise, an observation can become an assumption that extends beyond what the evidence actually established, and an assumption an agent can't verify is a liability, not an insight.

Research on memory management in LLM agents shows why this matters. Researchers at Harvard, Michigan State, and other institutions found that agents exhibit what they call "experience-following": the more similar a new task is to an experience retrieved from memory, the more likely the agent is to follow that past execution. That's useful when the retrieved experience applies. When it doesn't, the agent can carry an assumption from one task into the next that the new evidence doesn't support. Reliable knowledge is what keeps that experience-following useful instead of risky.

Useful organizational knowledge is more than a collection of isolated facts. The relationships and intricacies between those facts provide the context needed to interpret them: not just what is known about an identity, system, or activity, but how each relates to the organization around it. Preserving those relationships is also what surfaces the insights security teams actually need: correlation across seemingly unrelated events, the blast radius of a compromised identity or system, and where the real detection opportunities sit. None of that comes from more data. It comes from data that's been made reliable enough to connect.

Strong evidence can still become outdated without AI knowledge management

Preserving the right conditions solves one problem, but it creates another: conditions change.

In our finance example, previous investigations may provide strong evidence that only a specific group of executives had access to the folder. That evidence doesn't become wrong when someone new is granted access; they could be, simply, a new member of the exec team.

That's why Legion separates confidence from freshness: confidence reflects how strongly the evidence supports what is known, while freshness reflects how recently those conditions have been verified.

That distinction matters when existing knowledge is used in a new investigation, or acted on by an agent. Something can remain strongly supported by evidence while becoming too stale to rely on without verifying that the same conditions still hold. An agent that can't tell the difference between confident-and-fresh and confident-and-stale is an agent that will eventually act on the wrong assumption.

New evidence has to reconcile with existing knowledge

Every new investigation produces information that could become organizational knowledge. But observing something doesn't automatically make it a best practice. Before new evidence changes the output, Legion evaluates it against what the organization already knows. It may reinforce something already established, add something new, or contradict it.

New evidence doesn't necessarily make the old evidence wrong. Both may be valid: one describes what was true when it was established, while the other shows that something has since changed. Preserving the evidence and timing behind both lets security teams understand that change rather than simply replacing one version with another.

This makes evaluation part of the learning process, not just a gate at the moment knowledge is created. An investigation produces new evidence, that evidence is evaluated against existing knowledge, and only then can it change what Legion, and the agents built on top of it, carry into future investigations.

Learning is automatic. Authority isn't.

Automatic learning shouldn't make organizational knowledge opaque to the humans who rely on it. If that knowledge is going to shape future investigations, and the agents acting on them, the people who know the organization should be able to see what was learned and contribute to its quality.

Human feedback adds another signal to that process. A validation can strengthen what Legion has learned, while a correction or rejection can challenge it. And for people to make those judgments, the knowledge has to remain traceable: where it came from, the evidence behind it, and how it has changed over time.

AI knowledge has to remain trustworthy

Organizational knowledge is useful only as long as there is a reason to keep trusting it. Something can be well supported and still become outdated. New evidence can strengthen what is already known or show that the environment has changed. And a conclusion that was right six months ago shouldn't become an assumption simply because nothing has challenged it yet.

That's the distinction we built Legion around. The goal isn't simply to collect more data about an organization. It's to make that data reliable and accessible enough, for analysts and agents alike, to know what still deserves to be trusted.

Cybersecurity
How AI Knowledge Management Makes Security Investigations More Reliable
September 9, 2026
min read

How Legion turns security data into reliable, AI agent-ready knowledge to preserve evidence, track freshness, and surface what still deserves trust.

Gili Diamant

➤ Problem: A backlog of tens of thousands of security alerts and overwhelmed analysts who could not keep up.

➤ Solution: Legion's agentic SOC automation, which learns existing SOC workflows and takes over routine investigations transparently.

➤ Outcome: Legion's agentic SOC automation processed 30,000 backlogged alerts for Virgin Money in under two months, leading to a 60% reduction in their alert backlog.

Neil Robinson, CISO at Virgin Money (a major UK financial services brand and retail bank), was facing a familiar SOC problem: a massive volume of alerts overwhelming their security operations team.

Protecting a large, high-profile attack surface meant that Virgin Money had to deal with a backlog of around 50,000 security alerts. This placed immense pressure on their ~200-person security team.

Within two months of deploying Legion’s Agentic Security Operations Platform to automate repetitive SOC workflows, Virgin Money had reduced its alert backlog by more than 60%.

Alert reduction was the SOC automation benefit Robinson wanted. Legion's other core advantage was that it let his team automate existing security workflows without forcing his SOC to redesign its operations.

“Legion has just completely transformed the way I think about automation. You take your existing operation and really just 10x it.” - Neil Robinson, CISO at Virgin Money

A 200-person SOC with a 50,000 alert backlog

Virgin Money relies on a security organization of around 200 people to protect their bank and its more than 6 million customers from cybersecurity threats.

Like many modern financial institutions, Virgin Money offers a huge range of digital banking services from current accounts to mortgages. They also provide customers with in-person services through branches and hubs.

The digital infrastructure required to support this broad business creates a large attack surface and a huge volume of security alerts.

Many of these alerts are low-value or false positives. Yet they still drain analyst attention that could be better spent on higher-value security investigations. The result was the alert fatigue that security teams know all too well. Too many alerts, too little time.  

To solve alert fatigue, Virgin Money wanted to reduce the time analysts spent on low-value alerts. But they needed automation their analysts could inspect and trust.

Transparent SOC automation

Robinson estimates that Virgin Money reviews around 100 new security solutions each year, many of them focused on automation. And for each, integrity and security are top concerns.

More specifically, Robinson wanted whatever solution Virgin Money chose to guarantee that:

  • Automation inside a security operation behaves predictably.
  • Analysts can see what the automation is doing and why it reached a given decision.
  • The system can be trusted with sensitive security workflows.

Robinson was immediately impressed that Legion uses vision models to watch how experienced analysts work on screen, so Virgin Money did not have to define every workflow by hand.

Legion can be deployed on an engineer's desktop to observe the sequence of actions in an investigation and turn that activity into a visual workflow.

“It feels a little bit like magic when you first turn it on, but then it gives you this really nice workflow diagram where you can see exactly what it's doing.” - Neil Robinson, CISO at Virgin Money

Legion did not require Virgin Money to replace its existing SOC processes. Instead, the platform learned how analysts already handled alerts and turned those operating patterns into repeatable automated workflows.

Using vision models combined with other methods to observe how analysts investigate alerts, Legion helps enterprises like Virgin Money either codify SOC processes or optimize them into visual agentic workflows that the team can inspect.

In Virgin Money’s SOC, Legion was able to rapidly capture their operating rhythm rather than forcing the team into a predefined process. Critically for Robinson, the way Legion understood Virgin Money’s SOC (and automated tasks) was fully transparent and traceable.

“Legion gives you this really nice workflow diagram so you can see exactly what it's doing.” - Neil Robinson, CISO at Virgin Money

For Virgin Money, that visibility made automation easier to trust.

Agentic SOC automation cuts alert backlog by 60%

Security teams often accumulate years of operational knowledge inside analyst behavior. This institutional and practitioner knowledge can include which systems to check, what evidence matters, what conditions trigger escalation, and how investigations move between tools.

Much of this knowledge is only partially written down. Understanding it requires observing people at work and then translating those observations into automated workflows that use the same tools in the same or improved ways.

This is agentic SOC automation, where the system can carry out parts of investigations using the same workflows already developed by experienced security staff.

For Virgin Money, deploying Legion’s agentic automation solution cut the alert backlog by 60% in under two months, from approximately 50,000 alerts to 20,000. Automating repeatable investigative work freed analysts to spend more time on security tasks requiring judgment and deeper analysis.

It also changed how the security team viewed automation.

Initial concerns that automation could replace analysts shifted toward seeing Legion as a tool that expands what the existing team can accomplish.

“They now see it as an augmentation. They see it as something that means that they can do a better job for security.” - Neil Robinson, CISO at Virgin Money

Robinson does not expect agentic automation to remove the need for his security team.

“I don’t see it as something that’s going to replace any of my team. I see it as something that’s going to help us defend the increasing speed of the attack.” - Neil Robinson, CISO at Virgin Money

From SOC alert fatigue to responding at the speed of attacks

Agentic SOC automation can capture how experienced analysts already investigate alerts, reproduce those workflows at scale, and leave human analysts focused on the cases where their judgment matters most.

For Virgin Money, that approach helped cut a 50,000-alert backlog to 20,000 in less than two months.

The larger change was that automation stopped being something layered on top of the SOC and became a way of scaling the workflows the security team already trusted. Ultimately, this has created a new approach to scaling security operations for Virgin Money, one built on a partnership with Legion’s team.

“I think what you've really got to understand if you're working with Legion is that they really are a special company. Any good partnership is about the people as much as it is about the technology” - Neil Robinson, CISO at Virgin Money

Hear Virgin Media's CISO describe what working with Legion was like

Hear directly from Neil Robinson, CISO at Virgin Money, on how Legion’s agentic security operations platform learned his team’s existing investigation workflows and scaled them without forcing new tools or processes onto analysts. Neil shares how Legion delivered faster, more repeatable, and more secure investigations, aligned to how his team already operates, rather than a generic playbook applied from outside.

0:00 / 0:00
Cybersecurity
Legion Customer SOC Automation Case Study - How Virgin Money Reduced SOC Alert Fatigue with Legion
August 2, 2026
min read

Legion SOC automation case study

Legion Team