Amazon GuardDuty AI-powered investigations: a useful SOC copilot, not an autopilot
AWS just added a capability that many security teams have been trying to build around GuardDuty for years: a faster way to move from “there is a finding” to “this is probably what happened, here is the evidence, and these are the next actions.” The new feature is called GuardDuty Investigation, and it is now available in preview as AI-powered investigations for Amazon GuardDuty.
That wording matters. GuardDuty has already used machine learning and threat intelligence to detect suspicious behavior across AWS accounts, EC2, EKS, ECS, Lambda, S3, RDS, and other surfaces. This launch is not only about detecting another signal. It is about reducing the investigation tax that comes after the alert.
If you have operated cloud security at scale, you know the pattern: a finding appears, the analyst checks CloudTrail, IAM context, affected resources, related activity, known indicators, suppression rules, account ownership, and whether the finding is a real incident or just a noisy but expected behavior. That work is valuable, but it is also repetitive. It is exactly where a well-scoped AI assistant can help.
🔵 What changed
According to the AWS announcement, AI-powered investigations automatically analyze GuardDuty findings and AWS accounts to help distinguish true threats from benign findings. The investigation looks at finding context, related activity from the last 90 days, affected resources, and threat indicators. AWS says it uses knowledge graphs and threat intelligence to produce the analysis in minutes.
The GuardDuty Investigation documentation gives more detail on the output. Each investigation can produce:
- a risk level: Info, Low, Medium, High, or Critical;
- a confidence level: Unknown, Low, Medium, or High;
- a summary with key observations;
- investigation details with supporting context;
- recommended actions, including CLI commands;
- MITRE ATT&CK technique classification, using the common security knowledge base for attacker tactics and techniques.
That is a meaningful step beyond a plain alert. It gives the responder a starting hypothesis and evidence trail. The important part is not that the model “knows security.” The useful part is that GuardDuty already has the AWS-native context and can package that context into a structured investigation.
🔶 Three analysis modes
The preview supports three investigation scopes.
Finding analysis focuses on one GuardDuty finding. You provide a 32-character finding ID, and GuardDuty analyzes that specific signal. During preview, AWS says this supports all Extended Threat Detection findings and selected findings from foundational, S3, and Runtime plans.
Account analysis looks at the threat posture of one AWS account. This is useful when an account has multiple signals or when the first question is not “is this one finding real?” but “is this account behaving like it is under attack?”
Organization analysis lets an administrator analyze organization-wide posture, with a preview limit of up to 100 accounts. This is the most interesting mode for larger AWS environments because cloud incidents rarely respect account boundaries. A compromised principal, suspicious API activity, or lateral movement pattern may only make sense when viewed across accounts.
That said, the preview limits are real. The documentation states that, during preview, you can initiate up to 10 investigations per account per day, with a total limit of 100 investigations per account. The trigger prompt for API or CLI usage can be up to 2,048 characters. Failed investigations do not count against those quotas.
⚙️ How to enable it
You need an active GuardDuty detector in the Region where you want to create investigations, and the investigation feature must be enabled for that detector. In the console, AWS exposes this under Settings → AI powered investigations - Preview.
From the CLI, the docs show the feature name as AI_ANALYST:
aws guardduty update-detector \
--detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
--features '[{"Name":"AI_ANALYST","Status":"ENABLED"}]'
Your IAM identity also needs the investigation permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"guardduty:CreateInvestigation",
"guardduty:GetInvestigation",
"guardduty:ListInvestigations"
],
"Resource": "arn:aws:guardduty:us-west-2:123456789012:detector/2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7"
}
]
}
A basic investigation can be started with create-investigation:
aws guardduty create-investigation \
--detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
--trigger-prompt "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012"
The API is asynchronous. You get an InvestigationId, then retrieve the result with get-investigation once it completes.
🛡️ Where this helps in practice
The obvious use case is SOC triage. Instead of every finding starting as a blank page, the analyst receives a structured summary with risk, confidence, evidence, and recommended commands. That can cut the first 20–40 minutes of manual digging, especially for teams that already receive more alerts than they can deeply review.
The second use case is consistency. Different analysts may investigate the same GuardDuty finding differently. A standardized AI-generated package can help normalize the first response: what was checked, why the risk was assigned, which known attack technique may apply, and which resources need attention.
The third use case is managed security. If you operate AWS Organizations for many teams, account analysis and organization analysis are more interesting than single-finding analysis. They can help a central security team answer “which accounts deserve attention first?” instead of treating every alert as equal.
⚠️ What to be careful about
The preview documentation is explicit: investigation recommendations may contain errors or incomplete assessments, and human review is recommended. That is the right mental model. This feature should not auto-remediate production resources without a review gate.
There is also a data residency detail worth reading carefully. GuardDuty Investigation uses Cross-Region Inference Service. AWS says your data remains stored only in the Region where the investigation request originates, but investigation data and summary results may be processed outside that Region within the supported geography. For many organizations that is acceptable; for regulated environments, it needs review.
Availability is also limited to 10 commercial Regions in preview: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), and Asia Pacific (Tokyo).
🔍 What this means for security teams
This is the right direction for cloud security tooling. The value is not “AI replaces the analyst.” The value is that AWS has the telemetry, the resource graph, the threat intelligence, and the service context. If GuardDuty can assemble that into a defensible investigation package, analysts can spend less time collecting facts and more time making decisions.
I would not wire this directly to remediation on day one. I would start by enabling it in a controlled set of accounts, comparing its summaries against human investigations, measuring time saved, and building a review workflow around the recommendations. If the results are good, the next step is not full autopilot. It is faster triage, better evidence, and cleaner escalation.
Top comments (0)