Table of Contents
Thoughts from NEXT ‘26
Google’s Triage and Investigation agent processed more than 5 million alerts last year. It’s also doing VirusTotal lookups through an LLM. Both of those things are true, yet neither was front and center in the keynote coverage.
That tension is where this post lives. Most NEXT security recaps are reading off the same press release. What practitioners actually need is a cleaner filter: what’s real, what’s premature, and what got buried while everyone was watching the flashy agentify-all-the-things demos. Let me give you that.
The Agentic SecOps Story Is More Complicated Than Google Is Letting On
Google led its security narrative with three new agents in Google Security Operations: a Threat Hunting agent, a Detection Engineering agent, and more data points on the existing Triage and Investigation (TIN) agent. The TIN stat they’re leading with is real: over 5 million alerts processed in the past year, cutting typical 30-minute manual triage to 60 seconds.
But TIN’s architecture has a problem that Google isn’t surfacing clearly.
The agent is using LLM and agentic layers to perform enrichment: VT lookups, Mandiant context, IoC correlation. None of that should be happening there. These are tasks that either belong in the Entity Graph (which already contributed to the detection that fired the alert), or in an upstream SOAR enrichment step that should have run before the triage agent ever touches the case. Routing these through an LLM reasoning layer adds latency, cost, and opacity to operations that don’t need reasoning. They need reliable, deterministic data retrieval.
The principle is simple: use each tool for what it’s good at. Old-fashioned API calls and ETL enrichment are sometimes exactly the right answer. Putting an LLM in the middle of a VirusTotal lookup doesn’t make it better. Let the model focus on what it’s actually good at: reasoning, synthesis, pattern recognition across complex context. Keep enrichment in the pipeline stages designed for it.
The other gap: TIN currently lacks native support for organizational context and importantly, SOPs. An agent that doesn’t know your business context, your crown jewels, your tolerance for false positives, or your escalation paths is doing generic triage. That’s useful, but it’s not the same as a tier-1 analyst who’s been at your org for six months. The technical groundwork is there for Google to close this gap, and it’s the natural next evolution that’s been hinted at. It’s not there yet.
The Detection Engineering agent gets even more skepticism from me. Auto-generating persistent detection rules sounds compelling. But detection quality is the whole game in SecOps. A preview-status agent writing rules for production environments is a claim I want to see backed by real customer stories before I put weight on it. Detection engineering is a craft, not a content generation problem.
And all of it has a dependency the keynote skipped over: your SIEM maturity is the floor, not the ceiling. These agents are only as good as the data underneath them. If your log sources are incomplete, your schemas are inconsistent, or your detection coverage has gaps, the agent will produce confident-sounding analysis on a weak foundation.
(Honestly, this applies to most AI features Google has shipped in SecOps over the last two years. The platform assumes you’ve already done the hard work. Most orgs haven’t.)
To be fair to Google - these are incredibly tough problem areas to solve for, let alone “Agentify.” Other platforms are in very similar spots in practice, though Google’s vision and technical foundation leave me bullish on their long-term execution in the space.
SCC’s Standard Tier Expansion Is the Announcement People Are Sleeping On
Everyone has been talking about the agents. Not enough people are talking about what Google did to Security Command Center Standard tier.
Google expanded Standard to include data security posture management, compliance monitoring, vulnerability management, and risk analysis at no additional cost. For organizations that were previously on Standard and staring at the price gap between that and SCC Enterprise (SCCE), this is a meaningful expansion of what you get for free.
But the piece that should actually get your attention: SCC Standard now includes continuous discovery and posture management for AI agents, models, and MCP servers. That is a genuinely new security surface area, and Google is the first major cloud platform to take a native posture management stance on it.
If you have AI workloads running on Google Cloud (and if you’re reading this, you probably do or will soon), getting asset inventory, risk context, and posture findings for your agent fleet and model deployments in the same console you’re already using for everything else is not a small thing. The attack surface for AI systems is real and most organizations don’t have good visibility into it. This is a start.
Especially as many are wondering what the marriage of Wiz and SCC will look like in the long term, this is a very solid investment by Google into the security of orgs that arguably need it most.
Agent Governance Is Underappreciated
Buried in the announcements: Agent Identity, Agent Gateway, and expanded Model Armor integrations. Together, these form the scaffolding for governing AI agent traffic in enterprise environments, and practitioners should be paying more attention to this cluster than to the demo agents.
Agent Identity gives every agent a cryptographic identity with a clear, auditable trail mapped to authorization policies. This is the foundational requirement for any serious enterprise AI deployment. Without identity, you don’t have accountability.
Agent Gateway enforces policy at the agent-to-agent and agent-to-tool layer. It understands protocols like MCP and A2A, which means it can inspect the actual content of agent interactions, not just network-level metadata. That’s the right place to catch prompt injection and data leakage before they become incidents.
Model Armor integration across Agent Gateway, Agent Runtime, LangChain, and Firebase closes the loop. Runtime protection for model interactions is a problem class most security teams aren’t thinking about yet. They will be.
If you’re building on Google Cloud and deploying AI agents, this governance layer is where your architecture attention should go.
Quick Takes
Dark Web Intelligence and the 98% accuracy claim. Google’s GTI-powered dark web monitoring is interesting, and the team behind it is serious and credentialized. Deeply embedded GTIG analysts with real dark web expertise grounding the Gemini models. The claim that previous tools averaged over 90% false positives isn’t hard to believe. But “98% accuracy in internal tests” is a marketing number, not an ops number. I’ll believe it when it holds up in a customer environment over six months. Watch this capability. The underlying signal is genuine.
Post-Quantum KMS. KMS Quantum Safe Key Imports in preview is quiet but correct. Harvest-now-decrypt-later is not a zero-probability threat, and the timeline for quantum attacks on current encryption is getting shorter. (You can read more here on recent research by Google in the space). Getting quantum-safe key import infrastructure in place isn’t exciting work. It’s the kind of infrastructure work that looks prescient in five years and looks negligent if you skipped it. Plan accordingly.
Wiz integration. Wiz’s AI-Application Protection Platform (AI-APP) is now billing itself as part of Google’s “agentic cloud security” story, covering risk posture and runtime analysis for AI applications across clouds. The capability is real. The integration is still early. For Google-native environments, the native SCC and agent governance story is more coherent right now. Wiz earns its place in hybrid and multicloud shops where portability matters, and the massive public + behind-the-scenes investment in this integration is going to be key to watch over the next 12-18 months.
What It All Means
Native identity, governed agent traffic, runtime protection, posture management extending to AI workloads. The architectural vision is coherent and ahead of where most enterprises are operationally.
The gap is between the vision and the assumption. Google’s platform assumes practitioners who have already done the unglamorous work: clean data pipelines, robust contextual data stores, solid detection libraries, mature SOAR playbooks, consistent log coverage. Most shops aren’t there, and the agents won’t close that gap; they only amplify whatever you’ve already built.
The most important thing you can do after NEXT isn’t spinning up a Threat Hunting agent. It’s auditing your log source coverage, reviewing your detection library for gaps, and making sure enrichment is happening in the right layer of your stack, not being outsourced to an LLM that has no business being there.
That doesn’t get a keynote slot. But it’s what makes everything else work.
If you think I’m wrong on the TIN architecture critique, I want to hear it - especially if you’re running it in production and seeing something different. Same thing goes for the maturity floor argument. Find me on LinkedIn or reach out directly.