Skip to main content
This feature is useful when human confirmation is required before proceeding with automated investigation or remediation actions. For example, a security team may need to verify whether a user performed a suspicious activity. The playbook can automatically send an email to the user and pause until a response is received or the configured timeout period expires.

​
Purpose

The Email Response Checkpoint enables human-in-the-loop validation within automated playbooks.
Common use cases include:
  • Confirming suspicious login activity
  • Verifying phishing email interactions
  • Validating account actions with end users
  • Gathering user confirmation before remediation actions
  • Reducing false positives through direct user verification
When a playbook reaches a Wait for an Email Response checkpoint:
  1. AirMDR sends an email to the specified recipient.
  2. The playbook execution status changes to Waiting at Checkpoint.
  3. The playbook remains paused until:
    • The recipient replies to the email, or
    • The configured wait time expires.
  4. Once a response is received or the timeout is reached, the playbook automatically resumes execution.
  5. Subsequent playbook steps can use the recipient’s response to determine the next action.
The recipient receives an email requesting confirmation regarding a detected security event.The email contains:
  • A predefined security notification subject
  • A security-related message configured by the playbook creator
  • Instructions to reply directly to the email
  • No requirement to log in to AirMDR
Because recipients may not have access to the AirMDR platform, all interaction occurs through email replies.
Sample Mail

​
📖 Playbook Behavior

Example Descision Flow

​
Email Checkpoint Skill Behavior Scenarios

Important👤 Users must reply to the original email sent by AirMDR.

⚠️ Creating a new email or sending a response outside the original email thread will not resume the playbook execution.
1

Scenario 1: User Responds

If the recipient replies before the configured timeout:
  • The checkpoint is completed.
  • The playbook resumes execution.
  • The response body is captured as checkpoint output.
  • Subsequent steps can evaluate the response and take appropriate actions.
Example:
The playbook may classify the activity as benign and close the investigation.
2

Scenario 2: User Indicates Suspicious Activity

Example:
Reply Mail
The playbook can:
  • Create a malicious finding
  • Escalate the case
  • Trigger containment actions
  • Notify analysts
3

Scenario 3: No Response Received

If the recipient does not respond within the configured wait time:
  • The checkpoint timeout is reached.
  • The playbook automatically resumes.
  • The execution records that no response was received.
  • Subsequent playbook logic can mark the event as suspicious and escalate for analyst review.

​
Additional Information

When building a playbook, configure the following parameters:
After execution resumes, the checkpoint provides the following outputs:These outputs can be used in conditional branches to determine the next playbook action.
Phishing Investigation
  1. A phishing alert is generated.
  2. The playbook sends an email to the affected user.
  3. The playbook pauses and waits for a response for up to 1 hour.
Possible outcomes:
While waiting for a response, the playbook execution displays the following status:
This status indicates that execution is paused and awaiting either a user response or timeout expiration.
  • Keep questions simple and direct.
  • Ask questions that can be answered clearly.
  • Provide sufficient context for the recipient.
  • Configure reasonable timeout values based on business requirements.
  • Use conditional branching to handle positive, negative, and no-response scenarios.
  • Include user responses as evidence in findings whenever applicable.
  • Recipients do not require an AirMDR account.
  • Users interact solely through email replies.
  • Playbook execution automatically resumes after a response or timeout.
  • No manual intervention is required to restart execution.
  • The feature supports MSSP branding and can be customized for partner deployments.
  • 📧 Contact AirMDR Support through your designated support channel.
  • 🔄 Connect in AirMDR in case of any suspicious activity.