Solution
Elevated once.
Trusted for hours.
Access management gets a person into the session. Everything after that is inherited. The consequential operation waits until it carries an approval the operator released on their own phone.
The problem
Elevation is a state, and a state covers everything inside it.
Access is granted to a person, for a window, and every operation in that window inherits the grant. The controls are working exactly as designed; what they cannot do is tell one operation inside the window from another, at the time or afterwards.
Access vaults and credential brokers
They broker the credential and open the session. Once it is live the vault is not consulted again for the operations taken inside it, because that was never what it was asked to do.
Just-in-time elevation
It narrows the window. It does not change the granularity: inside an approved window every operation is equally permitted, and afterwards they are equally hard to tell apart.
How it works
Elevation stops being a state. It becomes a fact about one operation.
Your existing access management, identity provider and roles all stay. What is added is a verification step your infrastructure calls before the consequential subset runs.
Classify the operation
Your policy marks which operations need a person: production writes, secret access, permission grants, break-glass. Read-only and routine work is untouched, and you move the line whenever you want.
Ask the operator
At execution time the request goes to the operator's own enrolled phone, carrying the command and the target it is asking about rather than a generic prompt.
Verify, then run it
The approval comes back carrying the operation it was made for. Your infrastructure verifies it against what it originally sent, and the command runs only if it verifies.
Where the approval is made
The signing key is generated inside Android's StrongBox or the TEE, or inside the iOS Secure Enclave, and released by the operator's own fingerprint or face. It has no export path, so the authority behind the operation is not held by anything in your estate, or in ours.
Where it applies
The operations worth a person.
Each is the same step with a different command inside it.
A production write
A schema change, a data deletion, a migration against live records. The operator who ran it is the one who released the approval for it.
Reading a secret
Pulling a production credential out of the vault is itself the consequential act, and it waits for a person the same way.
A permission grant
Which role is being granted, and to whom, is on the screen the approver signed off.
Break-glass
Emergency access is the path most likely to be abused and least likely to be reconstructed afterwards. It produces the same record as everything else.
The boundary of the guarantee
Where this stops.
Stated here rather than discovered later.
Your gate is the enforcement point
The check runs in your own infrastructure, because that is where the command executes. A second path that reaches the same operation without it will reach it. What is not required is not controlled.
An operator can be talked into approving
Someone persuaded to run the operation themselves will approve it, and the approval will be valid. That is a real limit and this page does not pretend otherwise.
The device can be unavailable
You define the fallback and it is recorded as what it was. For the most consequential operations you can require a second enrolled operator rather than drop to an unproven path, so break-glass still leaves a record.
See it on your own flow.
Your app, your call, our SDK.