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.

Ryan Rowcliffe
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). 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

Demand for agentic security that actually works in complex enterprise environments has never been higher, and today we're excited to take a meaningful step forward in meeting it

We're excited to announce that Legion Security has partnered with Optiv to become an Authorized Partner to help enterprises stop talking about the same-old-problem, and start putting AI to work. Security teams are under pressure that doesn't need a lot of explaining. Analysts, engineers, and practitioners are being asked to do more with less; more alerts, more tools, more threat surface, and fewer people to manage it all. AI was supposed to be the great equalizer, and the promise of the AI SOC was compelling: automate the noise, free up your people, let machines handle the volume.

The reality has been… more complicated.

Most AI security tools were built generically for a generic security team in a generic enterprise. One problem with this is… what is an average security team? Every large organization has processes that are entirely their own: workflows built around a specific stack, custom tools that were built and tuned over long stretches, tribal knowledge accumulated over years, investigation procedures tuned to their environment, their risk tolerance, their regulators, their customers.

Heavy API integrations try to stitch it together but end up slow, brittle, and context-poor (at best). And agents that operate inside a black box create exactly the kind of trust deficit that makes security leaders hesitate to hand anything off at all.

This is the gap Legion was built to close.

A Different Approach to Agentic Security in the Enterprise

The premise of Legion is straightforward: nobody knows your security operations like you do. Our platform doesn't arrive with assumptions about how your team should work. Instead, it observes and learns from how your team actually works; across your tools, your workflows, your most repetitive processes and your most bespoke ones, and then uses that knowledge to build optimized AI agents that operate within the context of your organization.

We don’t require integrations for full contextual awareness. We’re an open book (no black box) that leans on our browser-based approach to see what your analysts see and do, learns what they know, and earns YOUR trust before taking action.

The result is agentic security that can actually scale in the enterprise — not by replacing how teams work, but by amplifying it.

The Imperative for Partnering with Optiv

Becoming an Optiv Authorized Partner matters because of what Optiv represents to the enterprise security buyer. Optiv works with organizations that have mature, complex security programs; exactly the kind of environment where Legion's approach of learning from bespoke processes is most valuable.

Enterprise security leaders look to trusted advisors to help them evaluate fit, plan implementation, and optimize outcomes over time. Optiv's position in the market as an integrator with deep relationships and deep domain expertise makes them uniquely positioned to bring best-in-breed solutions to the organizations that need it most and to help them get maximum value from it.

This partnership reflects something we're hearing consistently in the market: enterprises want agentic security, but they want it on their terms. They want AI that understands their environment before it acts in it. They want partners who can help them think through where automation should start, how to build confidence in the system over time, and how to expand from their first use cases into a broader program.

That's exactly what this partnership is designed to deliver.

What It Signals More Broadly

The Optiv partnership is a data point in a larger trend. Channel partners; the integrators, MSSPs, and advisors who sit closest to enterprise security buyers, are increasingly being asked about agentic security. Their clients want to know what's real, what's ready, and what actually works in complex environments.

For Legion, this is an important milestone in building the ecosystem that enterprise agentic security requires. We're grateful to the Optiv team for their partnership and excited about what we'll build together. And for enterprise security leaders who have been watching the agentic security space and wondering what a path to trusted AI adoption actually looks like, we'd love to show you.

Interested in learning how Legion Security and Optiv can help your organization automate, scale, and elevate your security posture? Get in touch.

AI
Legion and Optiv Partner to Deliver Agentic Security That Understands How Enterprises Work
June 29, 2026
5
min read

Legion Security is now an Optiv Authorized Partner. Enterprise security teams can now deploy agentic AI for security operations that understands and optimizes agentic workflows without integrations, black boxes, or needing to ask teams to change how they work.

Marcia Dempster

I was there, I sat in every SOC seat out there…

A SOC analyst grinding through alert queues at 2am. Part of an Incident Response team leading running war rooms. A SOC manager in Monday morning stand-ups asking what we learned this week while staring at blank faces.

Every single role. Every single day. And the one thing that never changed across any of them?

The insights, recommendations, self improvement, the de-facto SOC continuous improvement action items were disappearing. Seating documented in a case log for no one to action upon, trapped inside closed tickets that live in a backlog nobody rarely reopens.

I know the why and I feel the overwhelming operations, which is  why I’m offering a practical solution for how to continuously improve your SOC with the valuable insights coming out of your investigations.

The Hidden Goldmine You're Sitting On

Every ticket your team closes tells a story. It's not just that an alert fired, then an analyst investigated and eventually closed. There are powerful signals buried in those notes, whether it's a tool with overly noisy alerts, a gap in your email gateway rules, or the same user clicking a phishing link for the third month in a row.

Your tier 1 all the way to your tier 5 analysts and IR responders are generating intelligence every single shift and with every single incident. They know things and they're writing them down. It's useful information but these notes get buried and never read again.

It's a sad truth... I know because I've been in those weekly SOC meetings, I was running them.

It's not a people problem, rather, it's a system problem.

The Weekly Report Trap

The thing people look to as the standard fix is the weekly report. In theory it's elegant: senior analysts summarize the week, extract the learnings, feed them back into tier 1 runbooks and detection improvements. On paper, it's a proper feedback loop.

In practice, it becomes the task that either gets rushed on Friday afternoon or simply doesn't happen. It's for good reason too! Your senior analysts are already stretched because on top of everything they need to do for their jobs, they're also being asked to synthesize everything in themes. You either get a half-hearted copy-paste of ticket titles, or, more likely, you get nothing.

Teams try rotation where everyone takes a turn on the ferris wheel. But in doing so, you face losing important insights and information, not to mention a lack of consistency.

Now add a follow-the-sun operation to this. APAC closes tickets while EMEA is asleep. EMEA handles incidents while Americas is offline. By the time anyone tries to compile a summary, they're working with fragments. Nobody has the full picture. The patterns that only emerge when you look across all shifts stay invisible.

Wait, Can't AI Can Solve This Pretty Easily? 

When capable LLMs became available, I thought this was finally solved. Just feed all the investigation summaries in, ask for a weekly report. Done? Not so fast... here's what actually happened.

First attempt: I gave the best LLM models that money can buy more than 250 investigation summaries and asked for a consolidated report. But what I got back was a mess.

What I saw were recommendations repeated five times just with slightly different wording. Severity assessments that made no sense and my “favorite” recommendations that are not feasible, for example “Tune your EDR machine learning to reduce false positives of macro xlsx files”.

No traceability whatsoever, no way to tie anything back to the original investigation and forget about cross referencing with similar recommendations.

Second attempt: I went deep on prompt engineering. Longer prompts. More detailed. With examples. The results improved marginally, but the ceiling was surprisingly low.

The fundamental issue is that when you dump a large context with complex requirements into a single LLM call, it can't hold everything in working memory. It forgets constraints from earlier in the prompt. It hallucinates connections between unrelated incidents. Severity levels come out inconsistent.

One-shot approaches get you mediocre fast. They don't get you useful.

The Breakthrough: Think Multi-Step, Not Prompt

The shift that changed everything was stopping thinking about this as one task and starting to think about it as a multi-step pipeline.

When an experienced analyst writes a weekly report, they don't try to do it all at once. They read, they group, they prioritize, they write. Multiple steps. Each one is different.

So I built it that way.

The 6-step pipeline

Step 1: Classification

The first step does one thing and one thing only. It extracts and categorizes recommendations from raw investigation summaries. It looks for whatever your analysts call them: Recommendations, Do Better, Action Items, Next Steps. It pulls each one out and assigns it to a category: detection, prevention and process improvements.

No dedupe. No severity. Just extraction, done well.

Step 2: Feasibility Assessment

Now we evaluate each recommendation against practical reality. Can this actually be implemented? Is it a quick win or a multi-quarter project? Does it require resources you don't have?

This is also where web search earns its keep. When a recommendation references a specific product or vendor, the model can look up current best practices, product documentations, tech community discussions and verify the suggested configuration actually exists and is supported. Without this, you get generic, often infeasible advice. With it, you get grounded recommendations.
Make sure to use an LLM model that has web search capability via API calls.

Step 3: Citation Attachment

Before touching deduplication, every recommendation gets linked back to its source investigation. This is non-negotiable for a report anyone will actually act on. When a SOC manager reads and SOC teams attempt recommendation implementation, they need to know which investigations triggered that and value with volume justification to it. Otherwise it's just noise or worse, it might break business operations.

Step 4: Deduplication

Three analysts working three separate investigations but same use case, all recommend the same prevention improvement. Without deduplication, you get three entries saying the same thing with slightly different wording. With it, you get one consolidated recommendation that shows it came from three independent investigations, which is actually a stronger signal.

Citations from all source recommendations get merged. Nothing is lost.

Step 5: Severity Classification

Now, with duplicates consolidated, we can assign severity levels that actually mean something. The model evaluates security impact per your instructions, weights and SOC defined severities for each use case. Not how urgent did the analyst feel when writing this, but what is the actual risk if this doesn't get addressed built on your SOC knowledge base.

Separating this from extraction forces objectivity. If you try to assign severity while also pulling recommendations from raw notes, the analyst's tone bleeds in and skews the assessment.

Step 6: Report Generation

Everything feeds into the final structure. The model has category breakdown, feasibility assessments, severity levels, citation references. It produces a coherent report with an executive summary and recommendations sorted by severity, with enough context to actually act on. Also comparing recommendations week on week to get remediation/implementation progress for repeated action items.

Add another layer of disregard recommendations and you have a magnificent mechanism.

No LLM at this stage, actually. It's programmatic and deterministic. It assigns citation letters for easy grounding and reference of recommendation with feasibility (A, B, C...), builds the reasoning section for each recommendation, and outputs clean JSON ready for whatever you want to do with it.

Why This Architecture Actually Works

The goal is to achieve focused context at each step. Instead of one massive prompt juggling ten objectives, each step gets only what it needs. Fewer constraints to forget.

Modular iteration is the name of the game here. When severity ratings were inconsistent, I refined only the severity prompt. When analysts switched from Recommendations to Do Better as their section header, I updated only the classification step and nothing else broke.

Inspectable intermediate outputs. Between every step, results are saved. If something looks wrong in the final report, you can trace back through the pipeline and find exactly where it broke. Debugging is possible, which is not nothing.

Web search in the right place. Not as a general capability, but specifically in the feasibility step where it does the most work. Validating that a recommended configuration actually exists changes the quality of the output completely.

The Payoff

Your analysts don't change anything, they can run the same investigations, keep the same ticket notes they're already writing. The pipeline simply runs against their existing documentation.

The output is consistent. Same structure, same categories, same severity criteria, every week. You can compare week over week and actually spot trends. You can see if the same recommendations keep surfacing, which means they're not getting actioned, which is itself a signal.

The feedback loop that should have existed closes automatically. Tier 2 findings reach tier 1. Detection gaps surface. The Monday morning question about what we learned has an answer.

Build it or use it

Building this right takes time. Getting prompts tuned for the variety in how analysts write, handling edge cases, making it robust across different ticketing systems. It's not weekend work.

If you want to build it yourself: start with extraction only. Get that reliable first. Then add deduplication. Then severity. Don't try to build the whole thing at once.

If you'd rather not build tooling while also running a SOC, this is exactly what we built at Legion Security. Already tuned across real SOC environments, connected to your existing ticketing system, your analysts change nothing.

Either way: stop burying the intelligence your team generates every day.

Your team is learning constantly. Those lessons deserve to surface.

Written by someone who's been the analyst, the IR lead, and the manager staring at the empty Monday morning whiteboard.

SOC
How to Keep Up With Never-Ending SOC Continuous Improvement
June 22, 2026
6
min read

SOC continuous improvement fails when insights get buried in closed tickets. Learn a 6-step LLM pipeline that turns investigation notes into action.

Yaniv Menasherov

Legion Security is Now Available on Google Cloud Marketplace

Security operations were built around human investigators. Skilled analysts, working manually across dozens of tools, piecing together evidence, making judgment calls, closing cases. But as alert volumes outpaced human capacity, institutional knowledge became a bottleneck, and the complexity of the modern enterprise made scaling impossible. The industry responded with more headcount, more tools, more automation. None of it solved the fundamental problem.

Legion introduces a different operating model entirely. 

What Legion Does

Legion observes how your analysts operate when running real investigations, learning your organizational context, tools, past cases, playbooks, runbooks and all other tribal knowledge in order to understand what an optimal investigation looks like for your environment. This is then turned into an easily editable and audible workflow which can be automated when you’re ready. Powered by Google Cloud's Gemini models, each workflow is executed by AI agents that reason through the evidence and provide a verdict and even remediate. This is all accomplished with no manual playbook writing or need to document predefined rules.

But legion goes well beyond workflow creation. As Legion builds trust in its performance, teams can choose to keep a human in the loop to approve every decision or have Legion operate fully autonomously reducing MTTR eliminating MTTA, allowing analysts to focus on more novel investigations that are becoming more and more common in the world of AI. 

Memory: The Compounding Advantage

Every investigation Legion conducts makes it smarter. A persistent memory layer continuously captures context from previous cases, your SOC knowledge base, and direct analyst feedback, feeding all of it back into future investigations and decisions. Institutional knowledge that once lived in the heads of your most experienced analysts becomes a permanent, improving organizational asset. The more Legion works, the better it gets. That's not a feature. That's a compounding strategic advantage.

Zero Integrations. Immediate Value.

Most security automation platforms fail at the same hurdle: integrations. Enterprises face months of API work, custom connectors, and professional services before anything runs in production, or are forced to adopt entirely new tools and processes, something most complex enterprises simply can't do.

Legion operates natively in the browser, which means it works across your entire security stack, from threat intel platforms to legacy internal tools, without any API configuration. If your analysts can open it in a browser, Legion can learn from it, generate workflows from it, and execute investigations through it.

Proven Results at Scale

The impact Legion delivers isn't theoretical:

As the head of Security at Virgin Money put it, Legion is “like evolving from handcrafted systems to precision manufacturing aligned to our flow (except) faster, repeatable and secure”.

Legion works with the worlds largest enterprises and delivers strong results: 

  • A large insurance organization automated 24,000 investigations and cut mean time to respond from 20 minutes to 2 minutes.
  • WELL Health Technologies reduced investigation times by 81%, allowing existing analysts to handle significantly higher alert volumes without additional headcount.
  • The University of Tulsa cut investigation times in half, enabling their team to overcome capacity limits with the staff they already had.

Across deployments, Legion reduces mean time to investigate by up to 85% and response times by up to 90%.

Built on Google Cloud

Legion's integration with Google Cloud goes deeper than the Marketplace listing. The platform runs on Google Cloud infrastructure and leverages Gemini models to power its AI reasoning, combining Legion's browser-native architecture with Google Cloud's security, scale, and model quality.

For organizations already invested in Google Cloud and Google SecOps, Legion extends that ecosystem directly into the analyst workflow.

Who It's For

Legion is purpose-built for enterprise security operations teams, CISOs, VPs of Information Security, SOC Directors, and Security Operations Managers at organizations running in-house SOCs. If your team is dealing with any of the following, Legion was built for you:

  • Alert volumes that have outpaced your team's capacity
  • Analyst burnout from manual, repetitive investigation work
  • Institutional knowledge that walks out the door when senior analysts do
  • Automation gaps caused by complex integration requirements

Available Now on Google Cloud Marketplace

Legion Security is available today on Google Cloud Marketplace, allowing customers to apply their spend toward their annual Google contract and simplify procurement. For security teams ready to move beyond the limits of traditional operations, this is where that transformation begins.

Engineering
Legion Security Is Now Available on Google Cloud Marketplace
May 31, 2026
12
min read

Legion is officially on the Google Cloud Marketplace.

Gili Diamant