Google SecOps Triage & Investigation Agent experience

1 month ago
Sep 23, 2026 11:21 AM UTC
1 reply
54 views

+8

MikelSA
Bronze 3

Hi everyone,

We are currently evaluating the Triage and Investigation Agent (TIN) in Google SecOps, but we haven't had the opportunity to test it in our environment yet.

We would mainly like to understand how well it works overall in a real SOC environment, and also how it performs with third-party security products such as Cortex XDR, CrowdStrike, Fortinet, etc.

For those already using it:

Overall, how has your experience with TIN been so far?
Does it genuinely help with triage and investigation, or is it still fairly limited?
How well does it investigate alerts coming from third-party products?
Does it understand and correlate the context properly once those logs are ingested into SecOps?
Have you tested it with Cortex XDR or similar EDR solutions?
Is the TP/FP verdict generally reliable, or do analysts still need to redo most of the investigation manually?
Does it work well with custom detections/YARA-L rules built on top of third-party data?
Are there any important limitations when the alert is not coming from Google's own security stack?
Has it actually reduced investigation time for your analysts?

We are considering a trial/PoC or potentially purchasing the capability, so any feedback on overall performance, investigation quality, third-party integrations, limitations and real SOC usage would be really useful.

Thanks!

+5

Ben_T
Staff
8 hours ago
Nov 12, 2026 3:54 PM UTC

Hi MikelSA,

From an architectural standpoint, the Triage and Investigation Agent operates on normalized Unified Data Model (UDM) events, Entity Context Graph data, and Google Threat Intelligence enrichment inside Google SecOps SIEM rather than being restricted to Google native log sources. Looking at the default auto investigation log types table in the documentation, CrowdStrike (CS_EDR, CS_DETECTS, CS_ALERTS, CS_IDP) and Fortinet (FORTINET_FIREWALL, FORTINET_FORTIEDR, FORTINET_WEBPROXY) log types are included for automatic trigger coverage, whereas I do not see a Cortex XDR log type on that default table today, so during a proof of concept your team will want to check that table against your feeds and test manual (Run Investigation) on a Cortex XDR alert before assuming automatic trigger coverage (https://docs.cloud.google.com/chronicle/docs/secops/triage-investigation-agent). Because the agent pivots on UDM entities like principal user, hostname, IP address, process command line, and file hash, investigation quality on third party products and custom YARA L rules depends heavily on having those feeds cleanly normalized into UDM rather than sitting unparsed or missing key entity fields.

Four practical details from the documentation are worth keeping in mind as you scope your trial: 1) the Triage and Investigation Agent operates in single tenant deployments (or MSSP setups connecting one SOAR instance to multiple SIEM tenants) and only processes alerts generated from data ingested into Google SecOps SIEM rather than third party alerts pulled directly into SOAR through a standalone SOAR connector, 2) by default, automatic investigations wait 5 minutes after alert creation (configurable up to 20 minutes) so slightly delayed telemetry from other third party sources has time to arrive and correlate before the verdict is generated, 3) there is no investigation queue, so alerts generated beyond your concurrent investigation limit are not automatically analyzed and you can define custom auto investigation criteria by rule name or log type to focus capacity on higher priority alerts, and 4) Case Summary integration requires Enterprise or Enterprise Plus tiers and investigations consume security tokens that you can monitor on the operational dashboard.

Thanks, Ben

Like

Sign up

Login with SSO

Login to the community

Login with SSO