60-Second Triage Is the Easy Part

· Daniel Miessler

Google says its triage agent has investigated more than five million alerts, taking a typical thirty-minute manual analysis down to about sixty seconds. I believe it, and it's a big deal. But I think speed is the easy part of the agentic SOC. The hard part is whether anyone can check what the agent concluded, because a conclusion nobody can verify is a suggestion, and a SOC runs on findings. Turning one into the other takes a context layer underneath the agent that your team maintains, and one MCP endpoint that every call goes through. I think that's where most of the work is.

In 2017 I wrote that AI would show up in the SOC sooner than people thought, and the argument was about coverage: exabytes of logs, a handful of people, so the bar was finding anything at all in the pile. I gave it five years. It took a bit longer than that, and now we're at the part I didn't think hard enough about back then.

Most of an investigation is assembling the story

So what is a senior analyst doing for those thirty minutes? Pulling the process tree, checking whether this user normally logs in from this country, finding out the host belongs to the finance team that just moved to a new VPN, and asking someone on Slack whether that service account is supposed to be doing this. Most of the thirty minutes is assembling the story.

And once the story exists, the verdict often takes seconds.

I made this argument in Unified Entity Context last year. Give a junior analyst an ambiguous connection and 27 sources and say "good luck, tell me if this is malicious," and it's brutal. Have a principal analyst build a clean timeline first, and the same junior analyst says "obviously malicious" in a few seconds. As I put it then, "It requires genius if you don't have the information. It does not require genius if you do."

Speed still matters, though. M-Trends 2026 found the median time between initial access and the hand-off to a secondary threat group fell from more than eight hours in 2022 to twenty-two seconds. A race that short is really hard to win with triage at any speed. So containment for the alert that fires at initial access, usually a low-severity one, has to be decided in advance, as policy, and the agent's job is to apply it with a verdict you can trust.

An unverifiable verdict is a suggestion

So what's actually left after an agent closes an alert?

In a lot of home-built agent stacks, roughly this. The alert fires, the agent gets a SIEM query tool, an enrichment tool, and a few MCP servers someone connected last quarter. It calls whatever looks relevant, reaches a verdict, writes a nice summary, and the picture it built goes away. That summary is the agent's account of what it did. An incident review needs the record: every query it ran and exactly what came back.

Six months later, when the incident review asks why that alert got closed as benign, you're arguing with a summary.

I hit this constantly with my own AI system, which does real work on real infrastructure every day. The agent would say the tests passed, and the transcript had no test run in it. So now the system enforces one rule: no claim of "done" without tool evidence attached. That rule did more for my trust than any model upgrade this year, because I can actually check the receipts.

Google's agent is built in the right direction here. Each investigation keeps its timeline, the data it used, a disposition, and a confidence level, drawing on an entity context graph. What I'd add, whatever product you run, is provenance on every fact the verdict rests on.

Three things break once the agent hits production

Production adds three problems the demos skip, and all three come back to context.

The first is loops. An unsure agent keeps running slightly different queries. My own agents used to run for two hours on ten-minute tasks until I put a hard 30-minute clock on them. Google bounds each triage investigation at 20 minutes, and every agent needs a bound like that.

The second is your logs. Lab benchmarks use well-formed data. Yours has a parser someone broke in March, a field renamed when you switched EDR vendors, two hours of missing firewall logs, and a hostname convention that changed after an acquisition.

So measure the agent on your own alerts. Replay a few hundred of last quarter's closed alerts, and be honest that for most benign closures the only label is your analyst's call, so you're measuring disagreement, and a senior person adjudicates each one. Mix in confirmed true positives from incidents and purple-team runs, and fence every query to the alert's original timestamp. Start capturing enrichment snapshots now.

The third one is the one I'd worry about most. A SOC agent's whole job is reading attacker-controlled content: the phishing email body, the malicious script, the user-agent string, text an attacker planted in a log field hoping an AI would read it. I've said prompt injection is the trigger and the bomb is what the agent can touch. In a SOC there's a second bomb: the attacker mostly wants one thing from your triage agent, which is for the alert to get closed as benign. Injection is one way to get there. The other is behavior built to look like things your team already signed off on: a sanctioned admin tool, a known service account, the finance team's VPN range.

Build the context layer first, then put the agent on top

I'd give every entity in the SOC, every host, user, service account, alert, and asset, one maintained record, and have the agent read from it on every alert. Every fact in the record carries one of three labels:

  1. Observed: it came from telemetry. This process ran, this login happened, from this IP.
  2. Approved: a human asserted it. This service account is supposed to talk to that database.
  3. Derived: the system inferred it. This login looks anomalous; these two alerts are probably one campaign.

A verdict is only as strong as the weakest fact it depends on. If a benign verdict rests on a #3, the analyst knows exactly which fact to go check. And since the quieter attacker imitates #2 facts, each one is scoped tightly: this account, from these hosts, to this target, at this volume. Anything outside that scope counts as unmatched. I go back and forth on how tight to make those scopes. Too tight and analysts drown in exceptions, too loose and the mimic walks right through. My guess is you start tight on service accounts and loosen with evidence. And my bet is that in an agentic SOC, the approvals your team writes down become the attacker's target list, so they deserve the same care as detection rules.

This is the part I'm super excited about, because it makes reviewing an agent something a human can actually keep up with. Today, checking an agent's verdict basically means redoing the investigation. With the labels, you check the one or two facts it hangs on.

The labels need a bit more to survive real life. A #1 fact carries its source's health: parser version, known gaps, and whether the field is attacker-influenced. A #2 fact has an owner, a date, and an expiry, and once it expires the agent treats it like a #3 until someone re-confirms it. Missing data gets marked as missing, so "no evidence of lateral movement" and "no firewall logs for that hour" look different. And the agent can write #3 facts, but only a human can promote one to #2.

Entity resolution is most of the engineering: one person spread across a dozen identity systems, one IP handed to three laptops in a day. Your SIEM's entity graph is probably a start, and I'd extend that first.

Build the record from an append-only log where each event carries its source and arrival time, and keep it a long time. Mandiant saw BRICKSTORM dwell times of nearly 400 days, against the standard 90-day retention window. And attackers are building a context model of your company too, so the contest is whose record is more accurate and current.

Serve the context layer to the agent through one MCP endpoint

Every fact the agent reads and every action it takes crosses one boundary, the tool call, and in a lot of SOCs that boundary is now an MCP server. Someone adds a SIEM server to a config file on a Tuesday with a service account key pasted in. A quarter later there are nine, and the agent can see and do more than most analysts using it.

I wrote last year that MCP servers are other people's prompts pointing to other people's code. The tool description is a prompt your agent reads and follows, and every response is more text it reads and follows. Nine unreviewed servers means nine authors writing instructions for the thing that closes your alerts.

I love this part, because that same boundary is the best place to fix those three problems and the production gate. So I'd serve the context layer as one MCP endpoint and make it the only one the agent can reach, with any vendor's hosted servers behind it, called under a read-only identity. Your team writes the tool descriptions, reviews them like code, and pins them. Then each problem becomes a property of that server:

  • Loops: the server holds each investigation's budget, in calls and in minutes. When it runs out, the next response says so, and the case goes to a human with the partial work.
  • Messy logs: every response carries the fact's label, its source's health, and an explicit marker wherever data is missing.
  • Attacker content: attacker-influenced fields come back wrapped and tagged as untrusted. The server can't see what swayed the model, so the model only proposes a benign close, and a close tool proves it from the cited facts, and a human reviews it unless untagged #1 facts alone meet the closing rule for that alert type.
  • Production gates: the agent's endpoint carries read tools. Every change is a playbook call the server holds for a human, unless that action type has earned autonomy. If the endpoint is down, the agent stops and alerts go to people.

Permissions live there too. The agent holds a grant for each investigation, the server checks every call against it, and the credentials stay in the layer. An analyst-invoked agent gets that analyst's scope. An alert-triggered one gets read-only access to the entities and time window in that alert. And since every call runs through one layer, the thousandth concurrent investigation runs under the same policy as the first.

The server's log becomes the record. It captures every request and response, and whatever runs the agent adds the model, prompt, and alert payload, so you can audit the old decision exactly. To test a new model, run it against the retained, time-fenced data.

Where the server runs matters too. A hosted endpoint gives you identity on every call, an audit trail, screening of tool calls and responses, and a policy for which servers are allowed at all. Google now runs its cloud services this way, with read-only tool permissions in IAM. On any platform, turn on data-access logging for tool calls, since it's often off by default, and go find the laptop configs, because a local server with a pasted key sits outside every cloud policy.

Screening will eventually miss a planted string, so the tags and the grant have to hold on the day it does. And whatever platform you run, give the agent its own identity holding only what its tools need. Most platforms support custom roles scoped to the API methods the tools call, and for an agent running on its own I'd make that the default.

If you run a vendor's agent, ask for the equivalents: an export of every tool call, a way to plug in your own MCP server, and one switch that revokes everything. Where a vendor declines, pull what exports exist into your own record and keep closures with a human.

Split the work between judgment, execution, and the record

I wrote about this shape in 2024 in Policy, SOPs, and AI Are All You Need. Humans set policy: what counts as a crown jewel, what needs approval, what risk the business accepts. The reasoning layer decides the verdict and the response. Tested playbooks execute. Everything gets written to the record.

Google describes its agentic automation, now in preview, the same way: AI agents that gather evidence and reason through alerts, combined with deterministic playbooks so analysts stay in control of high-impact actions. I think that's the right split. A perfect "disable account" playbook aimed at the wrong account is still a bad day, though, so the server checks that the target is an entity in this alert, and break-glass accounts and executives always go to a human.

I'd grant autonomy per action type, and make the agent earn each one with evidence, the way a new analyst earns access:

  • Enrichment and triage: the agent works alone from day one.
  • Closing false positives: the agent closes alone when the close tool's check passes. Measure misses against known true positives, because zero misses across 300 replayed alerts proves little when only three were real attacks.
  • Containing one workstation: the pre-approved policy cases run automatically, like isolating a non-executive laptop on a high-confidence ransomware detection. For everything else the agent proposes, a human approves, and "correct" means confirmed on later review. Zero bad calls in 300 still means the true failure rate could be as high as about 1%, at 95% confidence, so that's the number to show your CISO.
  • Identity systems, production infrastructure, customers: human, for a long time.

A lot of agentic SOC marketing implies you'll need fewer analysts. I think the analysts move up. Someone adjudicates the disagreements, keeps the #2 facts current, reviews the tagged closures, and owns the tool descriptions. That's senior work, and rotating Tier 1 through it is how juniors still learn to assemble a story.

What I'd do on Monday

  1. Replay a few hundred closed alerts plus known true positives, time-fenced, and adjudicate every disagreement.
  2. Pick one entity type, probably users, and label every fact #1, #2, or #3, with owners and expiries on the #2s.
  3. List every MCP server and credential your agent can reach, revoke the broad keys, and turn on MCP audit logging.
  4. Give SOC engineering a quarter to put one reviewed endpoint in front of the agent, with budgets and per-investigation grants.
  5. Move every response action into playbooks the agent picks from, with server-side checks on the arguments.
  6. Report five numbers monthly: disagreement rate, override rate, timeout rate, the share of verdicts resting on a #3, and the share of closures that still needed a human.

Sixty seconds is going to get a lot faster.

The security teams that get the most out of AI will be the ones who can power their AI tooling with context via MCP, open any verdict, see which facts it rested on and where each one came from, and replay the decision a year (or more) later. We won't be able to get any of these AI promises without being able to truly verify how decisions were made. Learn More

Sources