What is the difference between standing access and just-in-time access?

Standing access is permission that exists whether or not it is being used. Just-in-time access grants the same permission only for an approved window and then removes it, which shrinks the time a leaked credential is useful. Just-in-time is a real improvement, but during the window the access is as broad as the role allows, and it depends on a human completing an approval workflow at the moment they are least inclined to: during an incident.

Why is rotating credentials not enough?

Rotation shortens the useful life of a credential that has already leaked. It does not reduce how many credentials exist or what they can do, and between rotations the credential is standing access like any other. It reduces the window; it does not remove the exposure.

How can a developer operate a production service without a credential?

By not performing the operation themselves. The operation is packaged and runs under its own scoped identity inside the cluster; the developer's request is authorised at the moment they make it, and they hold nothing between requests. There is no kubeconfig on their laptop to steal, because the authority lives with the operation rather than with the person.

Concepts

Standing access

Standing access is permission that remains granted when nobody is using it: the production database password sitting in a developer's password manager, the cluster-admin kubeconfig on a laptop, the service account token issued two years ago and never rotated. It is the default state of most access, and it is what attackers actually use. Verizon's 2026 Data Breach Investigations Report puts credential abuse in 39% of breaches, the single most common way in. The reason standing access is singled out is that a credential's risk is not a property of the moment it is used; it accumulates for as long as the credential exists. Every day it exists is another day it can be phished, committed to a repository, left on a decommissioned laptop, or carried to a new team by someone who no longer needs it. A credential that was never issued cannot be any of those things.

Why it exists everywhere

Standing access is not usually a decision. It is the residue of decisions. Access is granted for an event (an incident, an onboarding, a migration, one bad Friday) and then scoped to a person rather than to the event. Revocation has no forcing function: nothing breaks when a permission is left in place, and something might break if it is taken away, so the safe move for whoever is holding the ticket is always to leave it.

The result is that a credential's real exposure is the union of everywhere it has ever been: the laptop, the second laptop, the CI log it was accidentally echoed into, the screenshot in the incident channel, the backup of the password manager. None of that is visible at the moment you decide whether to revoke it, so the decision keeps going the same way.

The standard answers, and what each one leaves behind

Rotation. Shortens the window in which a leaked credential is useful. It does not reduce the number of credentials in existence, and a credential rotated every ninety days is still standing access for ninety days.
Vaulting. Secures storage and centralises issuance, which is a genuine improvement to how credentials are handled. The credential still exists, and it still does everything it could do before, for whoever pulls it out of the vault.
Just-in-time elevation. The best of the three: access exists only inside an approved window, which is what "zero standing privilege" aims at. Two things survive it. It is still access: during the window, the blast radius is whatever the role allows. And the approval is a workflow a human has to complete, usually in the middle of an incident, which is precisely when people route around it.

Each of these is worth doing and none of them removes the credential. That is not a criticism of them; it is a description of the ceiling they share. They make holding dangerous access safer. They do not answer the question of why the developer needs to hold it.

The alternative: don't issue one

If a developer never holds a credential, there is nothing to rotate, steal, vault, or revoke. Getting there means the operation is performed on their behalf by something that does hold a scoped identity, and their authority to ask for it is checked at the moment they ask. The permission is attached to the operation, and the human is attached to the request.

This is a real trade, not a free lunch, and it is worth stating the cost plainly: the thing performing the operation now holds a permission, and that permission is standing. What changes is its shape: one identity, confined to a fixed set of operations, running inside the cluster, that cannot be phished off a laptop or committed to a repository, instead of one credential per developer, each able to do anything the role allows, from anywhere, forever.

How Spellbook relates to this

This is the trade Spellbook makes. Spells run self-hosted inside your own cluster. The person casting one holds no kubeconfig, no token, and no shell; what they have is the ability to ask for a specific operation on a specific service. The spell's own identity does the work, and the audit line records which human asked for it.

So the standing permission does not vanish. It moves, from every developer's laptop to one in-cluster identity that can only perform the operations that were packaged. Whether that is a good trade depends on how many people currently hold credentials they use twice a year. For most small teams, that number is everyone.

In the demo on the homepage, typing kubectl exec gets you a refusal rather than a shell, because there is no credential behind the prompt to exec with. Spellbook is not open yet.

Common questions

What is the difference between standing access and just-in-time access?: Standing access is permission that exists whether or not it is being used. Just-in-time access grants the same permission only for an approved window and then removes it, which shrinks the time a leaked credential is useful. Just-in-time is a real improvement, but during the window the access is as broad as the role allows, and it depends on a human completing an approval workflow at the moment they are least inclined to: during an incident.
Why is rotating credentials not enough?: Rotation shortens the useful life of a credential that has already leaked. It does not reduce how many credentials exist or what they can do, and between rotations the credential is standing access like any other. It reduces the window; it does not remove the exposure.
How can a developer operate a production service without a credential?: By not performing the operation themselves. The operation is packaged and runs under its own scoped identity inside the cluster; the developer's request is authorised at the moment they make it, and they hold nothing between requests. There is no kubeconfig on their laptop to steal, because the authority lives with the operation rather than with the person.

Sources

Verizon Data Breach Investigations Report 2026Credential abuse appears in 39% of breaches, the most common initial access vector.

Last reviewed 13 July 2026.

None of this needs a credential on your laptop.

Spellbook packages the dangerous operations so the people who run them hold nothing. It is not open yet.

Join the waitlist