Lost developer Mac response: revoke access safely

A missing developer Mac is a credential incident first and a hardware incident second. The laptop may come back untouched. It may also be unlocked, offline, or in someone else's hands while its browser sessions, SSH material, cloud CLI cache, local repositories, and agent processes still carry authority.

The worst response is to wait for certainty. You will rarely get it. Start with reversible containment, preserve evidence before noisy changes erase context, then rotate the credentials that could let an intruder widen access. A calm sequence beats frantic password changes across every service.

Treat the disappearance as active access until containment proves otherwise

Assume the missing Mac can make authenticated requests until you have stopped the paths that matter. This assumption does not accuse anyone or predict a breach. It prevents the familiar mistake of treating a device recovery ticket as if it were an access-control event.

Write down four times immediately: when the Mac was last physically seen, when it was last known locked, when its user last performed sensitive work, and when the loss was reported. Those times define the review window. Do not let recollection drift for hours while people search meeting rooms.

Record what was open at the last known safe time. The useful details are specific: a terminal connected to a production host, an agent run editing deployment code, a browser tab in a cloud console, a local port forward, a repository with credentials in its history, or a password manager unlocked for a migration. "Working on the backend" tells the responder almost nothing.

Classify the situation before assigning work:

• The machine was locked and lost in a controlled office.
• The machine was unlocked or its lock state is unknown.
• The machine disappeared in public transit, a hotel, or another uncontrolled place.
• The machine had active production access or an autonomous agent process.
• The machine belonged to an administrator, release engineer, or owner of an organization account.

A locked machine with disk encryption and a hardware-protected secret store is a better situation than an unlocked one. It is not a reason to skip revocation. Device protection limits extraction from storage. It cannot rewind actions made while the device was unlocked, invalidate remote sessions, or tell you whether somebody used the machine before it locked.

Tell one incident owner to make decisions and one recorder to maintain the timeline. On a small team, that may be the same person. The recorder should log the account, credential class, action taken, time, operator, and evidence location. A spreadsheet is acceptable during the first hour. A chat thread with reaction emoji is not an incident record.

Do not use the missing Mac's last network address as proof that it is safe. Network location can be stale, proxied, or shared. Do not call, message, or alert a suspected finder through accounts that may be open on the machine. Use a separate channel.

Contain the device without destroying the investigation

Remote lock and remote erase are sensible actions, but they are only one branch of containment. Issue them through your device-management service or the operating system's device-finding service as soon as the reporting facts support it. Record the request time and any delivery confirmation.

A remote command waits for the device to reach the service. If the Mac is offline, the command may remain pending. If someone can keep it offline, it may not execute for a long time. That is why credential revocation cannot wait for a wipe confirmation.

Ask the device administrator to collect available management records before they change retention or disappear behind a later wipe. Useful fields include the device serial or inventory ID, assigned user, last check-in time, operating system version, last reported IP address, FileVault escrow status if your organization records it, and the state of the remote lock or erase request. Collect what your tooling provides; do not invent a clean story from absent fields.

If the missing Mac used a personal Apple Account, the owner should handle device finding with an incident lead present. The team should not ask them to disclose personal account credentials. The organization needs confirmation that a lock or erase request was submitted, not access to unrelated personal data.

Preserve the local work context from other systems. Disable the device's VPN or zero-trust device posture if your provider allows a device-specific block. Revoke its certificate if it has one. Remove it from endpoint-management groups that grant network access. Disable remote desktop and device-sync privileges associated with that endpoint.

This is also the point to suspend unattended work tied to the machine. A scheduled local job cannot run after a powered-off laptop, but a remote agent, cloud development environment, CI runner, or browser automation started from it may continue independently. Identify the execution location before assuming the missing Mac controls it.

Avoid the popular but weak recommendation to "just change the user's main password." People like it because it is quick and visible. It may help, particularly if the password could have been observed, but it often leaves personal access tokens, OAuth grants, SSH keys, browser sessions, CLI refresh tokens, and service-specific credentials alive. Password reset is one task in a wider containment plan.

Revoke live agent authority before it makes another call

A coding agent with access to external actions deserves the same urgency as an interactive terminal. It can still call an API or open SSH if its process is live, its session remains authorized, and the machine can reach the network. Stop the agent's authority at the gateway and at every remote service that accepted its credentials.

First identify each run that could have originated from the missing Mac. Capture its process identity, session start and end time, assigned credentials, target systems, and the last completed action. If your agent host uses a session list, revoke the affected sessions rather than waiting for them to expire. If you cannot distinguish the missing machine's runs, revoke all sessions for that user and create new ones later.

Sallyport's Sessions journal can revoke an agent run immediately, while its Activity journal records the individual calls made through the app. Use both records during a device-loss response: one tells you which run to cut off, and the other tells you what that run attempted before you did.

Do not confuse an agent name with a trustworthy identity. "Claude Code" in a process label or terminal title does not establish which executable ran, who signed it, or whether an attacker launched a copied process. A proper approval record should identify the code-signing authority of the calling process. Record that identity alongside the session, then compare it with the known-good development setup.

A gateway can block future calls, but it cannot retract a request that already reached an API. If an agent created a deployment token, added a user, changed a repository setting, or uploaded data, investigate that service directly. The agent journal gives you a lead. The destination service remains the authority on whether the action succeeded.

For agents that connect through an MCP server, revoke or disable the connection path on the affected workstation identity. Then inspect the agent configuration stored in source repositories, shell profiles, project directories, and managed configuration. Do not restore that configuration onto a replacement Mac until you have removed old tokens, reviewed command hooks, and checked whether it points at personal or production accounts.

Per-call approval has a specific benefit here. It forces a human decision at the moment of credential use, which can reduce harm after a user walks away. It does not replace revocation after a laptop goes missing. An approval already granted to a running session may remain valid for that process, and any external token used earlier may be copied or have its own lifetime.

Rotate credentials in the order an attacker would abuse them

Credential rotation is an ordered exercise in removing paths to privilege escalation. Rotate the credentials that can create more access before you rotate credentials that merely read a low-risk development service. If you reverse that order, you can spend an hour resetting minor tokens while a cloud administrator token remains usable.

Start with identity and control-plane access: identity provider sessions, organization owner accounts, cloud administrator roles, secrets-manager access, source-control organization administration, deployment-control accounts, and device-management administration. If one person owns all of these, that is an architectural problem to fix after containment, but solve the immediate incident first.

Then rotate access that can move code or execute workloads: CI credentials, package registry publishing tokens, signing credentials, deployment keys, cloud workload tokens, container registry tokens, and SSH keys used by bastions or production hosts. Finally handle issue trackers, documentation tools, lower-privilege API tokens, and individual service passwords.

Use this worksheet for every credential. It prevents the common failure where someone rotates a secret but misses the systems that still trust it.

Do not rotate by overwriting a secret and hoping. Revoke the old item when the provider supports separate revocation. Create the replacement with the narrowest scope that keeps the intended workflow alive. Update the authorized consumers. Then validate that the old credential fails. Capture the credential identifier and time, never the secret value, in the incident record.

For a bearer token, validation might be a harmless authenticated endpoint that should reject the old token and accept the replacement. For SSH, remove the old public key from every authorized path, then test a connection with that key and expect denial. For an OAuth grant, revoke the grant in the identity provider and check the application's active sessions or token list.

A command-line test can make this explicit. Substitute a safe endpoint that returns the authenticated principal and run it only from a clean machine:

curl -i -H "Authorization: Bearer $OLD_TOKEN" https://api.example.internal/whoami

The expected shape after revocation is an authentication failure, such as HTTP/1.1 401 Unauthorized or the provider's documented invalid-token response. A 200 response means the old token still works. Do not accept "we changed it in the secret manager" as proof, because the remote service may still accept the old credential.

SSH deserves extra suspicion. Developers often remember ~/.ssh/id_ed25519 and forget deploy keys, hardware-backed keys, SSH certificates, forwarded agents, keys registered with source-control providers, keys stored in CI, and public keys copied to bastions. Search the access-control side, not merely the lost disk. Every place that accepts the public key must stop accepting it.

Check activity before and after the loss window

Audit review should answer whether access occurred, what authority it used, what changed, and whether that change created a new route back in. Reading logs only for obvious destructive commands misses the preparation work attackers do first.

Set the review window from the last known safe time through the moment every high-authority credential was revoked. Extend it backward if the device showed unexplained activity before the loss. Extend it forward while old sessions or credentials remain active. Keep timestamps in one time zone in the incident record.

Review identity-provider events first. Look for successful and failed sign-ins, new MFA methods, recovery changes, OAuth consent, new application grants, session creation, unusual device registrations, and administrator role changes. A failed sign-in is not harmless if it appears among successful refreshes or a new session from the same context.

Then inspect cloud and infrastructure audit trails for the actions that create persistence: new access keys, service principals, API tokens, role assignments, policy changes, firewall changes, compute instance creation, secret reads, snapshot exports, and audit-log configuration changes. A token that only has read permission can still expose enough configuration to locate a more powerful credential.

Source-control records deserve the same care. Check deploy-key additions, personal access token events, SSH key changes, branch-protection edits, webhooks, repository transfers, application installations, release publishing, package publishing, and workflow file changes. A modified CI workflow can grant a future run more access than the stolen Mac ever had.

For SSH destinations, review authentication logs, command logs if you collect them, shell histories only as supporting evidence, privileged command records, and new entries in authorized_keys. A successful key login after the reported loss time requires explanation even if the source address looks familiar. Corporate VPN egress can make many people appear to come from the same address.

Sallyport keeps a write-blind encrypted, hash-chained audit log behind its journals. On a clean Mac, preserve the available audit material and run the offline integrity check before treating its entries as evidence:

sp audit verify

A successful verification should report that the chain verifies; a failure means you must preserve the affected files, record the error, and investigate why verification failed. The command verifies the chain over ciphertext and does not need the vault key. It verifies that the recorded sequence has not been altered, not that every remote action succeeded.

Build a short event table rather than pasting raw logs into a chat channel. Include timestamp, actor or credential ID, source, action, target, result, evidence reference, and disposition. Mark events as expected, suspicious, confirmed harmful, or unresolved. The unresolved column matters. Teams often close incidents because they found one benign explanation while several account changes remain unexamined.

Hunt for persistence, not only theft

An intruder who can use a developer machine may prefer a quiet way back over an immediate production change. Look for new credentials, altered automation, and control changes that survive a password reset.

Inspect each control plane for recently created access: new users, API tokens, OAuth applications, SSH public keys, deploy keys, service accounts, personal access tokens, recovery methods, device enrollments, and delegated administrative roles. Compare against a baseline if you have one. If you do not, ask the service owner to validate each recent entry manually rather than declaring the list normal.

Search code changes for modified CI definitions, build scripts, package publish settings, dependency URLs, webhook endpoints, and secret references. A malicious workflow often hides in a small pull request or a configuration change that looks like routine maintenance. Review merged changes and open branches created during the review window.

Also inspect data movement. Check artifact downloads, repository clones where your provider logs them, exports from customer systems, object-storage listing and retrieval events, and newly shared documents. You may not get perfect visibility, especially for a local clone made before the incident. State that limitation plainly in the record instead of assuming no export occurred.

Do not overreact to every anomaly. A deploy made at an odd time may have an approved ticket. Verify it with the person or automation account that made it, using a communication channel unrelated to the missing laptop. Do not send a confirmation prompt to an account whose session may be exposed and accept its reply as proof.

If you find persistence, scope outward. A new SSH key on a bastion means inspect every host reachable through it. A new source-control application means inspect its granted repositories and the workflows that use its token. A new cloud role means inspect its role assignments and activity. Remove the persistence first, preserve evidence, then rotate every credential it could have read.

Restore access from a clean endpoint, not from a backup image

A replacement Mac should receive new authority deliberately. Restoring a full backup can restore old tokens, SSH keys, browser cookies, agent configuration, shell hooks, and unknown files along with source code. That convenience is expensive during an active investigation.

Enroll the new Mac in normal device management, apply operating-system updates, enable disk encryption and screen lock, and install approved development tools from trusted sources. Restore source code from remote repositories after you review account access. Recreate local settings from version-controlled, reviewed configuration where possible.

Use a separate account or browser profile for administrative work during the response. Keep daily development access narrower. This separation reduces the damage when a development environment eventually runs an untrusted extension, package script, or agent instruction.

Reissue SSH credentials for the new device. Prefer an organization-managed SSH certificate or a distinct key per machine when your infrastructure supports it. A shared private key moved from laptop to laptop turns every device loss into a broad migration. Public-key naming conventions that identify the machine and owner make future removal faster.

Create fresh API tokens only when a tool truly needs them. Give a build system its own credential rather than copying a developer token into CI. Set expiration where the service supports it. Document who owns the token and where it is consumed. A secret that nobody can attribute will become an incident problem later.

Restore agent access last. Confirm which executable will connect, which code-signing authority it presents, what channels it may use, and which credentials it can request. Start with read-only or development credentials when possible. Watch the first actions rather than granting a wide approval because the team is behind schedule.

Do not put credentials into agent prompts, configuration text, issue comments, or shell commands that will land in history. An action gateway should hold the secret and inject it only when it performs the request. That boundary keeps the agent from receiving plaintext credentials, but it does not excuse careless authorization of the actions themselves.

Close the incident only after old paths demonstrably fail

You can close a missing-Mac incident when the lost endpoint no longer has a usable route to meaningful access, the review window has been investigated, and the replacement setup does not recreate the old exposure. Finding the physical Mac is not enough. A recovered device may still require re-enrollment or erasure if custody was uncertain.

Check each line in the credential worksheet. Every high-authority credential needs a recorded revocation or rotation result. Every active agent session tied to the device needs a termination result. Every suspicious event needs an explanation, remediation, or a documented decision to accept residual risk.

Run negative tests from a controlled environment for the access paths you removed. Confirm disabled VPN access rejects the old device identity. Confirm revoked SSH keys fail. Confirm old API tokens fail. Confirm former organization sessions cannot reach administrative pages if the provider supports session inspection. These tests catch the awkward cases where an old credential remained valid in a secondary region, a forgotten bastion, or a separate identity tenant.

Write a short post-incident note while the details are fresh. Include the timeline, impact, credentials affected, evidence reviewed, actions taken, open uncertainties, and changes you will make. Skip blame. If the response depended on one person remembering where a token lived, the process needs inventory and ownership, not a lecture.

The practical test is simple: if someone powered on the missing Mac tomorrow, which actions could it still take? Keep working until the truthful answer is limited to none that matter. That standard is stricter than a remote-wipe receipt, and it is the one that protects your systems.