Mitigant

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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "description": "Which cloud provider's attack catalog to list"
    },
    "service_filter": {
      "type": "string",
      "description": "Optional: only show attacks targeting this cloud service/resource type. Valid values are per cloud_service and not interchangeable (e.g. AWS object storage is 'S3', GCP's is 'CLOUDSTORAGE', Azure's is 'STORAGE') -- if unsure, call this tool without a filter first and inspect the 'service' field on the results, or just drop the filter: an unfiltered list is cheap and filtering client-side is always correct. Omit the field entirely rather than passing an empty string."
    },
    "category_filter": {
      "type": "string",
      "description": "Optional: only show attacks in this category. Category names vary by cloud_service and the set is not fixed, so do NOT guess one -- a guessed category simply returns an empty list. Call this tool without a filter first, read the 'categories' field on the results, then filter client-side; an unfiltered list is cheap and always correct. Omit the field entirely rather than passing an empty string."
    },
    "orchestration_filter": {
      "type": "string",
      "description": "Optional: PROVISIONED attacks create their own target resources, attack them, and delete them -- they do not target your existing infrastructure (they may still read or use existing resources along the way), so they're the lower-risk choice and usable in production. INLINE attacks find and attack an existing resource in the account. Filter to PROVISIONED for a lower-risk attack to run. Omit the field entirely rather than passing an empty string."
    }
  },
  "required": [
    "cloud_service"
  ],
  "additionalProperties": false
}

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).

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ]
    },
    "action_key": {
      "type": "string",
      "description": "The attack's attackType value (an opaque id, e.g. IAM_CREATE_USER -- not attackName) from list_attacks"
    }
  },
  "required": [
    "cloud_service",
    "action_key"
  ],
  "additionalProperties": false
}

Run an attack against a cloud account connected to Mitigant and return the result once it finishes. 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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ]
    },
    "account_no": {
      "type": "string",
      "description": "Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID"
    },
    "action_key": {
      "type": "string",
      "description": "The attack's attackType value to launch (an opaque id, not attackName) -- from list_attacks or get_attack_details"
    },
    "region": {
      "type": "string",
      "description": "Optional: the region to run the attack in (e.g. us-east-1, eu-west-3). Omit to use the account's default region (the defaultRegion from list_cloud_accounts); passing a region here does not change the account's default for other users. Evidence is collected in whichever region the attack runs in."
    }
  },
  "required": [
    "cloud_service",
    "account_no",
    "action_key"
  ],
  "additionalProperties": false
}

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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "description": "Optional: only list accounts for this cloud provider (AWS, AZURE, or GCP). Omit the field entirely to list accounts across all three; an empty string is tolerated and treated the same as omitting."
    }
  },
  "additionalProperties": false
}

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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "description": "Which cloud provider's scenario catalog to list"
    }
  },
  "required": [
    "cloud_service"
  ],
  "additionalProperties": false
}

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).

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ]
    },
    "scenario_key": {
      "type": "string",
      "description": "The scenario's key (an opaque id) from list_scenarios"
    }
  },
  "required": [
    "cloud_service",
    "scenario_key"
  ],
  "additionalProperties": false
}

Run a multi-step attack chain against a cloud account connected to Mitigant and return the result once every step finishes. 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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ]
    },
    "account_no": {
      "type": "string",
      "description": "Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID"
    },
    "scenario_key": {
      "type": "string",
      "description": "The scenario's key to launch (an opaque id) -- from list_scenarios or get_scenario_details"
    },
    "region": {
      "type": "string",
      "description": "Optional: the region to run the scenario in (e.g. us-east-1, eu-west-3). Omit to use the account's default region (the defaultRegion from list_cloud_accounts); passing a region here does not change the account's default for other users."
    }
  },
  "required": [
    "cloud_service",
    "account_no",
    "scenario_key"
  ],
  "additionalProperties": false
}

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.

{
  "type": "object",
  "properties": {
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    }
  },
  "required": [
    "attack_id"
  ],
  "additionalProperties": false
}

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.

{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ]
    },
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    }
  },
  "required": [
    "cloud_service",
    "attack_id"
  ],
  "additionalProperties": false
}

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. Read evidence.statement and relay it.

{
  "type": "object",
  "properties": {
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    }
  },
  "required": [
    "attack_id"
  ],
  "additionalProperties": false
}