How to build compromised account response

What matters here

• Ask the user first. Most risky sign-ins are travel or a new phone, and one message settles them.
• Cut off every way in at once: sessions, tokens and sign-in methods, in every app the account reaches.
• A password reset alone leaves open sessions working. Revoke them explicitly.
• Look for what the attacker left: forwarding rules, new sign-in methods, app grants and new API tokens.
• Accounts with admin power go to a person before anything is cut off, with the evidence attached.

Who this is for

You run security operations or identity. Risky sign-in alerts arrive every day, most are harmless, and the real ones need minutes, not a ticket queue.

How it works in practice

From a risky sign-in alert to the account being safe again.

1. 1

   A risky sign-in raises an alert

   Impossible travel, a new country, a sign-in method change or a burst of failed attempts.

2. 2

   The account's context is attached

   Who they are, what they can reach, whether they have admin power, and what changed on the account this week.

3. 3

   The user is asked whether it was them

   In Slack, on a channel the attacker can't reach, with the time and place of the sign-in.

4. 4

   A confirmed takeover is contained

   Every session and token revoked, sign-in methods reset, and the password changed, in every app the account reaches.

5. 5

   What the attacker left is found and removed

   Mail forwarding rules, new sign-in methods, app grants and tokens created during the window.

6. 6

   One case records it all

   What was seen, what was cut off, what was removed, and who approved each step.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then attach the account's context

   Whether to act depends on what the account can reach.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Okta or Azure Active
   Directory, Office365 Management, Google Workspace, Datadog or
   Splunk for the alerts, Slack, Jira and Snowflake, or whatever we run in
   those seats. Before you plan anything, tell me which of them are
   already authenticated in the workspace, because I do not want a
   connector stubbed that I have not authenticated.
   
   On every risky sign-in alert, attach: the person, their department and
   manager, whether they are a leaver, which apps the account signs into,
   whether it holds admin power anywhere, and every change to the account
   in the last seven days, including new sign-in methods.

2. 2

   Ask the user, on a channel the attacker can't use

   Most risky sign-ins are travel or a new phone.

   Headless skills build-workflow

   Copy

   Use build-workflow. Message the user in Slack with the sign-in time,
   location and device, and two buttons: "This was me" and "Not me".
   
   If they say it was them, close the alert and record the answer. If
   they say it was not, or don't answer within 15 minutes for a high
   risk alert, start containment.
   
   Never ask by email. If the mailbox is the thing that has been taken,
   the attacker is the one who answers.

3. 3

   Revoke every way in, at once

   A password reset leaves open sessions working.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then on a confirmed takeover, in this order:
   
     Revoke every session in the identity provider
     Revoke sessions and tokens in each app the account signs into
     Reset sign-in methods, removing any added in the last seven days
     Force a password change at next sign-in
     Tell the user, and their manager, what happened and what to do next
   
   Run the revocations together, not one app at a time over an afternoon.
   For an account with admin power anywhere, stop before the first step
   and ask the on-call analyst to approve in Slack, with the evidence.

   Order matters. Revoking sessions before resetting sign-in methods stops the attacker from signing straight back in with the method they added.

4. 4

   Find and remove what was left behind

   A forwarding rule outlives every reset.

   Copy

   For the window between the first suspicious sign-in and containment,
   look for:
   
     Mail forwarding or delete rules created
     New sign-in methods or recovery details
     Apps granted access to the account
     API tokens or app passwords created
     Files shared outside the company
   
   List each finding on the case and remove it after an analyst confirms.
   Some of them, such as a forwarding rule to a personal address, are
   real changes the user made, which is why a person confirms.

5. 5

   Record it, and measure time to revoke

   The record is what an incident review and an auditor ask for.

   Copy

   Keep one Jira case per account: the alert, the user's answer, every
   action with its time and approver, and everything removed.
   
   Report: alerts, share settled by the user, confirmed takeovers, time
   from confirmation to every session revoked, and anything found in
   cleanup. Time to revoke is the number to drive down.

6. 6

   Validate it, then hand the rules to security ops

   Because what counts as high risk is a security decision.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it for a fortnight asking users and building
   cases, with revocation done by an analyst pressing a button, before any
   of it runs on its own.
   
   Then open the same workflow in Tray Build so security operations can
   change the risk rules, the answer timeout and which accounts need an
   approver, in the visual canvas.

What it connects to

The sign-in happened in one place, and the attacker's access reaches every app the account does.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides