IT playbook · AI Employee: Ivy

Lost Device → Remote Lock

Lock issued within 5 minutes of report

Install this playbookBack to marketplace
The problem

A laptop is missing. Reported at 6pm on a Friday. The device holds an active SSO session, cached credentials, potentially unencrypted files. Every hour until it's locked is an hour that data is exposed. IT support isn't available till Monday. The employee doesn't know what to do. This is where a small process failure becomes a real security incident.

At a glance
Trigger
Chat + form
Approvals
Immediate on report; audit-only
What it does
Writes to your systems
Systems
Jamf · Intune · MDM
How it feels in production

An hour-by-hour walkthrough.

6:14pm Friday. Priya messages Ivy: "I think I left my laptop on the train." 6:14pm + 20 sec. Ivy verifies Priya's identity via step-up MFA (her phone works fine — laptop was what's missing). Locates the device in Jamf — assigned to Priya, last check-in 90 minutes ago. Issues immediate remote-lock via Jamf API. Confirms lock status. 6:15pm. Priya gets confirmation: "Device locked. Active sessions killed. If found, only the FileVault recovery key can unlock. If not returned in 72 hours, it'll auto-wipe." 6:15pm + 30 sec. Ivy opens an incident ticket in the security queue (this is a real security event, not an IT ticket): device serial, last-known location (via MDM), files accessed in past 24 hours (if audit is enabled), automatic offer of a loaner device via the RMA workflow. Security-on-call gets paged. If Priya finds the laptop under her seat Monday morning, she reports back, Ivy verifies (identity check + device unlock confirmation), and cancels the wipe timer. If Monday comes and no laptop, the wipe fires and the RMA replacement ships.
How it works

Step by step.

  1. 01

    Verify identity of caller

    Read requester identity from Slack / Teams SSO. Step-up MFA on requester's registered phone (not the missing laptop). Verify device ownership in Context Graph.

    Slack · Okta · Context Graph
  2. 02

    Locate device

    Look up device serial in Jamf / Intune / Kandji. Retrieve last check-in location if MDM has geolocation enabled. Confirm device is still in the requester's assignment.

    Jamf · Intune · Kandji
  3. 03

    Issue remote lock

    MDM API call to lock the device immediately. Active SSO sessions invalidated. Screen locked with a message including recovery contact info for a would-be Good Samaritan.

    Jamf · Intune · Kandji · Okta
  4. 04

    Confirm status + open incident

    Confirm lock succeeded. Open security incident ticket with device metadata + timeline. Page security on-call for after-hours reports. Automatically offer loaner device via RMA.

    Slack · Security queue · RMA workflow
  5. 05

    Follow-up (recovery or wipe)

    72-hour countdown until auto-wipe. If device is recovered, requester confirms, Ivy cancels the wipe with a re-verification. If not, wipe fires, RMA replacement ships, and audit closes the incident.

    MDM · Slack · RMA workflow
Systems and wiring

What you connect to make this run.

Jamf Pro · Intune · Kandji

read+write

MDM API credential with lock + wipe + geolocation scopes. Lock is immediate; wipe is time-gated with human override.

Okta · Microsoft Entra ID

write

Session-invalidation on the device. Even if the finder cracks the OS lock, SSO won't renew — attacker gets nothing durable.

Security queue (PagerDuty · Incident.io)

write

After-hours reports page security on-call. Weekday reports create ticket + notify security via Slack. Every report is treated as a potential incident until resolved.

RMA workflow

write

Automatic loaner-device offer + replacement RMA. Prevents "lost laptop delays productivity for a week" pattern.

What changes

Before and after, honestly.

Time from report to device locked
Before
1-24 hours (dependent on IT availability)
After
Under 90 seconds, 24/7
Recovery-code delivery to a real Good Samaritan
Before
Days, if ever
After
Contact info on lock screen enables immediate return
SSO session exposure post-report
Before
Sessions may remain live for hours
After
Sessions invalidated within seconds of lock
Time to loaner device
Before
3-5 business days across IT ticket + shipping
After
Loaner offered within minutes; delivery in 1-2 days
Related

Playbooks that pair with this one.

IT

Device Recovery / Unlock

The inverse — user has device but can't get in.

IT

RMA & Repair

The replacement path when the device doesn't come back.

Security

Compromised Credential Response

Fires if any credentials were exposed on the device.

Security

Anomalous Login

Watches for login attempts on the locked device or accounts.

Frequently asked

Answers about this playbook.

What if the device is BYO (personal-owned, MDM-enrolled)?

Same flow with BYO-appropriate limitations. Ivy can lock and wipe the corporate profile; the personal side of the device is untouched. Employee retains their personal data + apps.

How does this handle a rushed "actually I found it" report?

Unlock requires identity re-verification. Requester DMs Ivy, Ivy re-verifies via step-up MFA, cancels the wipe countdown, delivers the FileVault recovery key. Full audit trail of every lock and unlock.

What about compliance reporting?

Every lost-device report generates a compliance record: device metadata, incident timeline, resolution (recovered / wiped / replaced), any data exposure. Ready for SOC 2 / ISO 27001 evidence.

Can the device geolocation be used to actually find the device?

For "lost on the train" cases: unlikely to help unless MDM ping happens while the device is on. For "stolen" cases: geolocation data included in the police report (some MDMs support 'lost mode' with periodic geolocation ping to a covert URL).

What if the report is fraudulent (someone else reporting)?

Identity verification is designed to catch this. The requester must be the device's assigned owner in Context Graph and pass step-up MFA. If either fails, Ivy declines and escalates the mismatched request to security for review.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore IT playbooks