Before
Responders had to coordinate identity controls across separate systems, decide whether to preview or apply the response, and manually reconstruct the actions taken. They also had to record the plan or results separately in the service-management ticket and security incident.
How it works
- Read the containment request and build an action plan for the identified user and linked incidents.
- Route shadow requests to documentation only, or execute live identity controls and update any linked security incident.
- Validate the action responses and record the planned or completed containment details in the relevant incident records.
Workflow details
- Request intake: The flow reads the containment request, including the user's principal name, incident references, requested mode, reason, and decision owner, then builds a proposed action plan.
- Safe preview path: When the request is not explicitly set to live mode, the flow does not change the account. It records the planned suspension, session and token invalidation, sign-in-session revocation, and any linked security-incident update.
- Live containment: In live mode, the flow locates the user, suspends the identity, clears its active sessions and OAuth tokens, and revokes sign-in sessions. If a linked security incident is provided, it is marked active, confirmed as a true positive, and classified as a compromised account.
- Result validation: The workflow evaluates the response from each containment action and creates a consolidated result showing whether each action completed or failed.
- Incident documentation: The plan or execution result is written as a private follow-up in the service-management ticket and as a comment on the security incident, while the final response distinguishes simulated from executed containment and preserves any human follow-up needed.
What changed
Containment is now selected by the request mode, with shadow mode documenting what would happen and live mode applying the controls automatically. Action validation and incident documentation happen as part of the same workflow, while human follow-up such as disabling an AD account, forcing a password change, or contacting the manager remains outside the automation.
Work removed
Manually looking up the user, suspending the account, clearing sessions and OAuth tokens, revoking sign-in sessions, updating a linked security incident, checking each action result, and copying the plan or outcome into the service-management ticket and incident comment.
Expected outcome
Each live request can remove at least three recurring identity-containment actions from the responder's workload, with an additional linked-incident update when applicable; shadow requests provide a documented preview without changing the account.
