AWS Launches Amazon GuardDuty Investigation Agent to Automate Threat Triage

AWS has recently made available the public preview of its Amazon GuardDuty investigation agent, a cutting-edge AI-powered security tool designed to streamline threat triage and reduce the time spent on security investigations. The tool evaluates findings, correlates historical activity, and maps threat telemetry across AWS accounts and organizations, providing a comprehensive view of potential threats.

The company’s goal is to minimize the manual overhead required for security teams to investigate alerts by synthesizing metadata from security findings, 90-day activity logs, and affected resource topologies into structured analysis reports. This capability was first announced in June as part of AI-powered investigations, with a detailed walkthrough published under the investigation agent name in July.

Threat detection services like Amazon GuardDuty continuously stream alerts regarding suspicious network or runtime behavior. However, security teams often struggle with alert fatigue and the manual overhead required to correlate findings across fragmented accounts and logs. Clarke Rodgers, who works in the Office of the CISO at AWS, framed the product thesis directly on LinkedIn: ‘Security teams don’t have a detection problem. They have an investigation problem.’

The GuardDuty investigation agent addresses this bottleneck by evaluating telemetry on demand across three distinct scopes: Finding Analysis, Account Analysis, and Organization Analysis. Each scope provides a structured result set containing an overall risk rating (ranging from Info to Critical), a confidence score, classification against the MITRE ATT&CK matrix, and actionable CLI remediation steps.

Finding Analysis evaluates a specific 32-character GuardDuty finding ID during preview, supporting all Extended Threat Detection findings as well as select foundational, S3, and Runtime findings. Account Analysis assesses the current threat posture of an individual 12-digit AWS account, while Organization Analysis evaluates threat findings across up to 100 member accounts in an AWS Organization.

Sena Yakut, a cloud security architect and AWS Security Hero, drew the distinction between the agent and GuardDuty’s existing correlation capability. She noted that Extended Threat Detection connects related findings into an attack sequence, whereas Investigation analyzes affected resources, IAM activity, and surrounding context to generate a summary with recommended next steps.

Yakut sees the strongest fit for this tool in organizations without a large security function, where initial evidence-gathering consumes a disproportionate share of analyst time. She tested it against sample findings, which returned low risk ratings on test resources as expected. Her caveat is that AI should assist investigation, not replace human validation and decision-making before taking remediation actions.

Programmatically, developers and SecOps teams can trigger investigations using standard AWS SDKs, the AWS CLI via aws guardduty create-investigation, or via EventBridge rules to automate downstream response pipelines. This integration allows for automated threat triage, streamlining the process of identifying potential threats and reducing manual overhead.

The MCP integration is a key detail for teams already running agentic tooling. Through the AWS MCP Server, an engineer can trigger a threat investigation from Claude Desktop or a custom CLI agent runner using existing AWS Identity and Access Management (IAM) credentials. This places security investigation inside the same agent surface as code and infrastructure work.

The integration also inherits governance questions such as which principal actually ran the investigation, whether the agent’s context window now holds 90 days of correlated security telemetry, and how that transcript is retained. AWS’s own Loom reference platform exists precisely to answer these types of questions for agent deployments.

To address data residency and compliance concerns associated with Large Language Models (LLMs), AWS leverages its Cross-Region Inference Service (CRIS) powered by underlying Bedrock models. While compute inference might route to another region within the same geographic boundary to optimize resource availability, investigation data and generated reports remain stored within the originating home region.

The launch puts GuardDuty in a category entered first by other hyperscalers such as Microsoft’s Security Copilot for incident summarization and guided response across Defender and Sentinel. Google offers Gemini-assisted investigation inside Security Operations. What distinguishes the GuardDuty agent is its scope, which is bounded to GuardDuty’s own finding corpus and surrounding AWS telemetry rather than positioned as a general security assistant.

The GuardDuty investigation agent is currently available in public preview across 10 commercial AWS regions: US East (N. Virginia, Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt, Ireland, London, Paris, Stockholm), and Asia Pacific (Tokyo). Usage is free during the preview period, subject to a throttle limit of 10 investigations per account per day, capped at a cumulative maximum of 100 per account during the preview phase. Failed investigations do not count toward either quota.

The limits on usage sit awkwardly beside the EventBridge integration. Ten investigations per account per day, capped at 100 for the whole preview, is a budget for manual triage rather than automated response pipelines. This constraint aligns with Yakut’s caveat that the preview is scoped for analysts evaluating output, not systems acting on it.

The GuardDuty investigation agent marks a significant step forward in automating threat triage and reducing the time spent on security investigations. By streamlining the process of identifying potential threats and providing actionable remediation steps, this tool has the potential to greatly improve the efficiency and effectiveness of security teams.