Does your Touch ID access review cover agent approvals?

A fingerprint enrollment change is an access change. Treat it with the same seriousness you would give a new administrator account, a transferred laptop, or a recovered device, because it changes who can satisfy a biometric approval prompt at the moment an agent wants to act.

That statement sounds obvious until a deployment is waiting, someone says they only added their spouse's finger so they can unlock the laptop, and the team remembers that the same machine can approve use of production credentials. I have seen teams build careful controls around an agent, then leave the physical computer holding the approval button outside their access process. The weak point is rarely cryptography. It is usually a reasonable shortcut that nobody recorded.

This runbook covers added and removed fingerprints, a change in Mac ownership, and biometric lockout. It assumes that an AI agent can make HTTP requests or SSH connections only after a person authorizes the action path. Adjust the names of local roles and escalation contacts for your team, but do not soften the decision points. If you cannot establish who controls the Mac, do not let that Mac approve consequential actions.

A fingerprint change alters the approval boundary

An added fingerprint can authorize a person to cross the same biometric boundary as the prior owner, so the owner must review it before the machine approves another agent action. The issue is not whether the new fingerprint belongs to a trusted family member, teammate, or IT technician. The issue is whether that person now has a practical way to approve activity tied to credentials they do not administer.

Apple's Touch ID guidance explains that fingerprints enroll on the device and that macOS can ask for a password after certain events instead of accepting Touch ID. That fallback is useful, but it does not turn an enrollment change into a harmless preference. The Mac still needs a password-bearing account with enough authority to manage enrollment, and physical possession still matters.

Run this review whenever someone adds or removes a fingerprint, whether the change happened intentionally or during support work. The person responsible for the Mac should complete it before using any agent that can reach shared infrastructure.

1. Identify the current device owner and the local account that controls Touch ID enrollment. Write down the owner, not a team alias.
2. Open the Mac's Touch ID settings with the owner present. Compare the enrolled fingerprints with the expected users. Ask why each one exists.
3. Confirm which local accounts can unlock the Mac, administer it, and change device settings. A fingerprint review without an account review misses half the route to approval.
4. End any agent runs that were active before the change. Do not carry an earlier authorization decision across a changed approval boundary.
5. Review credentials that the agent can invoke from this Mac. Put the highest-consequence credentials behind a fresh human confirmation until the review is complete.

The awkward case is the support technician. A technician may need a password and physical access to repair a machine, but that does not automatically grant a standing right to approve its agent actions. If support enrollment is unavoidable, remove the fingerprint as part of the repair closeout and record that it happened. A ticket that says "fixed Touch ID" is not a record of who could approve production access during the repair.

Do not ask people to swear that they will not touch the prompt. Build the process around the fact that shared physical access changes risk. People make mistakes when a confirmation looks routine, especially when an agent is moving quickly and the request resembles work they perform every day.

Per-call approval needs a named human decision

Per-call approval is safe only when the person approving can recognize the action, the credential, and the consequence at the time of the prompt. Touch ID can prove that an enrolled person interacted with the Mac. It cannot prove that the right person understood a request an agent made thirty seconds earlier.

That distinction gets blurred constantly. A biometric prompt is often described as an identity check, then used as if it were an authorization review. They are related, but they answer different questions. Identity asks whether an enrolled user touched the sensor. Authorization asks whether that user should permit this call now. A team that confuses them will approve a destructive request with the confidence of a login screen.

Write the approval rule in ordinary language. For example: "Any call that can change a production deployment, create a long-lived token, alter billing, or send data outside the organization requires the current service owner to inspect and approve it." That rule identifies the human judgment. It does not pretend the fingerprint alone made the decision.

The approval prompt also needs useful context. Before accepting it, the reviewer should be able to answer these questions without reconstructing the agent's private reasoning:

• Which agent process made the call?
• Which credential will the call use?
• What destination will receive the request or SSH command?
• What operation will happen if the call succeeds?
• Why is this person, on this Mac, allowed to approve it?

If your prompt cannot answer those questions, fix the workflow before widening access. A generic request that says an agent needs permission creates approval theater. People click it because they are blocked from doing useful work, not because they made an informed decision.

Sallyport makes this separation explicit: a locked vault denies every action, session authorization covers one agent process until it exits, and a credential can require approval on each use. That fixed sequence is easier to review than an improvised set of exceptions, provided the team still treats the biometric confirmation as a human decision rather than a magic stamp.

For everyday, low-consequence calls, per-session approval can be reasonable. It keeps the human in charge of a run without forcing them to confirm every harmless read. Use per-call approval where a single call can create a lasting change or expose material data. Do not mark every credential this way just to sound strict. Excess prompts train people to approve blindly, then the prompt that matters arrives wearing the same clothes as the rest.

Ownership transfers require a custody break

When a Mac changes hands, the old owner must lose the ability to approve actions before the new owner uses it. A handoff is not complete when the laptop reaches another desk, nor when a device-management inventory changes. It is complete when the machine's local access, enrolled biometrics, vault access, active sessions, and credentials match the new custody arrangement.

The fastest safe approach is a clean reprovisioning. For a company-owned Mac, erase and set it up for the new owner through the organization's normal management process. That removes the need to reason about old local accounts, forgotten fingerprints, browser sessions, cached tokens, and development tools that survived the transfer. Reprovisioning takes time, but forensic guessing after a bad transfer takes longer.

Sometimes a clean rebuild is impossible because the machine carries local development state that has not yet moved. Then use a temporary transfer procedure and set an end date. Do not let "we will clean it up later" become the permanent state of a production-capable Mac.

A temporary transfer should follow this order:

1. The old owner signs out of services, locks the vault, and stops every agent run. Export only the development material the new owner needs through an approved path.
2. An administrator removes the old owner's local account or disables it according to company policy. Confirm that the old owner cannot log in after a restart.
3. The new owner enrolls their own local account and fingerprint. Check the enrollment list while both the administrator and new owner are present.
4. Recreate access deliberately. Do not copy credentials, SSH private keys, browser profiles, or local secret files from the old account because copying preserves access you may not notice.
5. Review the activity record after the new owner performs the first approved agent call. Confirm that the process, destination, and credential match the new owner's work.

Mac ownership and credential ownership are separate. A contractor may temporarily hold the machine while an employee remains the service owner. In that case, the contractor should not become an approving party merely because they possess the device. Keep the credential unavailable to that workflow, or require the actual service owner to perform the confirmation on an approved device.

Do not solve a transfer by changing a display name and keeping the old profile. That approach is popular because it preserves tools and avoids a slow setup. It is wrong for a machine that can authorize agent activity because it leaves too many unexamined paths: saved passwords, SSH configuration, command history, local repositories, and access to recovery methods. Convenience has a place in workstation setup. It does not belong in the evidence trail for a changed custodian.

Removed fingerprints need proof, not a verbal assurance

Removing a fingerprint reduces one route to approval, but it does not prove that the former user lost access to the Mac. The review must establish that the person cannot authenticate through another local account, an administrator credential, a recovery method, or an already-open session.

This matters after departures and role changes. A manager may ask for a fingerprint removal because an employee no longer works on the service. That is a good first action, yet it can create false comfort if the employee still knows the login password, retains an administrator account, or has a device that remains unlocked at a shared desk.

Use this evidence set when a fingerprint comes off a Mac:

• A current owner opens Touch ID settings and confirms the fingerprint is absent.
• An administrator verifies that former local accounts are disabled or removed according to the applicable retention procedure.
• The current owner locks the screen, restarts the Mac, and verifies that only approved people can return to the desktop.
• The service owner reviews which credentials were available before the removal and decides whether any require rotation.
• The reviewer records the time of the access change, the people involved, and the result of the checks.

A restart is useful because it clears the comforting but misleading state of an already-unlocked computer. It also forces the team to confront the password path that Touch ID normally hides. If the former user can still get past the login screen, the fingerprint was not the access boundary you thought it was.

Rotate a credential when the former person had access to it, could have copied it, or could have approved calls while the machine was unlocked. Do not rotate merely because someone removed a fingerprint months after a routine change, if you can show that the credential was never exposed to them and the device remained under controlled custody. Rotation has a cost, and indiscriminate rotation makes teams delay it when it is actually warranted. Tie the decision to what the person could do, not to a ritual.

This is also the moment to revoke agent sessions. A session approval is a statement about a particular running process under a particular access condition. Once the authorized person or biometric enrollment changes, that statement has expired. Restarting the agent is cheap. Explaining why an old process kept access after a custody change is not.

A biometric lockout calls for containment first

A Touch ID lockout should pause approvals until the team confirms possession and restores access through the intended recovery path. Lockouts happen for ordinary reasons: repeated failed attempts, a restart, a sensor problem, or macOS requiring the account password. They also happen at precisely the wrong time, when someone feels pressure to find any route around the control.

Do not respond by leaving the machine unlocked, sharing an account password in chat, or moving a credential into an agent configuration file. Those actions solve the immediate prompt and create a longer incident. The agent should never receive the secret simply because a person cannot complete a biometric confirmation.

Use this containment sequence:

1. Stop the agent run or revoke its authorization. Record the agent process and the action it was trying to perform.
2. Establish physical custody. Ask who has the Mac, where it has been, and whether anyone outside the approved group could have used it while unlocked.
3. Use the local account password through the normal macOS path if the owner is present and authorized. A password requirement after restart is expected behavior, not evidence that Touch ID failed.
4. If the owner cannot authenticate, hand the device to the approved support or recovery process. Do not improvise with another person's account or fingerprint.
5. After recovery, review the enrollment list, local accounts, and any attempted agent actions before restoring approval capability.

The fifth step is where teams get careless. They see the desktop again and declare the incident over. Recovery proves that someone regained access; it does not answer whether the lockout masked a hardware problem, unauthorized attempts, a changed fingerprint list, or an abandoned agent session. Take two minutes to answer those questions while the event is fresh.

A lockout that occurs during an urgent release still deserves the same treatment. Move the release decision to another approved machine if the organization has one. If it does not, pause the consequential action. That answer will frustrate someone, but it is better than degrading the credential boundary under time pressure and discovering later that the exception became the documented process.

The vault gate should remain absolute during uncertainty

When the Mac's custody or biometric state is uncertain, deny access at the vault boundary until a responsible person resolves it. A conditional rule that lets some agent calls continue while the team investigates is harder to reason about and much easier to abuse.

This is where a simple control model earns its keep. If a locked vault denies all actions, the operator does not need to calculate whether an HTTP request is harmless enough during a device review. They lock it, stop affected sessions, and perform the checks. The cost is a short interruption. The benefit is a clear answer to the question everyone will ask later: could the agent still act while device access was in doubt?

Sallyport's vault is hardware-gated on supported Macs through Secure Enclave and Touch ID, and its lock state denies actions. That does not remove the need for custody review. It gives the reviewer a clean containment control while they establish who has the computer and who can satisfy its approval requirements.

Do not stretch this control into a claim that the Mac is safe whenever the vault is locked. The Mac may still hold source code, browser sessions, work notes, or a local account with broad authority. The vault gate protects the actions that flow through it. Your transfer and incident procedures must protect the rest of the workstation as well.

The same limit applies to any audit record. A record can show that an agent attempted or completed an action. It cannot tell you whether someone watched a former owner type a password, whether an unlocked machine sat unattended, or whether a supervisor understood a prompt. Logs support a review; they do not perform one.

Audit entries need to connect the device event to the action

An access review is useful when a later investigator can connect a fingerprint or ownership event to the agent activity around it. Keep one concise record that joins the physical change, the local account checks, the affected sessions, and the credential decision.

For a small team, a controlled ticket or security journal is enough. Record the Mac asset identifier or serial number under your internal procedure, the previous and current custodian, the event type, the reviewer, the time window, and the result. Then attach references to the agent session record and individual action record. Do not store passwords, fingerprint images, recovery keys, or copied secrets in the ticket.

A record can follow this shape:

Event: Touch ID enrollment removed
Mac custodian before: Development contractor
Mac custodian after: Platform engineer
Observed by: Device administrator
Local-account result: Former account disabled and restart check passed
Agent result: Active sessions revoked at 14:32 UTC
Credential result: Deployment credential rotated after access review
Follow-up: Clean reprovision scheduled before reassignment

The point of this artifact is not paperwork. It prevents the most damaging ambiguity: one person believes the device changed hands, another believes the agent approval remained valid, and a third assumes a credential rotation happened because it was mentioned in a meeting. Each claim needs an observable result.

Sallyport projects both session and call records from a write-blind encrypted, hash-chained audit log. Its offline sp audit verify check can establish whether the encrypted chain still verifies without needing the vault material. Use that evidence for integrity, then pair it with your custody record. A valid chain does not make an incomplete handoff complete.

Review the records after the fact for patterns that point to process trouble: repeated lockouts around a release, recurring support enrollments, approvals from machines with unclear owners, or credentials marked for per-call review that people avoid using because every prompt lacks context. Those are design problems. Do not punish the person who reports them; change the workflow that made the workaround attractive.

Shared Macs turn personal biometrics into a team risk

A Mac used by more than one person should not be the approval station for sensitive agent actions unless the team can assign and enforce clear custody. Shared workstations are common in labs, build rooms, and temporary incident spaces. They are convenient for getting work done and poor at proving who made a permission decision.

The usual defense is that every person has their own login. That helps, but it is not sufficient when people know each other's passwords, leave sessions open for handoffs, or let a helpful coworker use a fingerprint to get past a prompt. The social norm in a cooperative team often defeats the technical separation.

Assign one primary custodian per approval-capable Mac. That person owns enrollment review, lock state, and escalation when the machine changes location or user. If the team needs a shared incident workstation, keep it out of the credential approval path or use a procedure that requires an authorized service owner to approve from their own controlled device.

You should also separate physical convenience from credential reach. A shared Mac can host documentation, dashboards, and read-only agent work without holding a route to production credentials. The moment it can authorize an agent to mutate shared systems, its placement, account setup, and biometric enrollment need the same discipline as any other privileged workstation.

Do not rely on a sign taped to the monitor that says "do not use Touch ID." Signs describe an intention. The system should deny the action when the intended owner is absent, and the process should make that absence visible. If your team cannot describe who may unlock, approve, and recover the Mac, remove it from the approval path.

The first review should happen before the next agent run

Run the review immediately after an enrollment, removal, ownership change, or lockout because the evidence is clearest before people resume normal work. Waiting until a quarterly access review turns a specific event into a memory test, and memory is where quiet exceptions go to disappear.

Start with the device in your hands. Identify the custodian, inspect the enrolled fingerprints and local accounts, lock or revoke access if anything is unclear, then end old agent sessions. After that, decide whether affected credentials need rotation and record the outcome with the relevant action history.

The hard part is not opening macOS settings. The hard part is refusing to treat a physical-access change as a personal convenience when the same Mac can approve an agent's use of real credentials. Keep that boundary clear, and the next urgent prompt will be a decision you can defend.