Grounding the SOC Agent: Bridging Cisco XDR Telemetry to LLMs via Model Context Protocol

When security operations centers (SOCs) experiment with AI agents, the initial pilot almost always follows a predictable pattern: an analyst copies an alert summary from a dashboard, pastes it into a chat window, and asks the model: "What should I do with this alert?"

The model replies with a plausible-sounding, six-paragraph playbook: check the IP reputation on VirusTotal, search the endpoint in EDR, verify authentication logs, and isolate the host if malicious.

It sounds impressive until you look at the operational reality: the model is completely ungrounded.

The model has no access to the live incident graph. It does not know if the flagged IP address is an external command-and-control (C2) server or an internal proxy VIP. It cannot see whether Cisco Secure Endpoint already quarantined the parent process, whether Meraki logged outbound traffic, or whether a ServiceNow incident is already assigned to a tier-2 analyst. The human is forced to act as an API middleware layer—manually copying hashes, querying portals, pasting results back into the prompt, and hoping the model does not hallucinate the next step.

To turn AI from a passive chatbot into an active investigation teammate, we rebuilt the community Model Context Protocol server for Cisco XDR: technoxi/xdr-mcp-community.

By providing AI agents with 27 strongly typed tools across Cisco XDR's incident, observable, threat intelligence, and automation engines, agents can autonomously traverse complex detection graphs, enrich indicators of compromise (IOCs), and stage audited containment actions—without bypassing production safety controls.

Why the Upstream Integration Broke

Anthropic's Model Context Protocol (MCP) has rapidly become the standard interface for connecting LLMs to external systems. When Cisco DevNet released an initial community MCP prototype (CiscoDevNet/xdr-mcp-community), it proved the concept, but practitioners attempting to deploy it in production quickly ran into walls.

Over the past two years, Cisco XDR has evolved its backend architecture, migrating legacy threat intelligence services to modernized Conure v2, Private Intel, and Unified Platform APIs. The original community codebase suffered from critical regressions:

1. Broken Endpoint Mappings (404s): Older routes such as iroh-incident, iroh-profile/profile, iroh-int/integrations, and legacy casebook URLs were completely decommissioned, causing tool calls to fail silently with HTTP 404 errors.
2. Obsolete Workflow Execution Paths: Automated response actions called stale per-workflow execution endpoints rather than Cisco XDR's modern Automation Start API.
3. Stdio-Only Transport Coupling: The server was hardcoded for local standard input/output (stdio) process spawning, making it difficult to deploy as a shared microservice for multi-agent orchestration platforms or remote cloud runners.

We forked the project at technoxi/xdr-mcp-community to fix the underlying API contracts, implement Streamable HTTP transport, and make the toolset dependable for production SOC workflows.

Architecture of the Modernized XDR MCP Server

The server acts as a secure, schema-enforced gateway between AI agents (running in Claude Desktop, Cursor, Antigravity, or headless agent frameworks) and the Cisco XDR cloud platform:

[AI Assistant / SOC Agent]
         │
         ▼ (JSON-RPC 2.0 over Streamable HTTP at /mcp or stdio)
┌────────────────────────────────────────────────────────┐
│               technoxi/xdr-mcp-community               │
├────────────────────────────────────────────────────────┤
│  • Token Management (Client ID + Client Password OAuth) │
│  • JSON Schema Validation per Tool Call               │
│  • Rate Limiting & Regional Routing (US, EU, APJC)     │
└────────────────────────────────────────────────────────┘
         │
         ├─► Incidents API (Summary, Observables, Events)
         ├─► Threat Intel & Sightings (Private Intel / Conure)
         ├─► Casebooks Engine (Investigation Dossiers)
         └─► Automation Engine (Workflows & Staged Responses)

The server exposes 27 tools organized into four operational categories:

• Incident Triage: incident_summary, incident_observables, incident_events, incident_update, incident_add_note.
• Investigation & Threat Intel: investigate_observables, intel_sightings, intel_judgments, intel_indicators.
• Casebook Dossiers: casebook_list, casebook_get, casebook_create, casebook_add_observables.
• Response & Workflows: action_list, action_trigger, workflow_start.

The Investigation Workflow: Tracing the Entity Graph

To see how an AI agent uses these tools during an incident, consider a real detection scenario: Cisco XDR raises a high-severity incident (INC-94182) titled "Suspicious PowerShell Execution with Outbound Beaconing".

Instead of asking a human to copy and paste data, the agent executes a structured investigation loop.

Step 1: Ingesting the Incident Graph

The agent begins by calling incident_summary and incident_observables:

// Agent Tool Call: incident_observables
{
  "incident_id": "INC-94182"
}

The MCP server queries the live XDR incident API and returns the structured entity collection:

{
  "incident_id": "INC-94182",
  "title": "Suspicious PowerShell Execution with Outbound Beaconing",
  "severity": "HIGH",
  "observables": [
    {
      "type": "ip",
      "value": "198.51.100.23",
      "disposition": "Suspicious"
    },
    {
      "type": "sha256",
      "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "disposition": "Malicious"
    },
    {
      "type": "endpoint",
      "value": "001a4a16-89b2-4d2c-9a4f-712891bb2201",
      "hostname": "finance-ws-04"
    }
  ]
}

Step 2: Correlating Observables Across Telemetry Engines

With the raw observables in hand, the agent does not guess their relevance. It calls investigate_observables to pull judgments and sightings from all connected telemetry sources (Cisco Secure Endpoint, Umbrella DNS, Meraki, and Secure Email):

// Agent Tool Call: investigate_observables
{
  "observables": [
    { "type": "ip", "value": "198.51.100.23" },
    { "type": "sha256", "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }
  ]
}

The response contains concrete sightings:

• The SHA-256 hash was first seen on finance-ws-04 at 08:42:10 UTC by Cisco Secure Endpoint.
• The destination IP (198.51.100.23) was queried via DNS and allowed by Cisco Umbrella at 08:42:15 UTC.
• Meraki MX recorded 45 outbound TCP connections over port 443 within a ten-minute window.

Step 3: Compiling the Casebook Dossier

As the agent uncovers evidence, it records its findings directly in Cisco XDR by calling casebook_add_observables and incident_add_note. This ensures that human analysts looking at the incident in the web console see the agent's work in real time, formatted cleanly with evidence timestamps and MITRE ATT&CK technique IDs (e.g., T1059.001 - Command and Scripting Interpreter: PowerShell).

Guarded Containment: Staging Without Uncontrolled Action

The most critical design consideration when connecting AI agents to security tools is containment safety.

An AI agent should never be granted unconstrained API permissions to immediately isolate an endpoint or push a blanket firewall rule without human authorization. An uncontrolled model can easily isolate a critical domain controller or block an entire corporate subnet due to a misunderstood entity relationship.

We addressed this by establishing a clear separation between investigation tools and containment workflows.

Instead of executing raw endpoint isolation or firewall mutations directly, the agent leverages Technoxi's proven engineering patterns:

[AI Security Agent]
       │
       ├─► 1. Enriches Incident & Identifies Malicious Assets
       ├─► 2. Evaluates Host Context (Server vs Workstation)
       ├─► 3. Calls: workflow_start ("Staged Containment Approval")
       │
       ▼
[Cisco XDR Automation Engine]
       │
       ├─► Creates ServiceNow Incident with Evidence Contract
       ├─► Pauses Execution on XDR "Request Approval" Block
       │
       ▼
[Human SOC Lead / CAB Approver]
       │ (Clicks "Approve" in ServiceNow Ticket)
       ▼
[Webhook Callback] ──► XDR Resumes ──► Executes Isolated Action

This connects directly to the architectural principles we established across our security engineering suite:

1. The Evidence Contract: When the agent prepares a ticket, it adheres to our ServiceNow ticket evidence contract, ensuring detection payloads, process trees, and observables are structured before an analyst reviews the approval request.
2. Safe Endpoint Qualification: Before proposing isolation for finance-ws-04, the workflow verifies the device GUID, confirms it is not a shared cluster host or critical server, and validates identity eligibility—following our safe endpoint isolation principles.
3. Read-Merge-Write Firewall Updates: When blocking the external C2 IP (198.51.100.23) on Meraki, the automation executes an atomic read-merge-write update rather than overwriting existing rules.
4. Resuming via Secure Webhooks: The workflow pauses in Cisco XDR and awaits human sign-off via our ServiceNow approval loop pattern.

The agent acts as the tireless investigator that gathers evidence, correlates telemetry, and prepares the exact change request. The human remains the deliberate decision-maker who authorizes execution.

Deployment: Running xdr-mcp-community

The server runs on Node.js (v18+) and connects to Cisco XDR using OAuth2 client credentials.

1. Generating API Credentials in Cisco XDR

1. Sign in to your Cisco XDR portal (e.g., https://xdr.us.security.cisco.com).
2. Navigate to Administration > API Clients.
3. Create a new API Client with the necessary read and execution scopes:
   • Incidents: Read/Write
   • Investigate: Read
   • Casebook: Read/Write
   • Automation: Read/Execute
4. Copy the Client ID and Client Password.

2. Configuration (mcp.json)

For standard local MCP clients (such as Claude Desktop or Cursor), add the server configuration to your mcp.json file:

{
  "mcpServers": {
    "cisco-xdr": {
      "command": "node",
      "args": ["/path/to/xdr-mcp-community/build/index.js"],
      "env": {
        "XDR_CLIENT_ID": "your_client_id_here",
        "XDR_CLIENT_PASSWORD": "your_client_password_here",
        "XDR_REGION": "us",
        "MCP_TRANSPORT": "stdio"
      }
    }
  }
}

Note: For production deployments, inject XDR_CLIENT_ID and XDR_CLIENT_PASSWORD from your environment or a secrets vault rather than hardcoding them in plaintext files.

3. Running Over Streamable HTTP

To run the server as a shared microservice for multi-agent platforms:

git clone https://github.com/technoxi/xdr-mcp-community.git
cd xdr-mcp-community
npm install
npm run build

export XDR_CLIENT_ID='your_client_id'
export XDR_CLIENT_PASSWORD='your_client_password'
export XDR_REGION='us'
export MCP_TRANSPORT='http'
export PORT=8000

node build/index.js

The server starts an HTTP endpoint at http://127.0.0.1:8000/mcp, ready to serve streaming MCP tool calls to any authorized agent runtime.

Engineering Takeaways

Integrating AI into security operations does not mean abdicating operational control.

1. Schema-enforced tools prevent hallucinated triage: By connecting agents to structured REST tools via Model Context Protocol, the model reasons over actual detection telemetry rather than speculating on alert descriptions.
2. Community tools require active maintenance: As enterprise cloud platforms evolve their underlying REST interfaces, community MCP adapters must be updated to match the living data contracts of the production API.
3. Stage, do not execute: The most powerful AI security agent is one that automates 90% of the investigative legwork—finding observables, correlating sightings, and drafting the casebook—while delegating destructive containment to human-approved, audited change workflows.