Amazon’s GuardDuty Investigation Agent Turns AI Threat Triage Into a Supervised Workflow

On July 20, 2026, Amazon Web Services published a detailed walkthrough of the GuardDuty investigation agent, an on-demand AI capability that can dig through a single security finding, an entire account, or an organization of up to 100 accounts, and hand back a structured threat assessment in minutes instead of the hours a human analyst would normally spend correlating logs by hand. The underlying capability, an AI_ANALYST feature on the GuardDuty detector, has been running in public preview since AWS first announced it in a June 23 “What’s New” post. The July 20 AWS Security Blog post is the company’s own deep dive on how to actually put it to work through the console, CLI, API, and now Model Context Protocol (MCP) clients.

What stands out is not that AWS built an AI agent to triage security alerts, but how deliberately boxed in AWS has kept this one: hard daily and lifetime usage caps, a narrow set of IAM permissions, an access model that walls member accounts off from each other, and a blunt line in AWS’s own documentation warning that a human still has to check the machine’s work.

What the Investigation Agent Actually Does

GuardDuty is AWS’s threat detection service. It continuously watches accounts, workloads, and data for signs of compromise and surfaces the results as “findings.” Historically, turning a raw finding into a confident verdict, and then into a remediation plan, has meant an analyst pulling together CloudTrail events, VPC flow logs, and threat intelligence by hand. The investigation agent is built to do that correlation automatically once someone, or something, asks it to.

You trigger an investigation one of three ways, and GuardDuty determines which from the plain-language “trigger prompt” you provide:

• Finding analysis: name a specific 32-character finding ID, for example "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012", and the agent digs into that one finding. During preview this covers all Extended Threat Detection (XTD) findings plus select findings from the foundational, S3, and Runtime plans.
• Account analysis: give it a 12-digit account ID, such as "Analyze findings in account with id 123456789012", and it assesses that account’s overall threat posture.
• Organization analysis: ask it to "Analyze findings in my organization" and, during preview, it evaluates up to 100 accounts across the organization at once.

Whichever scope you pick, the agent pulls in the finding’s context, up to 90 days of related activity, affected resources, and threat intelligence, and runs it through a knowledge graph rather than a flat keyword search. Every completed investigation returns five things: a risk level (Info, Low, Medium, High, or Critical), a confidence score (Unknown, Low, Medium, or High), a plain-language summary, supporting investigation details, and recommended actions that include ready-to-run AWS CLI commands. Each investigation also maps the observed behavior to specific MITRE ATT&CK techniques, giving analysts a standard vocabulary to slot the result into an existing incident response process instead of a bespoke one.

Cross-Region Inference, Not Cross-Region Storage

Investigations run on what AWS calls Cross-Region Inference Service (CRIS), which automatically routes the AI processing to whichever region within your geography has the most available compute and model capacity. Your underlying GuardDuty data stays stored only in the region where you started the investigation; the inference workload itself, encrypted in transit, is what can hop to a neighboring region to get processed faster. A GuardDuty detector in Europe (Ireland), for instance, can have its investigation processed in Frankfurt, Stockholm, Milan, Spain, London, or Paris depending on capacity, while the underlying findings never leave Ireland.

During preview, GuardDuty Investigation is available in only 10 commercial AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt, Ireland, London, Paris, Stockholm), and Asia Pacific (Tokyo). Internally, AWS labels the resulting output as coming from a product called “Amazon GuardDuty AI Analyst,” currently at version 1.0.0, a naming choice that treats the agent as a distinct, versioned product rather than a simple feature flag.

Wiring the Agent Into an Existing Security Workflow

Turning the capability on is a detector-level setting, not an account-wide switch. In the console, it lives under GuardDuty’s Settings page, in a section labeled “AI powered investigations,” currently marked Preview. From the CLI, the same toggle is a call to update-detector with the AI_ANALYST feature flag: aws guardduty update-detector --detector-id <detector-id> --features '[{"Name": "AI_ANALYST", "Status": "ENABLED"}]'.

Once enabled, three IAM actions govern who can use it: guardduty:CreateInvestigation, guardduty:GetInvestigation, and guardduty:ListInvestigations. AWS’s access model then splits sharply along administrator and member lines. Administrator accounts can create and view investigations for themselves and every member account underneath them. Member accounts can only view investigations of their own findings; they cannot launch a new investigation or see anything belonging to another account, including the administrator’s. That is a narrower blast radius than a lot of “AI agent” rollouts get, and it means a compromised member account cannot use the investigation agent to go snooping across the rest of the organization.

AWS’s own example of wiring this into a real pipeline is an EventBridge rule paired with a Lambda function: the function calls CreateInvestigation with a finding’s ID as soon as GuardDuty emits it, waits for the investigation to finish, and forwards the enriched result (risk level, confidence score, MITRE ATT&CK mapping, and recommended actions) into a SIEM alongside the original finding. That turns the agent from a tool an analyst opens by hand into a standing enrichment step ahead of triage.

The agent is also reachable through the Model Context Protocol, the open standard for connecting AI assistants to external tools and data that Anthropic introduced in 2024. Because AWS’s own MCP server implements that standard for AWS services, AWS says you can use it to “add GuardDuty investigations into AI-powered workflows using tools like Kiro, Anthropic’s Claude, or other MCP-compatible clients,” letting an analyst ask a chat-based assistant to kick off a GuardDuty investigation in natural language rather than typing a CLI command.

The Guardrails Are the Real Story

The technical capability is genuinely useful, but the limits AWS built around it during preview say as much about how AWS wants this treated as the feature itself does. Every account is capped at 10 investigations per day and 100 total during the preview window; failed investigations do not count against either limit, and a trigger prompt sent through the API or CLI cannot exceed 2,048 characters. Completion times vary by scope in a way that is easy to misread: AWS’s own figures put account-level investigations at 2 to 5 minutes but finding-level investigations at 10 to 12 minutes, meaning a narrower, single-finding request currently takes longer to resolve than a full account sweep.

Most tellingly, AWS’s documentation attaches a direct warning to the feature: “AI-generated analysis and recommendations may contain errors or incomplete assessments. Human review is recommended.” That line sits next to the investigation results themselves, not tucked away in a terms-of-service page.

Why This Matters

GuardDuty’s investigation agent reflects a broader caution in how security vendors are deploying AI agents this year: automate the tedious correlation work, but stop short of letting the agent act unsupervised. The scoped IAM permissions, the administrator-versus-member wall, the preview quotas, and the standing human-review disclaimer are not accidental friction: they are the product decisions that make an AI analyst something a security team can actually adopt without giving up control of its own incident response process.

The open questions are what happens as this moves toward general availability: whether the daily quotas loosen once AWS trusts the model’s accuracy at scale, whether the region list grows beyond the current 10, and whether the human-review line survives GA or quietly fades once liability calculations shift. Those decisions will say a lot about how much autonomy AWS is ultimately willing to hand this agent.