How agentic AI simplifies GuardDuty incident response playbook execution

Incident response in AWS often starts with a playbook. AWS publishes reference playbooks, step-by-step guides based on the NIST Computer Security Incident Handling Guide (Special Publication 800-61 Revision 2) that security teams can use to respond to alerts detected by GuardDuty. These playbooks are written to cover common threat categories, such as anomalous IAM user behavior, and guide analysts through the evidence to gather, verification steps, and documentation of their investigation.

The IAM Anomalous Behavior playbook, for example, instructs responders to:

• Identify the impacted resources
• Check the nature of the impact
• Determine if the anomalous API call was successful
• Investigate the Actor
• Correlate identity
• Engage the resource owner or custodian

Each of these steps is critical, but together, they are also painstakingly manual. The analyst must switch between GuardDuty findings, CloudTrail logs, the AWS IAM console, and sometimes even external identity providers like Entra ID or Okta to piece together the full story. The first step of “acquire, preserve, and document evidence” can take hours, especially in complex environments where corporate identity and AWS sessions don’t align neatly.

Why it’s harder than it looks

Take a concrete example. Let’s say GuardDuty flags that an IAM role was used to call APIs outside of its usual pattern. The playbook says to check the “Anomalous APIs” section of the finding, see if those calls were successful or returned an error, and then figure out who actually assumed the role. That means digging into CloudTrail, correlating session IDs, tracing the assumed role back to its origin, and then checking the corresponding identity in your IdP. If your enterprise uses Okta, that often means looking up sign-in logs, comparing IP addresses, and verifying whether the same user authenticated around the same time. Multiply this across different logs and consoles, and the process becomes a bottleneck for every incident.

And that’s just one finding. In theory, for any detection that one expects to see more than once a month, there should be a documented playbook that Level 1 analysts can use to triage and investigate. But building those playbooks takes significant engineering hours, and is nearly impossible to fully automate with existing tooling. Each IaaS or SaaS service generates dozens of recurring alerts, meaning that a mature organization would need hundreds of playbooks to cover the basics. For most SOCs, the scale and effort required simply exceeds their capacity, leaving gaps in consistency, repeatability, and investigation quality.

How Exaforce automates evidence gathering

When an alert is generated, Exaforce’s Exabot agents immediately begin a structured investigation, pulling data across GuardDuty, CloudTrail, IAM, and even external tools such as IdPs like Okta or Entra ID and EDR tools like CrowdStrike and SentinelOne. To make this concrete, let’s break down the process into three core phases: Identity correlation, Actor analysis, and Resource & action validation.

Identity correlation across AWS and IdP

One of the hardest steps in the IAM Anomalous Behavior playbook is mapping the AWS principal back to a real user. Exaforce automates this by collecting the full session tree, including the principal reported in the GuardDuty finding, the role it assumed, and the origin identity that triggered the session. It cross-references CloudTrail session IDs with IdP sign-in events, verifying whether the root session is tied back to a login in Okta or Entra ID. Exaforce then builds an identity chain that shows, in plain English, this Okta user logged in at 9:01 AM, assumed this AWS role at 9:02 AM, and triggered these anomalous API calls at 9:03 AM.

This correlation is notoriously time-consuming to do by hand. Analysts often have to search through CloudTrail logs, pull session details, and then compare timestamps with Okta or Entra ID logs. Exaforce does this instantly, collapsing hours of log stitching into a single identity.

Actor analysis and context enrichment

Next, Exaforce examines the actor behind the session. It determines whether the activity was performed from a corporate IP address or an unexpected location. It verifies if the principal has previously authenticated in this geography. It also checks whether the source IP is associated with a bad reputation according to threat feeds. Exaforce answers these automatically, enriching GuardDuty’s raw “Actor” field with contextual intelligence.

It also looks laterally to gather whether there were other logins for the same principal around the same time and if there were other identities active from the same IP. Normally, answering these questions requires pivoting between GuardDuty, CloudTrail, and your IdP’s audit logs. Exaforce unifies them into a set of structured Q&A results that let analysts see not just what happened, but whether the circumstances make sense in the broader context of enterprise identity activity.

If necessary, Exaforce will reach out to the user and their manager to validate the activity, aligning with the “Contact the person associated with the principal” section of this playbook.

Resource and action validation

Exaforce digs into what was actually impacted. It maps the GuardDuty “Anomalous APIs” back to the affected resources and validates whether those calls succeeded. If an S3 bucket was touched, Exaforce identifies which keys were modified, whether the principal has accessed that bucket before, and whether any unusual data movement occurred. If EC2 was involved, Exaforce looks for recent logins to the instance and correlates them to the same session.

Instead of simply stating that “an anomalous API call occurred,” Exaforce produces an audit-ready evidence package.

Bring it all together

Exabots automatically link actors, sessions, resources, and actions into a single view, enriched with historical context from past alerts and investigations. Instead of analysts scrambling to remember “what happened last time” or manually cross-referencing old tickets, Exabots weave that history directly into the current analysis.

From there, Exaforce produces a clear disposition of either False Positive or Needs Investigation. Each conclusion comes with the supporting evidence and recommended next steps, giving analysts a decision-ready package instead of a raw pile of logs. What would normally take hours of log stitching and institutional knowledge is collapsed into minutes, freeing teams to focus on action rather than assembly.

Further analysis and investigation

If the packaged results raise new questions, analysts can switch into copilot mode within the Command Center. Here, they can ask free-form, natural-language questions, and Exabots will query across configurations, CloudTrail, IdPs, and more to deliver precise, context-rich answers.

This interactive mode extends the playbook beyond its static steps, giving analysts the ability to explore leads, pivot investigations, and validate hypotheses on demand. Exaforce brings all of this information into a single console instead of wading through multiple consoles and raw logs.

Accelerating the first steps to set up for success

Going back to the playbook’s Part 1, Exaforce eliminates the most time-consuming barrier. Instead of manually collating logs, Exaforce provides a pre-built evidence package, including all related events, the principal identity chain, actor location analysis, resource impacts, and related misconfigurations or threat findings. The analyst doesn’t just get raw data, but a synthesized summary and even a conclusion on whether the alert is likely a false positive.

In our example, what might have been a half-day of evidence gathering and identity correlation becomes minutes. The SOC can quickly validate whether the activity was authorized and, if needed, move to containment and remediation much faster.

From manual to AI-driven

AWS playbooks are valuable templates for defining best practices and providing a clear checklist for response. But in high-volume environments, manual execution isn’t sustainable. For any detection that recurs even monthly, an organization should ideally have a corresponding playbook. Yet across IaaS and SaaS environments, this quickly translates into hundreds of playbooks that are costly to develop and nearly impossible to maintain. The effort required is beyond the capabilities of most SOCs.

Exaforce bridges this gap. Its threat findings are automatically decorated with the most relevant playbook questions and answers, evidence that would otherwise take hours of manual correlation. This represents a massive cost savings for any organization serious about detection, triage, and investigation. Instead of spending precious cycles authoring and updating playbooks, SOCs can operationalize consistent, repeatable investigations with Exabots doing the heavy lifting.

That’s how Exaforce transforms GuardDuty alerts from a manual slog into an accelerated, automated process. The result is faster MTTI and MTTC, reduced analyst fatigue, and stronger assurance that nothing is missed, even when identity and cloud data are spread across multiple systems.