Home/Platform/Just-in-Time Elevation
Privilege
The access the work needs. For the time it needs it.
A standing administrative account keeps rights in place between tasks. Seraph does not. Privilege is minted when a person authorizes an operation, scoped to that operation on that one machine, and revoked by the clock — not by the work reporting that it finished.
The life of a lease
Nothing has rights until someone says a name and a reason.
Follow one operation from the message Dana sent to the moment the rights stopped existing. The interesting part is the end: the revoke is bound to the clock, so it does not depend on anything reporting back.
Exposure
The same work. A different amount of standing risk.
This is the whole argument in one picture, drawn to scale. A month is 43,200 minutes. A standing admin account holds rights for all of them. Below it, twenty leased operations doing the same work — an illustration, but the proportions are exact.
Two scopes and a reason
A lease is not a role you hold. It is a key cut for one door.
The three things below are what make the difference between "the AI has admin" and "this operation had admin, here, for this long, because of this ticket".
Scoped to the operation
The lease is bound to OP-000217. It cannot be picked up by a different job, a scheduled task, or a second operation that happens to be running on the same machine at the same time.
Scoped to the target
One machine. Not a group, not an OU, not "servers". If the same fix is needed on a second server, that is a second operation with its own authorization and its own lease.
With the reason attached
Every grant carries why it happened — the ticket, the request, and the person who authorized it. A grant with no reason is the thing an auditor circles, so we do not issue one.
What the record carries →- No shared admin account. Not one for the AI, not one for the platform, not a "service account" in a password safe that four technicians know. There is nothing standing to share.
- No group membership that outlives the work. Elevation is not "add to Administrators and remember to remove it later". Later is exactly where that fails.
- No lease you can reuse. A lease cannot be extended, borrowed, or carried into the next operation. The next operation asks again.
When a person steps in
Taking the wheel mints a new lease, under your name.
The tempting shortcut is to hand the technician the lease the AI was already holding. We do not, because the record would then be unable to tell your work apart from the model's.
-
The AI's lease is revoked, not transferred
The moment you take over, the privilege the operation was running under ends. Nothing is passed across.
-
A fresh lease is minted under your identity
Same two scopes — this operation, this target — with its own ceiling and its own reason, granted to you by name.
-
The operation continues. It does not fork.
Same operation id, same receipt. The handover is an event inside it, so the record shows which part of the work ran under the model's lease and which part ran under yours.
In the record
What your auditor gets to read afterwards.
Privilege that expires is only half of it. The other half is that the grant, its scope, its reason and its end are in the same record as the work they paid for.
| The question | A standing admin account | A Seraph lease |
|---|---|---|
| When did these rights start? | When someone created the account, years ago | 09:40, on this operation |
| Who decided they should exist? | Whoever set it up, if the ticket survives | A named person, in the same record as the work |
| What were they allowed to touch? | Everything the account can reach | One operation, on one machine |
| Why was this granted? | Not a field that exists | The ticket and the request that caused it |
| When did they end? | They have not | 09:48, on the clock |
| Can I check that they ended? | Not from the account itself | The revoke is in the operation record |
This is a comparison with the shape of a standing account, not with any particular vendor's PAM product. A good PAM tool answers most of these well — it was built to. What it was not built to tell you is whether the work the privilege was borrowed for actually succeeded, which is why the receipt and the lease live in the same object here.
The questions people ask about elevation.
What if eight minutes is not enough?
The ceiling is set per runbook class, not globally, and a long-running operation gets a ceiling that suits it. What does not happen is a lease quietly extending itself because the work is taking longer. An operation that runs out of time stops and asks, which is the behaviour you want the first time something unexpected is happening on a production server.
Where does the privilege actually come from?
From an identity your platform already governs — a directory account or a local managed account — checked out for the operation and returned afterwards. The model never receives it in any form. Credential Vault draws that boundary, and it is the one worth reading next.
Does the AI decide what privilege it needs?
No. The operation names what it is doing; the platform derives the least privilege that operation requires and requests exactly that. The model does not get to ask for more, because it is not the thing doing the asking.
Can we set this so nothing elevates without a human?
Yes, and that is the default. Standing authorization for a certified runbook class is something you turn on deliberately, per class, and it moves your say-so earlier rather than removing it. Everything else about the lease is unchanged.
What happens on a machine with no agent?
There is no tunnel, so we cannot create or rotate an identity there. The work is brokered from a managed neighbour using an identity that is already vaulted or held by the client. That is a real constraint and we would rather state it than let you find it during onboarding — see the trust centre.
Test the claim, don't take it
Ask us to show you the lease expiring.
On a demo we run an operation, open the record, and try to reuse the privilege it borrowed. Bring the questions from your last client audit.