Zero standing privilege by design: make it a property of the session, not the token

Most vendors make the credential ephemeral. We make the privilege itself session-bounded—so standing privilege can't accumulate, even while a session is live.

Most PAM vendors now agree on one thing: an AI agent should hold no standing privilege. Mint an ephemeral token, bind it to the task, revoke it the moment the task ends. It's one of the louder points of consensus in the category, and the goal is right. But most of that work is happening at the identity layer—a shorter-lived credential—and a shorter-lived credential still carries whatever the identity behind it can do the second it's live.

This post is about the other way to get there: making zero standing privilege a structural property of the session an agent works in, rather than a lifecycle trick on the credential. In an earlier post we argued that adding an agent shouldn't widen your attack surface—that's the access path, the way an agent connects. A follow-up made the case that just-in-time access governs whether an agent gets in, never what it does once inside. This one goes underneath both: how the privilege an agent holds while it's inside is bounded by design.

Zero standing privilege, in the sense this post means it, is a property of the session: the privilege available inside a live session can never exceed the scope it declared, bounded at the execution layer—not a credential that merely expires faster.

Is zero standing privilege just a faster-expiring token?

Provisioning ephemeral access is real progress over a static admin key sitting in a config file, and I don't want to wave it away. An agent holding a durable credential is a durable liability, and killing that is worth doing.

But "ephemeral" is a statement about how long a credential lives, not about how much it can do. Bind a token to a task, and for the window it's valid it still inherits every entitlement the identity behind it holds. If that identity can reach production, the token can too—for as long as the task runs, which for an agent firing dozens of actions a minute is more than enough time to do something irreversible. The token expired on schedule; the privilege was standing the whole time it was live.

So the interesting question isn't "how do we make credentials shorter-lived." It's "how do we make sure the privilege available inside a live session never exceeds what that session was opened to do." Those are different problems, solved at different layers.

Where does standing privilege actually hide?

TL;DR: In two places an ephemeral-token story never reaches—the scope inside a live session, and the long-lived credentials (service tokens, superuser API keys, orphaned OS accounts) that no token-minting flow touches.

There are two blind spots in the mint-and-revoke model, and they're the two that matter.

The first is inside the session. Once a token is issued, the identity layer's job is done—it has authenticated the actor and handed over access. Whatever that access can reach, it can reach. Nothing in the token-lifecycle story constrains the specific action to the specific task.

The second is everything a token flow never issues in the first place: the service account wired into a CI pipeline, the superuser API key, the local OS account someone created for a one-off migration and nobody remembers. These are standing privilege in the most literal sense, and they accumulate precisely because no one is governing their creation and removal. Standards data backs this up—a CSA and Oasis survey found 78% of organizations have no formal policy for creating or removing AI identities, and in cloud-native and DevOps environments machine identities can outnumber humans by as much as 144 to 1 (Entro Security). You cannot rotate your way out of a credential you don't know exists.

How does the session model make zero standing privilege a structural property?

TL;DR: Every action belongs to a session with a declared scope that, by design, is a ceiling above RBAC—plus a hard time bound with auto-revoke, no out-of-session path, and a scope-expansion gate that can't lift itself. The time bound and auto-revoke are live; the scope-ceiling denial rolls out monitor-then-enforce.

In Alpacon, every user and agent action belongs to a Work Session, and there is no out-of-session path for them. A session declares its scope and a required purpose up front—scope is never inferred from the first command it happens to run.

The load-bearing property is what that scope is. By design it's an authorization ceiling that sits above normal role permissions: a sudo that isn't in the session's scope isn't authorized by the session, even for a superuser. RBAC bounds what a session may be granted; the scope bounds what it can do. That distinction is the whole point—the declared scope, not the identity's standing role, is the cap on an agent's blast radius. Alpacon rolls that ceiling out monitor-then-enforce: it measures would-be off-scope denials on real traffic first, and where enforce mode is on, an out-of-scope sudo is denied before any approval prompt reaches a human.

Four properties make that hold by design. Anything not in the scope is default-deny. The scope is minimal—the intersection of what the servers allow and what the session declared. Every session is time-bounded, with a hard TTL that auto-terminates the session and auto-revokes its credentials when it expires—that part is live today. The scope-ceiling denial itself rolls out monitor-then-enforce; where enforce mode is on, an off-scope attempt is denied before it runs—the action never reaches the host, and the operator is guided to re-declare scope rather than the request slipping through.

There's one more that closes the obvious loophole: expanding scope mid-session is itself approval-gated, and the approval is redeemed out-of-band—over a channel the agent doesn't control, never the one it's requesting from. A widening has to be at least as gated as the action it unlocks, so a session can't quietly lift its own ceiling, and a non-human can't approve its own escalation no matter how many tokens it holds. Reviewing privilege drift away is a process. Designing so it can't accumulate is an invariant.

What about the credentials a session token never touches?

I want to be precise, because "zero standing privilege" is a claim a technical reader should push on. It is not literally true of every credential in an environment today, and any vendor who tells you otherwise is selling you the slogan.

What is true: user and agent sessions carry no standing privilege, and standing keys and vaulted secrets are eliminated on the access path—the way in doesn't depend on a durable credential to steal. What is not yet fully closed: service tokens are still long-lived, bounded by a static ACL rather than a session, and closing the standing privilege on superuser API tokens is on the roadmap, not shipped. Those are the named exceptions, and naming them is the point of saying "by design"—the design has to account for the credentials the happy path never issues.

The orphaned OS account is the sharpest version of this, and account provenance is now closing it at the OS-account layer: every local account on a managed server carries its origin and whether Alpacon provisioned it, so disabled, shared, and orphaned accounts are surfaced by provenance rather than left to rot. When a person's last access to the account is removed, the accounts Alpacon provisioned are deprovisioned automatically; discovered and shared accounts, the ones Alpacon never created, are unbound from the departing identity rather than silently deleted. (Propagating an identity-provider leaver event all the way down to the host is on the roadmap, not shipped.) That directly answers the CSA and Token Security finding that only 21% of enterprises have a formal process for decommissioning AI agents. The account nobody remembers creating is standing privilege; you can't govern it until you can see it.

Here's the honest per-credential-type status:

The basics are table stakes; the execution layer is the hard part

Here's the distinction that matters competitively. Minting a task-bound token is access provisioning, and it belongs at the identity layer, where a lot of vendors are converging. Bounding what a live session can execute is execution control, and it lives one layer down, at the point where a command is about to reach a host. You can bolt zero standing privilege onto an identity product as a shorter token; it's much harder to bolt on a scope ceiling that can deny an out-of-scope sudo before it runs without owning the layer where the command is evaluated. Default-deny, a minimal scope, a hard TTL, auto-revoke on expiry—those are table-stakes any PAM will list. The part that's hard to copy is enforcing them on the command itself, at the execution layer, rather than at the identity edge where the session's authority is invisible.

That's also where the regulatory line is landing. The EU AI Act obliges high-risk AI systems to keep a human who can intervene or stop them, binding from 2026-08-02—and where an agent falls in scope, the most direct place to honor that for something moving at machine speed is a session that can hold, escalate, and revoke at the moment of action, not a credential that already expired.

Zero standing privilege isn't a shorter-lived credential. It's a session that can't exceed what it declared—not even for a superuser, not even mid-flight. Get that right and the audit question answers itself: every allow, deny, and escalation inside the session boundary becomes a record. Turning those records into an audit you can actually stand behind is where this thread goes next.

FAQ

Is zero standing privilege just an ephemeral, task-bound credential? No—not on its own. Zero standing privilege by design means the privilege available inside a session can never exceed what that session declared—bounded at the execution layer, not just expired faster at the identity layer. A shorter-lived credential still carries the full privilege of the identity behind it for as long as it's live, which is plenty of time for a machine-speed agent to do damage.

What is a scope ceiling, and how is it different from RBAC? RBAC defines what a role may be granted. The scope ceiling defines what a specific session can actually do, and by design it sits above RBAC: a sudo that isn't in the session's scope isn't authorized by the session, even for a superuser. Alpacon rolls that denial out monitor-then-enforce; where enforce mode is on, the out-of-scope sudo is denied before any approval prompt. By design, the declared scope—not the identity's standing role—is what bounds the session.

Does Alpacon really eliminate every standing credential? No, and we're specific about it. User and agent sessions carry no standing privilege, and standing keys are off the access path. Service tokens are still long-lived, bounded by a static ACL, and closing standing privilege on superuser API tokens is on the roadmap. Orphaned OS accounts are now surfaced by provenance—when an account's last access is removed, the ones Alpacon provisioned are deprovisioned and discovered or shared accounts are unbound rather than silently deleted (propagating an identity-provider leaver event to the host is on the roadmap). "By design" means the design names those exceptions rather than hiding them.

Can an AI agent widen its own scope mid-session? No. Expanding scope is approval-gated, and the approval is redeemed out-of-band, over a channel the agent doesn't control. A widening has to be at least as gated as the action it unlocks, so a session can't self-lift its ceiling and a non-human can't approve its own escalation.

If you're putting agents on production infrastructure, this is the layer that decides whether an ephemeral session is also a bounded one.