When the SOC Analyst Is an Agent

I kept building agents that act. AWS built one that investigates.

For a while now I’ve been building agents that do things: file records, edit notes, draft and post. When I wrote about the agent security stack nobody is building [4], the whole argument was defensive: an agent that acts is an attack surface, and it needs a layer around it that most people haven’t built yet.

GuardDuty’s new AI-powered investigation feature (currently in preview) [1] is the interesting inversion of that. It’s not an agent that needs securing; it’s an agent whose job is the security work. And looking at how it draws the loop taught me more about “good agentic design” than most of the acting agents I’ve built.

What it actually does

Here’s the part I verified against the docs rather than the launch blog, because product claims deserve that. When you kick off a GuardDuty investigation on a finding, the agent [2]:

• Examines the finding’s context plus related activity from the last 90 days, the affected resources, and threat indicators, using knowledge graphs and threat intelligence.
• Produces a threat disposition: a risk level (Info → Critical), a confidence score (Unknown → High), a plain-language summary, and supporting evidence.
• Classifies techniques against MITRE ATT&CK.
• Returns recommended actions, including the CLI commands to suppress, contain, or remediate.

It runs across an individual account or a whole AWS Organization, and you reach it from the console, the CLI/API, or the AWS MCP Server, which means it plugs straight into the same MCP-mediated workflows a lot of us already drive from an AI coding tool. As of this writing it’s a preview in ten regions (Frankfurt, Ireland, London, Paris, Stockholm, and Tokyo are on the list, alongside four US regions). Treat the specifics as preview-dated — check the docs for the current state.

(Worth keeping distinct: AWS Security Incident Response has a separate agentic-investigation capability aimed at support cases. Same philosophy, different front door. This post is about GuardDuty’s.)

The redrawn loop is the real story

The lazy way to describe this is “it automates SOC tier-1 triage.” True, but it misses the point.

Look at where the boundary lands. The agent does the part humans are bad at and hate: pulling 90 days of scattered activity together, cross-referencing threat intel, building a timeline, and mapping it to a framework, at 3am, consistently, without fatigue. Then it stops and hands you a disposition with a confidence score attached and a recommended action you have to choose to run.

That’s the loop I keep arguing for: the machine collapses the tedious correlation, the human keeps the judgment. The confidence score is the tell. It reports its own uncertainty instead of hiding it: “here’s what I found and how sure I am; your call.” A benign-looking finding that’s actually an intrusion, or a scary-looking finding that’s just a misconfigured backup job: those distinctions still route through a person, but now the person starts from a built case instead of a blank query console.

Alert fatigue is a real security problem, and it’s less a volume problem than a cold-start problem. Every alert makes an analyst start from nothing. An agent that hands you a warm, evidenced starting point changes the economics of paying attention. The catch is that a warm start is only a gift if the analyst still reads it critically; a team that treats every disposition as gospel will slowly stop building the correlation instinct the agent is doing for them.

What I’d watch before trusting it

Honest caveats, because this is a preview and because “AI does the investigation” is exactly the kind of claim that should make a security person suspicious:

• Confidence is not correctness. A high-confidence wrong disposition is more dangerous than an obviously-incomplete one, because it invites you to stop thinking. The MTTR win is real; the temptation to rubber-stamp is the risk.
• Recommended CLI commands are still commands. “It gave me the remediation” is not “I should paste the remediation.” The human-keeps-the-call design only holds if the human actually reads what they’re about to run.
• Read-only by construction is a good sign. The related Security IR agent gathers evidence through a read-only service role and logs every access to CloudTrail [3]. That auditability (being able to see exactly what the investigating agent looked at) is the thing that makes an autonomous investigator trustworthy. Confirm the same for whatever you enable.

If you’re running this on AWS

For a small footprint, turning on the GuardDuty investigation preview in a non-production account and running it against a handful of real findings is a low-risk way to see whether the dispositions match what your team would have concluded — a calibration exercise before you trust it in the loop. Because it’s reachable via the AWS MCP Server, you can also drive investigations from an MCP-capable assistant rather than the console, which is where this starts to feel less like a feature and more like a teammate. (I plan to wire exactly this into a test account and report what the dispositions get right and wrong — a follow-up build note.)

The broader pattern is bigger than security. We spent two years asking “how much can the agent do?” The better-designed systems are quietly asking “which half of the loop should the agent own, and which half do we keep?” GuardDuty’s answer, own the correlation and hand back the judgment, is a good template.

Where would you draw that line in your own security workflow — how much investigation are you comfortable handing to an agent before the disposition has to come back to a human?

Sources

• [1] Amazon GuardDuty AI-powered investigations accelerate threat response (Preview) — AWS What’s New — the announcement.
• [2] GuardDuty Investigation (Preview) — AWS documentation — the verified capability detail (risk/confidence/MITRE/recommended actions, 90-day window, regions).
• [3] AWS Security Incident Response — AI investigative agent — the distinct, complementary agent (read-only service role, CloudTrail-audited).
• [4] The Agent Security Stack Nobody Is Building — my prior argument that acting agents need a security layer.

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• AgenticAI
• Security
• AWS