From Alert Queue to Attack Narrative: Inside the Google SecOps Triage and Investigation Agent
The bottleneck was never detection. Modern SOCs are not short on signals. They are short on the hours needed to make sense of it.
A mature Google SecOps deployment ingests endpoint telemetry, on-premises firewall logs, identity events, network data, cloud audit trails, and custom application logs. The detection engine does its job. What follows is the expensive part: an analyst opens an alert, runs a search to pull surrounding events, pivots to threat intelligence to check a hash, reconstructs a process tree to understand what was actually executed, and only then decides whether the alert deserves escalation.
Repeat that a few thousand times a day and the outcome is predictable. Alerts go untriaged. Investigation quality varies by who happens to be on shift, and analysts spend most of their time answering the least interesting question available: is this real, or is this noise?
The Triage and Investigation Agent (TIN) in Google Security Operations answers that question autonomously, and shows its work while doing it.
What TIN is, and what it has done
TIN is an AI-driven investigation agent embedded natively in Google SecOps. Given an alert, it determines whether the alert is a true positive or a false positive and returns a summarized explanation of how it reached that assessment.
The important design decision is that TIN does not simply classify. It investigates. For each alert, it builds an investigation plan grounded in Mandiant investigative principles, executes that plan against the data in the platform, and assembles the evidence into a narrative. Where an attacker has moved across systems, that includes an attack narrative stitched together from separate alerts.
The agent entered public preview in November 2025 and is now generally available. At production scale, it has investigated more than five million alerts, reducing a typical 30-minute manual analysis to roughly 60 seconds using Gemini.
Two caveats worth stating alongside those numbers. Google has not published false-positive rates for the agent’s own verdicts, and time-saved figures are sensitive to how a given SOC was working beforehand. Treat the published figures as directional and measure your own, which the platform now makes straightforward.
How an investigation runs

TIN works through a set of built-in investigation tools, invoked dynamically based on what the alert contains:
Dynamic search queries.
The agent runs and iteratively refines searches across SecOps data to gather the context surrounding an alert, the equivalent of an analyst writing, reading, and rewriting a query until the picture resolves.
Google Threat Intelligence enrichment.
Indicators in the alert (domains, URLs, file hashes) are enriched with GTI context, so reputation judgments come from Google’s threat research rather than from a manual lookup in a second tab.
Command-line analysis.
Where an alert carries command-line activity, the agent explains in natural language what the command actually does. Obfuscated PowerShell becomes a readable sentence.
Process tree reconstruction.
The agent assembles the full chain of related process activity, turning a single flagged process into the sequence that produced it and the sequence that followed.
Every step is recorded. The result is an auditable investigation timeline rather than an opaque verdict, which matters enormously for the first question every SOC lead asks about agentic AI: why should I believe it?
Investigations are complete in an average of about 60 seconds, with a hard ceiling of 20 minutes, and there is no queue.
Two ways in, with the controls where they belong
Automatic investigation runs against alerts matching supported log types, and the trigger behaviour is configurable. Teams can define their own criteria for which alerts qualify, and can deliberately delay the start of an investigation by up to 20 minutes. It is a small feature with an outsized effect, since waiting for related events to land produces a materially better-correlated investigation than firing the instant the first alert appears.
Manual investigation is available from the Alerts & IoCs page or from an alert inside a case, via a Run Investigation action. The banner switches to View Investigation once the analysis completes.
Past and in-progress investigations remain accessible from anywhere in the platform, and re-running an investigation on the same alert produces a separate, independently reviewable entry rather than overwriting the previous one.
What the analyst receives
| Output | What it gives the analyst |
| Verdict | True positive or false positive |
| Confidence | How strongly the agent holds that verdict |
| Summary | A plain-language explanation of the assessment |
| Investigation timeline | Every step taken, with supporting evidence |
| Recommended actions | Concrete next steps for response |
The consistency is the point. Two analysts looking at the same alert now start from the same evidence base and the same reasoning, instead of from whatever each of them thought to check.
Beyond the alert: cases, playbooks, and dashboards
TIN’s value compounds once its output flows into the surrounding workflow rather than sitting in a panel.
Case summaries.
TIN results and verdict summaries surface directly in the Case Summary view, so a case-level view carries the agent’s assessment without requiring a pivot.
Agentic automation.
Available in preview, this pairs dynamic AI agents with deterministic enterprise playbooks. TIN outputs, verdict, and confidence among them can drive subsequent playbook steps, so a high-confidence false positive can route to an automated closure while a true positive enters a remediation flow with the evidence already attached. The hybrid design is deliberate: analysts stay in control of high-impact actions while the routine decisions are automated.
Dashboards.
Dedicated Triage and Investigation dashboards track what the agent investigated, what verdicts it reached, and how much analyst time it saved. They also expose Security Token consumption, which is how TIN activity is metered and billed, putting the agent’s operational value and its cost in the same view.
Knowing the boundaries
An honest assessment of any agent includes what it does not do. As documented today:
- TIN runs only on data ingested through Google SecOps SIEM and does not process alerts arriving via SOAR connectors, so the log sources onboarded through Google SecOps SIEM services define what the agent can see.
- TIN supports single-tenant Google SecOps configurations, and MSSP customers delivering Google SecOps managed services from a single SecOps SOAR tenant connected to multiple SIEM tenants. Multi-tenant configurations outside that structure are not supported.
- Usage is metered against Security Tokens. Enterprise, Enterprise Plus, and Google Unified Security customers were eligible for a no-cost trial that ran from April to August 2026, with hourly investigation limits by tier; continued use requires a paid Security Tokens subscription.
None of these are unusual for a feature at this stage. They are, however, the details that determine whether a rollout plan survives its first week, and the first things to settle when working out how to implement Google SecOps for enterprises.
Human plus agent, not agent instead of human

Google’s framing for this is the agentic SOC: a human-led operation in which agents handle the first pass. Agents triage, gather evidence, correlate, and package next steps. Humans set the policy boundaries, review the outcomes, and own the decisions that change production state.
That division of labour is visible in TIN’s design. It explains itself. It logs every action. It hands the analyst a verdict and the reasoning behind it. The agent is built to be checked, which is precisely why analysts come to trust it.
TIN no longer stands alone. Google has extended the fleet across the full SOC lifecycle: a Detection Engineering agent that finds coverage gaps and generates rules, agentic automation for containment, and a Threat Hunting agent that scours historical telemetry for what slipped past, all currently in preview, with a Third-Party Context agent announced as coming. Together they span the same sequence a SOC already follows to get from signal to containment, reshaping what Google SecOps security operations services look like from end to end.
When first-pass investigation is autonomous, explainable, and consistent, the untriaged backlog stops being a structural fact of SOC life. Analyst attention moves to the work that genuinely requires judgment: ambiguous cases, novel techniques, incidents where an attacker is actively moving.
Crest Data’s contribution
Alongside its broader Google SecOps partner services, Crest Data has worked as an engineering partner on TIN, and our primary contribution has been the analyst-facing layer: the interface through which the agent’s reasoning becomes something a human can act on.
The investigation experience.
We designed and built UI surfaces within Google SecOps that render the agent’s work legibly: investigation timelines, entity correlation views, and evidence visualization layers. An agent that gathers excellent evidence and presents it poorly delivers very little. The engineering problem is making a multi-step autonomous investigation readable at a glance and drillable when an analyst wants to verify a specific step.
The welcome experience through GA.
Ahead of general availability, we built the onboarding and welcome experience for the feature: the first-run flow that introduces TIN to an analyst, sets expectations about what the agent does and does not decide, and moves a user from curiosity to their first investigation without a documentation detour. Adoption of agentic features is won or lost in the first session, and this work was scoped specifically to carry the feature into GA.
Contextualizing agent output.
Beyond layout, we worked on making TIN’s outputs actionable, framing verdicts, confidence, and recommended actions in the terms analysts actually use when deciding what to do next.
Strengthening SecLM with real-world use cases.
We contributed domain-specific security scenarios across a range of products and environments to improve SecLM’s contextual understanding and reasoning quality against realistic threat activity.
Detection content.
We have also written and refined YARA-L rules across multiple security products, strengthening the detection layer that feeds the agent in the first place.
Crest Data is proud to have helped build the layer where the shift to agentic investigation becomes real for the analyst: the point where an autonomous investigation stops being a technical achievement and becomes a decision someone can make with confidence.
Turning agentic investigation into everyday SOC practice
TIN shows what first-pass investigation looks like when it is fast, explainable, and consistent. The agent alone doesn’t decide how much of that value a SOC captures, though. Clean SIEM ingestion, well-tuned detection content, playbooks that act on verdicts and confidence, and analysts who trust what they are reading all matter just as much. That is where Google SecOps implementation services make the difference. They cover connecting the right log sources and shaping trigger criteria. They also extend to Google SecOps SOAR implementation services that let agent output drive automated closure and remediation without taking high-impact decisions away from your team.
Crest Data brings the same engineering depth that helped shape TIN’s analyst experience to every SecOps engagement, from first deployment to a fully agentic SOC. Explore our Google SecOps consulting services to see how we can help your team move from alert queue to attack narrative, faster.
Thought Leader: Priyank Shah



