Connect Cortex XDR to Claude: Run Forensics & Response Actions

If you need to connect Cortex XDR to Claude to automate threat hunting, orchestrate incident response, or run forensic investigations, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Cortex XDR's highly structured REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on connecting Cortex XDR to ChatGPT. If you are building multi-agent architectures, explore our broader overview on connecting Cortex XDR to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling Extended Detection and Response (XDR) platform is a high-stakes engineering challenge. You must handle complex authentication lifecycles, map massive nested JSON schemas to MCP tool definitions, and deal with Cortex XDR's strict endpoint isolation protocols. Every time Palo Alto Networks updates an endpoint or deprecates a V1 resource, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Cortex XDR, connect it natively to Claude, and execute complex security operations using natural language.

The Engineering Reality of the Cortex XDR API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specialized B2B security APIs is painful. Cortex XDR is built to manage massive telemetry sets across endpoints, networks, and cloud environments. Its API reflects that scale and complexity.

If you decide to build a custom Cortex XDR MCP server, here are the specific integration challenges you will face:

Asynchronous Response Actions and Polling Not all endpoints in the Cortex XDR API behave like standard synchronous CRUD operations. When you instruct Cortex XDR to run a YARA scan or collect a forensic log bundle, the API does not wait for the operation to finish. Instead, it immediately returns an action_id. An LLM cannot natively handle this async loop. To make this agentic, your MCP server must expose an initial trigger tool (e.g., cortex_xdr_endpoints_start_yara_scan), followed by a separate status polling tool (cortex_xdr_actions_get_action_status), and explicitly instruct the LLM via schema descriptions on how to pass the action_id between them.

License-Gated Capabilities and Silent Failures Cortex XDR APIs are heavily gated by tenant licensing. An endpoint like cortex_xdr_compliance_assessment_profiles_lookup requires the Cloud Posture Management add-on, while cortex_xdr_disable_prevention requires an XDR Pro per Endpoint license (and will fail if the tenant only has an XDR Pro per GB license). If your MCP server indiscriminately exposes all tools to Claude, the LLM will hallucinate capabilities, attempt to execute actions it is not licensed for, and fail mid-workflow. Managed MCP servers dynamically filter available tools based on the active connection's permissions and license tier.

Tenant Version Fragmentation (3.x vs 6.0) Palo Alto Networks is migrating its incident management architecture. Older 3.x tenants rely heavily on the legacy /public_api/v1/incidents endpoints. Newer 6.0 platform tenants have entirely replaced these with Cases and Issues endpoints (e.g., /public_api/v1/case/search). A hardcoded custom MCP server will break depending on which tenant you connect to. You must build an abstraction layer that presents a unified set of operations to Claude, hiding the underlying platform fragmentation.

How to Create the Cortex XDR MCP Server

Truto eliminates the need to build a custom MCP server. By reading the Cortex XDR API documentation and your specific tenant's resource definitions, Truto dynamically generates a JSON-RPC 2.0 endpoint that serves as a ready-to-use MCP server.

You can generate this server via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

For IT admins and security analysts setting up internal tools, the UI provides a fast, no-code path:

1. Log into your Truto account and navigate to your Integrated Accounts.
2. Select your connected Cortex XDR account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., restrict to read operations for safety, or allow write for incident response).
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the API

For developers embedding AI agents into larger security platforms, you can programmatically generate MCP servers. This is ideal for provisioning short-lived, scoped access to Cortex XDR for automated forensic scripts.

Make a POST request to /integrated-account/:id/mcp with your desired configuration:

curl -X POST https://api.truto.one/admin/integrated-accounts/{integrated_account_id}/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cortex XDR Incident Response",
    "config": {
      "methods": ["read", "write", "custom"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Response:

{
  "id": "mcp_srv_9x8y7z6a",
  "name": "Cortex XDR Incident Response",
  "config": {
    "methods": ["read", "write", "custom"]
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/f7e6d5c4b3a2..."
}

This URL is a fully self-contained, authenticated MCP server. The cryptographic token in the path handles the mapping to your specific Cortex XDR tenant credentials.

How to Connect the MCP Server to Claude

Once you have the Truto MCP server URL, you must register it with your Claude environment.

Method A: Via the Claude UI (Web/Desktop)

If you are using Claude's graphical interface, adding the server takes seconds:

1. Open Claude and navigate to Settings.
2. Select Integrations (or Connectors depending on your plan tier).
3. Click Add MCP Server (or Add custom connector).
4. Paste your Truto MCP URL into the Server URL field.
5. Click Add.

Claude will immediately perform a handshake with the Truto MCP server, retrieve the list of available Cortex XDR tools, and inject them into the model's context window.

Method B: Via Manual Configuration File

If you are running the Claude Desktop app locally or managing a headless AI agent framework, you can connect the server by updating the claude_desktop_config.json file.

Because Truto provides a remote SSE (Server-Sent Events) endpoint, you must use the standard @modelcontextprotocol/server-sse proxy command to route the local process to the remote URL.

{
  "mcpServers": {
    "cortex-xdr-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/f7e6d5c4b3a2..."
      ]
    }
  }
}

Save the file and restart Claude Desktop. The Cortex XDR tools will now be available for your agent.

Hero Tools for Cortex XDR

Truto automatically generates tools based on the Cortex XDR documentation records. By parsing the exact JSON schemas required by Palo Alto Networks, Truto ensures Claude knows exactly how to format its requests.

Here are the highest-leverage tools available for AI agent workflows:

list_all_cortex_xdr_case

Retrieves a list of cases (incidents) that match specific filter criteria. This is the starting point for almost every automated triage workflow. It supports complex nested AND/OR filtering operators required by the XDR schema.

"Claude, pull the 10 most recent cases with a severity of 'High' or 'Critical' that were created in the last 24 hours. Summarize the initial observation time and category for each."

cortex_xdr_endpoints_isolate

Executes an isolation response action against one or more endpoints. This severs the endpoint from the network (except for Cortex XDR management traffic) to stop lateral movement during an active breach.

"I see that case ID 4059 involves a confirmed ransomware payload on host 'WIN-DB-PROD-01'. Execute the endpoint isolate command for that machine immediately to prevent lateral spread."

cortex_xdr_endpoints_start_yara_scan

Starts an on-demand YARA scan that runs selected rules against a specific endpoint. By default, it covers the full file system, but Claude can narrow the scope to specific paths.

"Trigger a YARA scan on endpoint ID 'e8a7b6c5' using rule ID 'yara_rule_102'. Limit the scan scope to the 'C:\Users\Public\Downloads' directory. Give me the action_id so we can track the results."

cortex_xdr_alerts_get_alerts_multi_events_v_2

Retrieves a list of alerts containing multiple events. This is critical for investigating chained attacker behaviors (like a suspicious PowerShell execution followed immediately by an unusual network connection).

"Fetch the multi-event alerts associated with case ID 4059. I need to see the exact sequence of events that triggered the initial BTP (Behavioral Threat Protection) alert."

cortex_xdr_indicators_insert_jsons

Uploads custom Indicators of Compromise (IOCs) retrieved from external threat intelligence sources as JSON objects. This allows Claude to act as a threat intel ingestion engine.

"Take these five malicious IP addresses and three file hashes I found in the latest threat advisory and insert them as active IOCs into Cortex XDR with a severity of 'High'."

cortex_xdr_forensics_investigations_collections

Lists all hunt (scheduled/on-demand artifact searches) and triage (targeted artifact collections) collections that belong to a specific investigation. Essential for navigating deep forensic data.

"List all forensic collections for investigation ID 'INV-90210'. I am looking for a triage collection that pulled the MFT (Master File Table) from the compromised server."

cortex_xdr_quarantine_status

Checks the quarantine status of specific files across your endpoints. Useful for verifying that a mitigation action actually succeeded.

"Check the quarantine status for the file hash 'a1b2c3d4e5f6...' to confirm that the malicious binary was successfully removed from all affected endpoints."

For a complete list of all available Cortex XDR tools, schemas, and endpoint configurations, visit the Cortex XDR integration page.

Workflows in Action

Connecting Cortex XDR to Claude transforms the LLM from a passive chat interface into an active Security Orchestration, Automation, and Response (SOAR) agent. Here are two concrete workflows showing how Claude sequences these tools.

Scenario 1: Automated Triage and Endpoint Isolation

A security analyst receives an urgent page about a critical alert. They need Claude to investigate the context, confirm the threat, and isolate the machine without making the analyst pivot through multiple dashboards.

"Claude, check Cortex XDR for any 'Critical' cases created in the last 2 hours. If you find a case involving behavioral threat protection (BTP) alerts, isolate the affected endpoint immediately and add a timeline record to the case noting the action."

How the agent executes this:

1. list_all_cortex_xdr_case: Claude queries the Cases API, applying a filter for severity: "Critical" and sorting by creation_time descending.
2. cortex_xdr_alerts_get_alerts_multi_events_v_2: Claude takes the case ID from the previous step and retrieves the underlying multi-event alerts to confirm the presence of a BTP detection.
3. cortex_xdr_endpoints_isolate: Having confirmed the threat, Claude extracts the endpoint_id from the alert metadata and executes the isolation command.
4. cortex_xdr_case_timeline_add_record: Claude updates the case timeline, logging that an automated isolation was performed based on a verified BTP alert.

sequenceDiagram
  participant User
  participant Claude
  participant MCP as Truto MCP Server
  participant API as Cortex XDR API

  User->>Claude: "Check critical cases and isolate if BTP detected..."
  Claude->>MCP: Call list_all_cortex_xdr_case
  MCP->>API: POST /public_api/v1/case/search
  API-->>MCP: Return case payload (ID: 5501)
  MCP-->>Claude: JSON response
  Claude->>MCP: Call get_alerts_multi_events_v_2 (case_id: 5501)
  MCP->>API: POST /public_api/v2/alerts/get_alerts_multi_events
  API-->>MCP: Return alerts (BTP verified, Endpoint ID: X92)
  MCP-->>Claude: JSON response
  Claude->>MCP: Call cortex_xdr_endpoints_isolate (endpoint_id: X92)
  MCP->>API: POST /public_api/v1/endpoints/isolate
  API-->>MCP: 200 OK (Isolation triggered)
  MCP-->>Claude: Success
  Claude->>User: "Endpoint X92 isolated successfully."

Scenario 2: Threat Intel Ingestion and Retrospective Scanning

A threat intelligence team receives a new advisory containing malicious file hashes. They need to ingest these into the platform and immediately hunt for their presence.

"Claude, here are three malicious hashes from the new APT group advisory: [hash1, hash2, hash3]. Insert these as new IOCs into Cortex XDR. Then, start a YARA scan across the 'Finance-Servers' asset group to look for these files."

How the agent executes this:

1. cortex_xdr_indicators_insert_jsons: Claude structures the hashes into the required JSON payload and uploads them to the IOC database, assigning appropriate severities.
2. list_all_cortex_xdr_asset_groups: Claude queries the asset groups to resolve the name 'Finance-Servers' into the specific list of endpoint IDs required for the scan.
3. create_a_cortex_xdr_yara: Claude generates a quick YARA rule string containing the three hashes and uploads the rule to Cortex XDR, capturing the returned rule_id.
4. cortex_xdr_endpoints_start_yara_scan: Claude triggers the scan using the rule_id and the retrieved endpoint IDs, returning the action_id to the user so they can monitor progress.

Security and Access Control

Exposing an XDR platform to an AI agent carries inherent risk. Truto provides strict governance mechanisms at the MCP server level to ensure Claude only has access to what it strictly needs.

• Method Filtering: You can lock down an MCP server to only allow read operations (e.g., fetching alerts or cases). If an LLM hallucinates and attempts to call cortex_xdr_endpoints_isolate, the MCP router intercepts and blocks the request before it ever reaches Palo Alto Networks.
• Tag Filtering: Restrict tools to specific operational domains. For example, you can create a server that only exposes tools tagged with compliance or vulnerability-management, keeping incident response tools entirely out of the model's context.
• require_api_token_auth: By default, possessing the MCP URL grants access. For high-security environments, enabling this flag forces the MCP client to also pass a valid Truto API token in the Authorization header, adding a mandatory second layer of identity verification.
• expires_at: Provision Just-In-Time (JIT) access for contractors or temporary automated investigations. Once the ISO datetime is reached, the server and its KV tokens are permanently purged.

Handling Rate Limits in Production

Cortex XDR enforces strict rate limits, particularly on endpoints like get_incident_extra_data which can be capped at just 10 requests per minute per tenant.

It is critical to understand how Truto handles these constraints: Truto does not automatically retry, throttle, or absorb rate limit errors.

When Cortex XDR returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the calling MCP client. Truto normalizes the upstream rate limit data into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset).

The caller (your AI agent framework or Claude Desktop) is fully responsible for reading these headers and implementing its own retry logic and exponential backoff.

Wrap-Up

Connecting Claude to Cortex XDR transforms complex security operations from manual, multi-screen dashboard navigation into fluid, conversational workflows.

By leveraging Truto to generate and manage your MCP servers, you bypass the massive engineering overhead of maintaining custom JSON-RPC middleware, reverse-engineering XDR schemas, and managing OAuth token lifecycles. Instead, your team can focus on writing better prompts, defining tighter incident response playbooks, and responding to threats faster.

Ready to put your security operations on autopilot?