Connect Google SecOps to ChatGPT: Manage Security Incidents & Cases

If you need to connect Google SecOps (formerly Chronicle) to ChatGPT (similar to how you might connect Google Workspace) to automate threat hunting, triage security incidents, or orchestrate case management workflows, you need a Model Context Protocol (MCP) server. This infrastructure layer translates ChatGPT's natural language tool calls into the highly structured JSON-RPC requests that the Google SecOps REST APIs demand. You can either spend weeks building, securing, and maintaining this translation layer in-house, or you can use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL in seconds.

If your team uses Claude, check out our guide on connecting Google SecOps to Claude or explore our broader architectural overview on connecting Google SecOps to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise Security Operations platform is a massive engineering challenge. You have to handle complex Unified Data Model (UDM) schemas, manage asynchronous polling for long-running threat searches, and navigate the deeply nested relationship between cases, alerts, and involved entities. Every time Google updates their API or you need to expose a new endpoint to your AI, custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Google SecOps, connect it natively to ChatGPT, and execute complex Security Operations Center (SOC) workflows (similar to managing Sentinel incidents) using natural language.

The Engineering Reality of the Google SecOps 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, implementing it against Google SecOps's highly specific API surface is exceptionally painful.

If you decide to build a custom MCP server for Google SecOps, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with this API:

1. Navigating the Unified Data Model (UDM) Abstraction

Google SecOps relies heavily on its Unified Data Model (UDM) to normalize telemetry from hundreds of different network appliances, endpoints, and cloud providers. When an LLM wants to search for a specific IP address or hash, it cannot simply hit a /search?ip=1.1.1.1 endpoint. It must construct a valid UDM query (e.g., target.ip = "1.1.1.1"), define specific time bounds, and handle massive JSON response payloads that often exceed standard LLM context windows. Building a custom MCP server requires writing strict schema validators to ensure the LLM generates syntactically correct UDM queries before the request is sent to Google, otherwise the API will reject it.

2. Complex Relational Graphs in Case Management

Case management in Google SecOps is not a flat list of tickets. It is a hierarchical graph. A Case contains CaseAlerts, which in turn contain InvolvedEntities and ContextProperties. If an LLM asks "Update the status of the alerts involved in Case 123," your MCP server must know how to first fetch the case, parse the nested alert IDs, and issue subsequent PATCH requests to the specific /v1/{caseAlert.name} endpoints. Exposing this dynamically requires mapping path parameters (like case_id and case_alert_id) into a flat input namespace so the LLM can provide them accurately.

3. The Asynchronous Polling Trap for Threat Searches

Many analytical operations in Google SecOps, such as historical retrohunts or deep instance searches (google_sec_ops_instances_search), do not return data immediately. Instead, they return a Long-Running Operation (LRO) object. LLMs operate synchronously - they expect an answer to their tool call in the immediate response. If you build your own MCP server, you have to implement an asynchronous polling wrapper that holds the LLM's HTTP connection open while repeatedly checking the LRO status endpoint, or you must build a complex state-machine into the LLM prompt to teach it how to poll for results itself.

Quickstart: Generate and Connect Your MCP Server

To bypass these architectural hurdles, you can use Truto to dynamically generate a Google SecOps MCP server. Truto derives the tool definitions directly from the integration's documented schemas, meaning your LLM gets perfectly formatted JSON schemas for every endpoint without you writing a single line of mapping code.

Step 1: Create the Google SecOps MCP Server

You can generate the MCP server either through the Truto dashboard or programmatically via the API. Both methods output a secure URL containing a cryptographically hashed token that authenticates the server.

Method A: Via the Truto UI

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Google SecOps instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., allow read and write methods, filter by specific tags like cases or alerts).
5. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/a1b2c3d4...).

Method B: Via the Truto API If you are building an automated onboarding flow for your SOC analysts, you can generate the MCP server programmatically by sending a POST request to the Truto API.

curl -X POST https://api.truto.one/integrated-account/YOUR_INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Google SecOps SOC Assistant",
    "config": {
      "methods": ["read", "write", "custom"],
      "tags": ["cases", "alerts", "udm"]
    }
  }'

The API validates that the requested tools exist, generates the token, stores the configuration, and returns the endpoint URL. This URL is self-contained - it handles routing and authentication automatically.

Step 2: Connect the MCP Server to ChatGPT

Once you have your Truto MCP URL, you need to expose it to ChatGPT. You can do this through the ChatGPT UI or via a standard MCP configuration file for local development.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode (MCP support requires this feature flag, available on Pro, Plus, Business, Enterprise, and Education tiers).
3. Under MCP servers / Custom connectors, click to add a new server.
4. Set the Name to "Google SecOps".
5. Paste your Truto MCP URL into the Server URL field and click Save.

ChatGPT will immediately connect to Truto, handshake via JSON-RPC 2.0, and load the dynamic tool definitions.

Method B: Via Manual Config File If you are running a custom AI agent framework or using a compatible desktop client, you can connect to the remote Truto MCP server using the official Server-Sent Events (SSE) wrapper. Add the following to your MCP configuration JSON file:

{
  "mcpServers": {
    "google-secops-prod": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_TRUTO_MCP_TOKEN"
      ]
    }
  }
}

Hero Tools for Google SecOps

Truto automatically generates hundreds of tools for the Google SecOps API. Here are the highest-leverage tools for case management and threat hunting.

Perform UDM Searches

google_sec_ops_instances_udm_search

Executes a Unified Data Model (UDM) search against the instance. This tool is critical for finding raw events, network connections, or process executions that match a specific threat indicator.

"Search the UDM for any events where target.ip is '198.51.100.45' over the last 24 hours. Summarize the user agents involved."

Fetch Case Details

get_single_google_sec_ops_case_by_id

Retrieves the full metadata for a specific SOC case, including its priority, current stage, and assignee. The LLM uses this to gain context before taking remediation actions.

"Pull the details for case ID 'cases/12345' and tell me who it is currently assigned to and what the priority level is."

Append Case Comments

create_a_google_sec_ops_case_comment

Allows the AI agent to write directly to the case wall. This is useful for appending automated analysis, summaries of UDM search results, or shift-handoff notes.

"Add a comment to case 'cases/12345' stating that the associated IP address was found in 4 distinct UDM events, all tied to the guest network."

Update Case Attributes

update_a_google_sec_ops_case_by_id

Modifies case properties such as the display name, priority, or stage. Analysts can instruct the LLM to escalate cases based on new findings.

"Update case 'cases/12345' to have a priority of 'CRITICAL' and change the stage to 'Containment'."

Look Up Enriched Entities

google_sec_ops_instances_search_entities

Searches for enriched entities (like users, hostnames, or file hashes) based on a specific indicator. This bypasses raw UDM logs to fetch high-level entity intelligence.

"Look up the entity details for the hostname 'DESKTOP-9X8B7' and list any active alerts associated with it."

Bulk Close False Positives

google_sec_ops_cases_execute_bulk_close

Closes multiple cases in a single operation. This is a massive time-saver for SOC teams dealing with known false-positive alert spikes.

"Execute a bulk close on cases 12346, 12347, and 12348. Use the close reason 'FALSE_POSITIVE' and add the root cause note 'Authorized vulnerability scanner'."

For a complete list of all supported endpoints, schemas, and required parameters, visit the Google SecOps integration page.

Workflows in Action

When you connect Google SecOps to ChatGPT via Truto's MCP server, the LLM can chain multiple tool calls together to orchestrate complex incident response workflows. Here is how real SOC teams use this in production.

Scenario 1: Triaging a Suspicious Login Case

A SOC analyst receives a new case alert for a suspicious login and asks ChatGPT to investigate and escalate if necessary.

"Investigate case 'cases/99887'. Check the UDM for the source IP associated with this case over the last 12 hours. If it shows multiple failed logins across different accounts, escalate the case priority to HIGH and leave a comment with your findings."

Step-by-step execution:

1. The agent calls get_single_google_sec_ops_case_by_id to extract the context and the specific source IP from the case metadata.
2. It calls google_sec_ops_instances_udm_search using a generated UDM query (e.g., principal.ip = " [IP]" AND metadata.event_type = "USER_LOGIN").
3. Observing multiple failures, the agent calls update_a_google_sec_ops_case_by_id with priority: "HIGH".
4. Finally, it calls create_a_google_sec_ops_case_comment to document the timeline of failed logins on the case wall.

The analyst receives a fully triaged, escalated, and documented case without leaving the chat interface.

sequenceDiagram
    participant User
    participant GPT as ChatGPT
    participant Truto as Truto MCP
    participant SecOps as Google SecOps

    User->>GPT: "Investigate case 99887..."
    GPT->>Truto: call: get_single_google_sec_ops_case_by_id
    Truto->>SecOps: GET /v1/cases/99887
    SecOps-->>Truto: Case metadata & IP address
    Truto-->>GPT: Case details
    
    GPT->>Truto: call: google_sec_ops_instances_udm_search
    Truto->>SecOps: GET /v1/instances/.../udmSearch?query=...
    SecOps-->>Truto: UDM Event logs
    Truto-->>GPT: Multiple failed logins found

    GPT->>Truto: call: update_a_google_sec_ops_case_by_id
    Truto->>SecOps: PATCH /v1/cases/99887 (priority=HIGH)
    SecOps-->>Truto: Updated case
    Truto-->>GPT: Success

    GPT->>Truto: call: create_a_google_sec_ops_case_comment
    Truto->>SecOps: POST /v1/cases/99887/caseComments
    SecOps-->>Truto: Comment created
    Truto-->>GPT: Success
    GPT-->>User: "Case 99887 has been escalated and documented."

Scenario 2: False Positive Bulk Closure

An analyst realizes a recent software deployment triggered a wave of identical alerts and asks ChatGPT to clean up the queue.

"Find the entity details for the hash 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'. Then, bulk close cases 1001, 1002, and 1003 with the reason 'Benign True Positive' citing that hash as safe."

Step-by-step execution:

1. The agent calls google_sec_ops_instances_search_entities to verify the hash and fetch its current context.
2. The agent calls google_sec_ops_cases_execute_bulk_close, passing the array of casesIds and the specific closeReason.

The analyst instantly resolves queue bloat without manually clicking through dozens of UI menus.

Security and Access Control

Exposing a SOC platform to an AI agent requires strict guardrails. Truto's MCP architecture provides four layers of access control directly embedded in the server token:

• Method Filtering (methods): You can restrict an MCP server to strictly read-only operations. By setting methods: ["read"], the agent can execute UDM searches and fetch cases, but any attempt to call create or update endpoints will be rejected at the Truto router level.
• Resource Tagging (tags): You can limit the server to specific operational domains. Passing tags: ["cases"] ensures the LLM only sees case-management tools and cannot discover or access administrative configuration endpoints.
• Dual-Layer Authentication (require_api_token_auth): For highly sensitive environments, the MCP URL token alone is not enough. Enabling this flag forces the connecting client to also supply a valid Truto user API token in the Authorization header.
• Time-to-Live (expires_at): You can generate ephemeral MCP servers for incident response contractors. Setting a strict ISO datetime ensures the server automatically self-destructs when the engagement window ends.

Handling Google SecOps API Limits

When querying large data sets - particularly via UDM searches - you will inevitably encounter API rate limits. It is critical to understand how Truto handles these constraints.

Truto operates as a transparent proxy for rate limit errors. Truto does not retry, throttle, or apply backoff logic when Google SecOps rejects a request. If the upstream Google API returns an HTTP 429 (Too Many Requests), Truto immediately passes that 429 error back to the ChatGPT client.

However, Truto normalizes the upstream rate limit data into standardized IETF headers before passing it back:

• ratelimit-limit: The maximum number of requests allowed in the current window.
• ratelimit-remaining: The number of requests left.
• ratelimit-reset: The timestamp when the limit will clear.

The caller (your custom agent or the LLM framework) is entirely responsible for reading these headers and implementing the necessary retry and exponential backoff logic.

Stop Writing Boilerplate SecOps Integrations

Connecting ChatGPT to Google SecOps transforms how analysts interact with telemetry and manage incidents. But building and maintaining the MCP server to bridge the gap between LLM JSON-RPC outputs and deeply nested Google SecOps REST endpoints is a poor use of engineering time.

By leveraging Truto, you abstract away the API maintenance, schema mapping, and authentication lifecycles. Your MCP server dynamically updates as endpoints evolve, ensuring your AI agents always have the correct tools to execute SOC workflows securely and reliably.