Mitigant

Clean up a previously launched attack, restoring the cloud resources it changed back to their pre-attack state. Clean-up is normally AUTOMATIC after a short, deliberate inspection window (so the team can verify the attack and collect evidence first); calling this kicks it off immediately rather than waiting out that window. It is NOT a fix for a stall, and it ends that window early -- removing the attack's artifacts before the team may have finished inspecting them -- so only use it when the user explicitly wants the account restored now. This triggers clean-up and returns immediately -- clean-up runs in the background, so a success here means the request was accepted, not that clean-up is done. Confirm the account is actually restored by polling get_attack_status until cleanup.cleanUpComplete is true; do not tell the user it is restored based on this call alone.

Full description, impact, MITRE mapping, and orchestration type (PROVISIONED or INLINE -- PROVISIONED attacks create and destroy their own target rather than targeting your existing infrastructure (they may still read or use existing resources along the way), so they're the lower-risk, production-viable choice; INLINE attacks find and attack an existing resource in the account) for one attack, by the action key from list_attacks. Result includes attackName (show this to the user) alongside the attackType you passed in (an opaque id, not for display).

Get the evidence Mitigant collected for a previously launched attack -- what the account's own logging (CloudTrail, GuardDuty) recorded about it. Returns an 'evidence' summary (counts, sources, and a plain-language statement) plus the raw records, each with an evidenceUrl that opens the matching console entry. Use it to show the user what their defenses saw, especially during the clean-up inspection window. Important: an empty or pending result shortly after an attack is normal -- logging delivery lags by minutes, and evidence usually appears within a few minutes -- and an attack whose purpose is to disable logging is expected to leave none, so never report an empty result as the attack leaving no trace; re-check about every minute or two, for up to 30 minutes after the attack, and not more often. An attack whose outcome is NOT_EXECUTED or FAIL changed nothing, so no evidence will ever exist for it; an attack still running has none yet. Read evidence.statement and relay it.

Find the managed attacks that demonstrate a named threat actor's real techniques, for one cloud service -- e.g. 'which Azure attacks demonstrate Scattered Spider', or to plan a red team exercise around one actor's known behavior. Get the actor's exact name from list_threat_actors first. Each result includes the same fields as list_attacks, plus matchedThreatActorTechniques: exactly which of that attack's own technique id(s) this actor is cited for (never that attack's full technique list, since one attack can implement several techniques and only some may belong to this actor). An actor with no mapped technique yet returns an empty list, not an error.

Get the current report for a previously launched attack, including its clean-up state. Returns the attack report plus a 'cleanup' summary with cleanUpComplete and a plain-language statement. Only tell the user the account is back to its pre-attack state when cleanup.cleanUpComplete is true -- while anything is pending or failed, clean-up is not done, so report it as in progress and check again rather than implying all-clear. A pending clean-up is usually the DELIBERATE inspection window, not a stall: read cleanup.statement and relay it, and poll no faster than that -- a few minutes -- rather than reporting a fault. Each report summary carries 'outcome' (SUCCESS, FAIL, NOT_EXECUTED, CANCELED, IN_PROGRESS) and, when there is one, 'reason': key on those, never on the free-text 'status'. NOT_EXECUTED / FAIL means the step changed nothing, so there is nothing to clean up. While attackStatus or any outcome is IN_PROGRESS, or there are no summaries yet, the attack is still running (attacks that wait for a person, e.g. device code, take minutes): poll again and do not conclude anything.

Check this account's context before planning or launching: whether it is a Mitigant DEMO account and what that allows. Call this first on a new connection. If isDemo is true, every attack or scenario with allowedOnDemo=false WILL be rejected at launch -- treat those as not runnable and don't attempt them; use list_attacks' allowedOnDemo field (or list_scenarios demo_only:true) to pick ones that run. Returns no account/org identity, just the demo status, what you can do, and how to upgrade.

Full details for one attack scenario -- description, impact, and the step-by-step composition, by the scenario key from list_scenarios. A scenario runs several attacks in sequence; this returns every step, not just the first. Result includes scenarioName (show this to the user) alongside the scenarioKey you passed in (an opaque id, not for display).

Run an attack against a cloud account connected to Mitigant. Returns the result if it finishes within wait_seconds (default 20); otherwise it returns at once with the attackId and status RUNNING while the attack keeps running -- then poll get_attack_status with that attackId, and never launch it again (that would start a second attack). This performs real actions on real cloud infrastructure -- it is not a simulation. Confirm with the user before calling: if their request could match more than one attack in list_attacks (similar names, or an underspecified description like "the security group attack"), show them the matching candidates with their names and descriptions and have them pick one -- don't guess which attack they meant. Some attacks need a person to act during the run (e.g. Azure device code flow abuse and other phishing-style attacks wait for someone to enter a code and sign in): tell the user that before launching, expect several minutes of runtime with no result yet, and know that outcome NOT_EXECUTED is the normal result when nobody completes that step -- report it as "did not run" with its reason, not as a fault or a no-op.

Run a multi-step attack chain against a cloud account connected to Mitigant. Returns the result if every step finishes within wait_seconds (default 20); a multi-step scenario usually takes longer, so expect it to return at once with the attackId and status RUNNING while it keeps running -- then poll get_attack_status with that attackId, and never launch it again (that would start a second scenario). This performs real actions on real cloud infrastructure, as several attacks in sequence -- it is not a simulation, and its blast radius is the combined blast radius of every step. Confirm with the user before calling: if their request could match more than one scenario in list_scenarios, show them the matching candidates with their names and descriptions and have them pick one -- don't guess which scenario they meant.

Browse Mitigant's attack actions -- atomic tests that each emulate one attacker technique -- that you can launch on their own against AWS, Azure or GCP. Currently 111 attack actions (AWS 49, Azure 36, GCP 26). Returns each action's attackName (show this to the user) and attackType (an opaque id -- pass this, not attackName, to get_attack_details or launch_attack), what it does, its impact, the MITRE ATT&CK technique it maps to, and its orchestration type (PROVISIONED or INLINE -- see orchestration_filter for what these mean). Optionally filter by cloud service (S3, IAM, ...), category, or orchestration type. Some attack actions run only as steps inside a scenario and appear via list_scenarios / get_scenario_details, not here. Start here to find an attack action to run.

List the cloud accounts available for attack emulation -- any account not listed here cannot be attacked, so check this before guessing an account_no for launch_attack. An empty result means no accounts are onboarded for attack emulation (for that cloud, or at all), not a failure -- the account may still exist in Mitigant for other purposes (e.g. posture scanning) without being eligible here. Each result's accountNo is already the value launch_attack expects; accountName is for display to the user. defaultRegion is the region attacks against that account run in by default (and where their evidence is collected); it can be overridden per attack request, but unless you do, actions target that region. State it when telling the user where an attack will run.

List your own recent attack and scenario runs for a cloud account, most recent first, each with its attackId and status. Use this to recover an attackId you no longer have -- for example when a launch_attack / launch_scenario call's connection dropped before it returned, or to check whether a long-running scenario is still running or has failed -- then pass the attackId to get_attack_status, get_attack_evidence or clean_up_attack. Shows only your own runs, not other users' activity on the account.

List Mitigant's attack scenarios -- multi-step chains that combine several attack actions run in sequence, so treat a scenario as having the combined blast radius of every step. Currently 45 scenarios (AWS 26, Azure 12, GCP 7). Returns each scenario's scenarioName (show this to the user) and scenarioKey (an opaque id -- pass this, not scenarioName, to get_scenario_details or launch_scenario), plus description, impact, and the step-by-step composition (each attack action's name, service, MITRE mapping, and impact). Use this to find a multi-step chain to run; use list_attacks instead for a single attack action.

List every real-world threat actor Mitigant's catalog tracks (name, description, references). Not scoped to a cloud service. Use this to find an actor's exact name (e.g. 'Storm-0940', 'Scattered Spider') before calling get_attacks_by_threat_actor, or to summarize what an actor is known for directly from its description. An actor can legitimately have no attacks mapped yet -- the report documenting it never cited a specific MITRE ATT&CK technique id, so nothing is attributed to it rather than guessed.