Zero standing privilege: a 7-question audit for your stack

Seven yes/no checks to run against your own stack before you trust a vendor's zero-standing-privilege claim.

Zero standing privilege is on many PAM vendors' slides now. The slide rarely says what happens when you try to break it. We've argued that zero standing privilege has to be a property of the session itself—not just a shorter-lived credential that still inherits everything the identity behind it can do. This is the practical follow-up: seven questions to run against your own environment, so you're not taking anyone's word for it.

The five properties you're actually checking

Five things this audit checks. The first isn't a zero-standing-privilege property at all, and that's the point: scope tells you what a session may reach, not whether anything looks at what it runs.

1. Once a command is inside the declared scope, something still looks at the command itself—scope isn't a free pass to run anything within it.
2. It denies anything outside its declared scope by default.
3. Its scope is the minimum intersection of what the servers allow and what the session asked for.
4. It can't expand its own scope without an out-of-band approval.
5. Any credential the session model doesn't cover is named, not hidden.

The questions below test these five, plus two more—the credentials and accounts a session model alone doesn't reach.

The checklist

Run each of these against your own environment, not your vendor's slide deck.

1. Does anything look at a command once it's inside the declared scope? Run a command that's technically in scope but destructive—right channel, right host, right identity, nothing about the request looks wrong on paper. If the only thing standing between the session and rm -rf is that the scope allowed shell access in the first place, the scope is the whole control, and on its own it isn't enough.
2. Does a session get denied the moment it reaches outside what it was scoped for? Open a session scoped to one task, then try something outside that scope—a different channel, a different host, a command the policy never allow-listed. If it runs, you don't have default-deny—you have a suggestion.
3. Is the blast radius of a replayed token bounded by the session's declared scope, not the identity's full role? Don't guess—trace it. Pull a session's token, replay it against a host outside that session's declared scope, and watch what actually happens. If the answer is "the identity's full role," the scope isn't the ceiling—the role is, and the session model isn't doing any work at all.
4. Is a session blocked from widening its own scope without leaving the channel it's already in? Try to approve your own scope expansion from inside the same session, using the same credentials that opened it. If it succeeds, nothing stops a compromised session—or a compromised agent acting on its own initiative—from lifting its own ceiling before anyone outside the session finds out.
5. Does a superuser's sudo still have to fit the session's declared scope? RBAC answers what a role may be granted; this checks what the session actually authorizes at the moment the command runs. Log in as a superuser, open a session scoped narrowly, and try to sudo somewhere the scope doesn't cover. If it goes through with no denial or approval step, RBAC is still running the show, not the session—and the session model is decorative for anyone senior enough to have the role.
6. Is every service token or CI credential in this environment re-evaluated by something after it's issued, or does it just work until someone remembers to rotate it? Ask how long they live and what bounds them. A credential nobody re-evaluates after issuing it is standing privilege by another name, whatever the marketing calls it.
7. Do you know every local OS account on the fleet, and who still owns it? Pull the list from one server at random—not from your inventory tool, from the box itself—and count how many accounts nobody on the current team can name an owner for. The account nobody remembers creating is standing privilege by definition; you can't govern what you can't see, and an inventory tool only shows you what it was told about.

What this doesn't answer for you

A "no" on any of these is a real gap. No session model closes every surface: an interactive shell typically audits a risky non-sudo command after the fact rather than holding it before it runs, which is the same gap question 1 is testing for—on us as much as anyone.

Alpacon's own session model is built to answer the scope-ceiling side of this directly—questions 2, 4 and 5. Scope is minimal by construction: the intersection of what a server allows and what the session declared, with everything outside it default-deny. Widening that scope takes an approval-gated request from outside the session, not a decision the session can make on its own, and a session's deadline never sits more than the workspace maximum from now, so an unattended session reaches its expiry on its own and its open channels are torn down with it. That boundary is not a deployment setting or a staged rollout: the scope ceiling is enforced today, and a sudo outside the session's declared scope is denied outright—a superuser's included. Question 1—whether anything still looks at a command once it's inside that scope—is a different axis entirely: the same command-level judgment that decides what an in-scope action is actually allowed to do.

Run it before you take the slide at face value

This checklist doesn't replace the deeper argument for why zero standing privilege has to live at the session, not the credential. It's the version you run against your own environment, or hand to a vendor mid-evaluation—read literally, not rhetorically. If most of your "no" answers cluster in the same place—self-service scope expansion, orphaned accounts, service tokens nobody tracks—that's where the actual work starts, and it's usually a smaller project than the vendor conversation made it sound.