Use after exploitability is demonstrated to prepare and persist a narrow supplier intake ingress policy, its compatibility analysis, rollback conditions, and the human decision required to apply it.
Use when a vulnerability finding needs fresh evidence of impact at the exposed supplier intake ingress, or when a completed control needs an attack and benign-traffic retest.
Use when a case involves API Gateway abuse, API key exposure, API authentication or authorizer weakness, WAF/API alerts, abnormal API invocation volume, scraping, injection through API endpoints, BOLA/IDOR, or API-layer data exfiltration.
Use when a case involves compromised AWS credentials, leaked or exposed IAM access keys, suspicious STS use, unauthorized IAM activity, GuardDuty IAM findings, unusual AWS API calls, or attacker persistence through IAM users, roles, policies, or access keys.
Use when a case involves unintended S3 access, public bucket or object exposure, permissive bucket policy or ACL changes, S3 GuardDuty/Macie findings, bulk object access, or data exposure through compromised credentials.
Use when the task is to create a new incident-response skill or playbook from scratch rather than triage a BOTSv3 case — no existing source playbook, and the user wants a structured interview or quick-mode draft for a new incident type.
Use when converting an existing human-readable incident-response playbook into an AI-usable skill — playbook authoring and transformation work, not direct BOTSv3 case closure.
Use when a case involves ransomware indicators, ransom notes, encrypted files or objects, volume or object lockout, destructive encryption behavior, mass deletion, extortion, or compromise paths that could lead to ransomware impact.