Signing a social account in
How does a password reach a phone without being handed around?
The credential-release path, message by message — proving that a password never rides inside a job.
Drag to pan, scroll to zoom, click an element to trace it.
Open full screenWhat to look for
- How far down the page the credentials message appears — everything above it happens first.
- The note "requires a live lease on a running sign-in job".
- The audit entry written on release, before the credential is returned.
Read the full explanation
Read this one top to bottom; it is the sequence of actual messages. An admin asks for @brand to be signed in, the Control Plane creates a sign-in job, and the account moves to "login pending". At this point no credential has moved anywhere.
An agent leases the job and receives a lease token. It wakes a phone, opens the app, and checks where it is. Only then — holding a live lease, on a running sign-in job, for this account — may it ask for the credential. The password is fetched at that moment, for that job, and is valid for five minutes.
That ordering is the entire point. If a password travelled inside a job, it would exist in the queue, in retries, in job history, and in anything that ever logged a job. Instead it is requested at the last possible moment by something that has already proved it is doing the work, and every release writes an entry to your activity log that you can read afterwards.
The ending has two branches and no third. Either the device signs in and the agent reports success, or the app raises a security challenge, the device is parked, and the job ends needing a person, naming what that person has to do. There is no bypass path on this diagram because there is none in the product.
Anyone doing security review, and anyone nervous about handing over a password.