Approvals
Approvals is a governance queue where approvers review and approve or reject sensitive requests from workspace members. Requests carry a risk rating—and, for work sessions, an AI pre-review—to help reviewers decide quickly and safely.
Approvals is available to Superusers and to the members your workspace makes approvers. A separate Approval history view (under Audit) shows past decisions.
What goes through approvals
Several kinds of sensitive requests route here:
- Work session, work session modification, and session extension
- Service token and token modification
- Username and group name changes
What an approver sees—and what they can adjust—differs by type. See Request types. For the reviewer-side journey end to end, see The approver’s guide.
The approvals queue
Open Pending approvals in the sidebar. Each request shows its type, the requested data, who requested it, and its status:
| Status | Meaning |
|---|---|
| Pending | Awaiting a decision |
| Approved | Approved by a reviewer |
| Rejected | Rejected by a reviewer |
| Canceled | Withdrawn by the requester |
| Expired | Timed out before a decision |
Filter the queue by status—All, Pending, Resolved, or Expired & canceled—and by request type, or search across requests.
For how to open and act on a request, see Reviewing requests.
Who can approve
A request is decided by the approvers its access rule names; see Who may approve a request. By default, those are the workspace’s Superusers, and any of them can review any pending request. The Admin role doesn’t by itself let you approve. The managers of a request’s servers are notified of a pending work session but can’t approve it unless they are among its approvers.
A request can’t be approved through the same channel it was submitted from—for example, a request made from the CLI is approved in the Approvals queue of the web console (or via Slack), never from the CLI itself. So you track your own request’s status (for example, from your dashboard) until an approver decides. Slack one-tap approvals follow the same approver rules. An approver must complete MFA to decide a request that grants standing authority, such as a service token or a sudo policy, and decides it in the console; see When a decision asks for MFA.
Automatic approval
Some requests clear without waiting for a manual decision:
- A Superuser’s own session request is approved as soon as it’s made.
- By default, sessions requested by an AI agent wait for a person’s approval, even when a Superuser makes the request.
- Workspaces can set access rules that decide, based on a request’s risk and who is asking, which actions are allowed, which wait for an approver, and which are blocked.
In a workspace whose execution control is set to Advisory, the requests that exist because of a risk judgment are never created at all: a command is not held for approval, and a work session—or a change to one—is admitted without review. Service token and identity requests are unaffected, and a sudo action still needs its own authority, so a request for something nobody is authorized to do still reaches this queue.
Switching the mode is not retroactive. Requests already Pending at the moment of the switch stay pending—neither approved nor released—and still need a decision. A pending work session nobody decides cancels itself once its pending window runs out (24 hours by default), and the requester is notified. After switching, submit the request again rather than waiting on the old one.
Access rules
Access rules decide what happens when someone opens a session, uses sudo, or runs a command. They live under Policies > Access rules, on the Overview, Sessions, Sudo, and Commands tabs. Superusers see the page, and so do admins whose role lets them read approval rules, on every deployment. The old Privileged access and Approval rules addresses open these tabs.
Each rule reads as a sentence: who asks, on which servers, and what happens. Click a word in the sentence to change it:
- Who: anyone, a person, an AI agent, or people with a role. A session rule can also name the role of the person the session is for.
- Servers: any server, or the servers in one group. Every tab offers it.
- AI rating: how the AI rates the command, for sudo in commands and for commands.
- End date: when the rule stops applying.
- Outcome: Allow, “Ask an approver”, “Ask 2 approvers”, or Block. On the Sudo tab, Allow after MFA makes the rule a standing sudo policy for the people, servers, and commands it names.
A choice your plan doesn’t include carries a plan badge instead of being hidden. On the Free plan, conditions such as an AI agent, a role, a server group, or an AI rating show Essentials, and so do an approver role, Not by the person who asked, and Allow after MFA. “Ask 2 approvers” shows Enterprise on the Free and Essentials plans.
Rules are checked from the top down. Drag a rule, or press Alt+↑ or Alt+↓, to change the order. A new rule starts as “Ask an approver” and goes last. Try it, beside the rules, shows what a request would get and which rule decides it.
Rules for AI agents
By default, a session requested by an AI agent waits for a person’s approval, even when a Superuser makes the request. An Allow rule for an AI agent admits an agent session that states its purpose without a person; a session with no purpose waits for a person. In an Enforce workspace, an agent session that attaches MFA-bypass sudo policies waits for a person even under such a rule.
On the Sessions tab, AI agents by name narrows a rule to the names AI agents report about themselves. Pick from the known agents and the names your workspace has already seen, choose No name given, or type a name. To accept only certain names, add an Allow rule for each name you accept, then a name rule with any entered under AI agents by name and Block as its outcome. These rules do not verify which agent is actually running.
The name is what the client reports about itself, so treat it as a label, not proof of identity. A rule that is stricter for one agent can be sidestepped by a client that reports another name, and your rules for every AI agent apply instead. To require more of every AI agent, add a rule for an AI agent that asks an approver or blocks the request.
Who may approve a request
A rule whose outcome asks for approval names its approvers: Approvers for those servers, or people with a role you pick. With Approvers for those servers, anyone who is an approver for the group of any of the request’s servers, or for the whole workspace, can decide, and Superusers can always decide too. When no approver covers any of the request’s servers, only Superusers can.
The same outcome offers Not by the person who asked. Check it to require someone other than the person who asked; on the Free plan it carries an Essentials badge. If nobody else can approve a request under that rule, it is refused right away rather than left pending. In a workspace whose execution control is set to Advisory, sessions are admitted without review, so this refusal doesn’t apply there. On a deployment that cannot tell the approving client from the requesting one, the person who requested an AI-agent session cannot approve it, even when the rule allows it.
Approval history
Resolved requests are available in Approval history under Audit > Governance, where you can review past approve and reject decisions.