Approvals
Review sensitive requests from workspace members in Approvals.
An approval reviewer decides whether a requested action may proceed. The separate reviewer role records decisions about findings in periodic reports; that role alone does not grant approval authority.
Requests and risk
Approvers can approve or reject requests. Each request carries a risk rating; work session requests also include an AI pre-review.
Superusers and members named as approvers can review requests. Every member can open their own requests from the dashboard. A separate Approval history view (under Audit) shows past decisions to superusers on paid plans.
What goes through approvals
Several kinds of sensitive requests route here:
- Work session, work session modification, and session extension
- Command approval for a command held before it runs, and sudo for a
sudocommand that waits for a person - Sudo policy requests
- Service token, token modification, and API token scope expansion
- Username, group name, and application account name changes
- Accept discovered account, for an account found on a server
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
Approvers can open Pending approvals in the sidebar to review requests. 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.
Your own requests
Open My approval requests on your dashboard to see your requests, even if you are not an approver. The card groups them as Pending, Approved, Rejected and Closed; open a count or row to see that group in Approvals. You can cancel your own pending request from the card or its row in Approvals. Confirm the cancellation when asked. You cannot cancel a request after it has been decided.
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. Pending notices and reminders go only to people who may decide the request. Managing its servers alone does not make someone a recipient.
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. You can track or cancel your own pending request from the dashboard while it waits for an approver. 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. Advisory never creates an approval request for execution: sudo still needs standing permission or a matching sudo policy. Without either, it is refused immediately with SUDO_NO_AUTHORITY, and nothing is added to 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. An undecided work session is canceled when its requested end passes or its pending window runs out (24 hours by default), whichever comes first. The requester and assignee, or the assigned token’s owner or application recipients, receive an in-app notice. After switching, submit the request again rather than waiting on the old one.
When you can approve your own request
If you can approve your own work session request, you’re asked first, and the other approvers hear about it about 10 minutes later if it’s still open. This applies when you are one of the approvers, your workspace’s access rules let you approve your own request, and one approval decides it. A request that needs more than one approval, or one you can’t approve yourself, reaches every approver at once. See When you can approve your own work session request for who is notified, and when.
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, Opening a session, Using sudo, and Running a command tabs. Superusers see the page, and so do admins whose role lets them read approval rules, on every deployment.
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 Using sudo tab, select Web terminal under Where sudo runs to manage standing sudo policies, whose only outcome is Allow after MFA. Select CLI and API to manage approval rules with allow, ask, or block outcomes.
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. On any tab except Overview, select New rule in the page header to open the editor drawer for the selected tab and location. It starts as “Ask an approver” with one approver, except under Using sudo → Web terminal, where it starts as Allow after MFA. 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 sudo policies where the session approval takes the place of MFA waits for a person even under such a rule.
On the Opening a session 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.
A person barred from deciding gets no notices or reminders, including a Superuser. With Not by the person who asked, this includes the requester and, for a work session, a change to it, or a sudo or command request inside it, also the session’s assignee and API token owner. The AI-agent restriction on deployments that cannot distinguish the approving client applies to the same people.
Approval history
Resolved requests are available in Approval history under Audit > Governance, where superusers on paid plans can review past approve and reject decisions.