The problem: device-code phishing is “legit login” abuse—and it breaks naive automations
OAuth device code flow phishing has been escalating since September 2025, with users tricked into entering a code on the real Microsoft device login page—handing attackers tokens without “classic” credential theft. (microsoft.com)
For IT Ops, the hard part isn’t just detection—it’s safe response:
- You want to revoke sessions, disable risky sign-in methods, and open/route incidents fast.
- But you don’t want an AI agent (or a rushed runbook) to lock out execs, break meeting-room devices, or mass-disable legitimate apps.
This is a great fit for governed orchestration: deterministic steps, approvals, and auditable execution—while still moving at incident speed.
End-to-end workflow (Autom Mate): “Device-code phishing response with guardrails”
Trigger → validation → approvals → deterministic execution → logging → exception handling/rollback
1) Trigger
Pick one:
- **m your SIEM/IdP alert (recommended). Autom Mate supports webhook-driven orchestration patterns.
- ITSM trigger (e.g., an Jira Service Management) using the Jira Service Management library.
2) Validation (don’t let “AI confidence” become production change)
- Parse alert payload and extract: user, tenant, client app, IP, geo, timestamp, correlation IDs.
- Enrich with a REST/HTTP API action to pull additional context (e.g., user risk, sign-in details, device compliance) from your identity platform/SIEMorts REST/SOAP API integrations and logs API calls.
- Apply deterministic rules:
- Is the user in a protected group (execs, break-glass, service accounts)?
- Is the sign-in from a known location/device?
- Is the client app category one that legitimately uses device code (meeting rooms, constrained devices)?
3) Approvals (human-in-the-loop for high-blast-radius actions)
Route an approval to SecOps / IAM on actions like:
- “Disable device code flow org-wide”
- “Revoke sessions for VIP user”
- “Block sign-in / force password reset”
If you’re using an Autom Mate AI agent to summarize the incident, run it in Supervised Mode so it proposes actions but pauses for appn, with steps visible in logs.
4) Deterministic execution (no improvisation)
Execute only the approved playbook branch:
- ITSM updates: create/update incident, add notes, attach evidence.
- If you use ServiceDesk Plus library actions (e.g., add note/notification), keee ticket.
- If you use Jira Service Management library, create/transition issues and keep respondersty containment** via REST/HTTP actions (since specific Entra actions aren’t confirmed in the provided library snippets):
- revoke refresh tokens / sessions
- disable specific auth flows (scoped)
- add temporary blocks (conditional access change request)
5) Logging & audit trail
- Store the full decision record: trigger payload, enrichment results, approver identity, approved actions, API responses.
- Autom Mate provides execution visibility and logs (including for supervised agent steps).
6) Exception handling / rollback
- If an API call fails or the run gets stuck, use Autom Mate’s retry/self-healing for webhook-triggered operations.
- Rollback pattern:
- If a policy changeo last-known-good configuration (stored as a JSON snapshot in your workflow variables / data store).
- If a user was blocked incorrectly, auto-create a “restore access” change task requiring approval.
Two mini examples
Mini example 1: “Fast containment, no lockout”
- Trigger: SIEM flags suspected device-code phishing for a standard user.
- Autom Mate: enriches context via REST calls, opens a P1 in Jira Service Management (library), requests SecOps approval, then revokes sessions (REST) and posts the outcome back to the ticket with timestamps and API responses.
Mini example 2: “VIP user + meeting room exception”
- Trigger: alert hits for an exec account, but the client app matches a known meeting-room pattern.
- Autom Mate: routes to a higher approval threshold, proposes a scoped action (revoke sessions + targeted block) instead of org-wide device-code disable, and logs the rationale in supervised mode for audit.
Why this belongs in Platform (Category 13)
This isn’t “just block device code flow.” It’s aboatterns**:
- deterministic orchestration over ad-hoc scripts
- approvals for high-blast-radius identity changes
- auditable, replayable incident response
- safe use of AI (summarize/propose) without letting AI directly execute risky changes
Discussion questions
- Where do you draw the line for mandatory approval in identity incident response (VIPs only, or any policy change)?
- Do you prefer ticket-first (ITSM creates the source of truth) or alert-first (SIEM webhook triggers, then ITSM is updated) for identity attacks like device-code phishing?