The approver’s guide

Most of Alpacon’s docs speak to the person asking for access. This guide speaks to you—the reviewer. If you hold the Superuser role, sensitive requests from across your workspace land in your queue, and it’s your call whether they proceed. Here’s how a request moves through your day: what reaches you, how to read it, how to decide, and where to look afterward.

Your role

When a workspace member needs to do something sensitive, the request routes to Approvals for a person to decide. What reaches you:

Work sessions and work session modifications: scoped, time-bounded access to specific servers.
Service tokens and token modifications: issuing new credentials to an application, or changing an existing token’s scopes or state.
Username and group name changes: identity changes that require approval.

See Request types for what you see and can change in each.

Reviewing the queue requires the Superuser role, and a few things follow from that:

More than one person can hold it. Any Superuser can review any pending request, so approvals aren’t blocked on one person.
Admins can’t approve. The Admin role doesn’t grant approval, and members without the Superuser role can’t open the queue at all.
Managers are notified, not deciders. The managers of a request’s servers are told about a pending work session but can’t approve it themselves.
You can’t approve through the channel that made the request. A request submitted from the CLI is decided in the Approvals queue of the web console (or via Slack), never from the CLI. This keeps the person asking and the person deciding on separate sides.
Your own session is the exception. When you request a session for yourself, it’s approved the moment it’s made—unless the requester is an AI agent (see below).

Reading a request

Open a request from the queue to see its details: the requester’s justification, the requested resources (or the before/after changes for a modification), a risk level, and—for work sessions—an AI pre-review. For a work session, that means the requested duration, features, target servers, and why they’re asking.

The AI pre-review

Every work session request carries an AI pre-review card with a recommended risk level (Low, Medium, High, or Critical risk), the reasoning behind it, and recommended features for the session. The recommendations are highlighted in the feature editor, but nothing is applied automatically—treat the pre-review as a second opinion, then decide. See Reviewing requests.

The risk rating

Each request shows a risk level so you can gauge sensitivity at a glance:

Service tokens: risk is computed from the requested scopes, with a per-scope breakdown and reason.
Work sessions: the risk level comes from the AI pre-review.

Risk is color-coded, so a High or Critical request stands out.

What you can adjust

For a work session, you’re not limited to yes or no. In the Admin adjustments area you can:

Change the features: add or remove scopes before granting.
Change the target servers: add or remove servers.
Add recommendations: notes the assignee sees before they start.

Approving sends your adjustments along with the decision. Other request types are review-only—approve or reject as-is. See Request types.

Watch the clock

Time-sensitive sessions show a warning when the window is nearly gone:

Expiring soon: approve promptly or the requester won’t have usable time.
Already passed: the window is gone, so approving now leaves nothing to use—consider rejecting and asking for a fresh request.

See urgency warnings.

Deciding well

A pending request shows Approve and Reject. Either way, the requester is notified.

Trim before you reject. Because you can add or remove features and servers before granting a work session, an over-broad request often doesn’t need to go back. Narrow it to what the work actually needs and approve the smaller scope. Reserve rejection for requests that shouldn’t proceed at all, or whose window has already passed.

Give sudo the most scrutiny. Privilege elevation (sudo) is the heaviest scope: for the session window it grants elevated, sudo-level access across the session’s other features. Including it in a session is only the first gate—each time the operator actually uses sudo, the action is checked again at that moment, may be held for a person to approve, and may prompt for MFA, with every sudo action recorded. Before you grant sudo, make sure the purpose genuinely calls for it. See privilege elevation (sudo).

Acting in bulk. You can select multiple pending requests and Approve all or Reject all, but bulk actions skip individual review and can’t be undone, so verify your selection first.

Cutting repeat work with approval policies

Reviewing every request by hand doesn’t scale. Some requests are meant to clear without waiting for you:

A Superuser’s own session request is approved the moment it’s made.
A workspace can configure approval policies that decide, based on a request’s risk and who’s asking, which actions clear automatically and which wait for a person. Low-risk sudo actions, for instance, can be cleared automatically while riskier ones are held for approval.

The idea is to govern by policy and review the exceptions: let routine, low-risk requests flow through a defined lane, and spend your attention on the ones the policy holds back. One line never bends—sessions requested by an AI agent always require a human, no matter the policy (see below).

See automatic approval.

While a session runs

An approval isn’t the end of your visibility. Live activity (under Execution) shows the sessions running right now so you can watch and step in.

Each active session appears as a card with its title, time remaining, requested features, and target servers. Open one for the live detail view, which streams:

Connection status: Live, Reconnecting, Closed, or Connection error, with the latest snapshot time.
Status history: the lifecycle from Requested through Approved and Active, on to Completed, Expired, or Revoked.
Activity timeline: a real-time feed of commands, terminal opens and closes, sudo requests and grants, and file transfers, filterable by category.

When you need to intervene, two actions are your kill switch:

Complete session: end a running session immediately.
Revoke session: end an approved session before it becomes active.

See Live activity.

After the session

Once a session ends, the record is where accountability lives.

Session history. Audit → Session history lists every session with who requested it, who approved it, the scopes and servers in play, how it ended, its duration, and a risk level from the AI analysis. Open a row for the full timeline, the approval record, and the analysis. See Sessions.

Recordings and AI risk analysis. A finished session’s detail page replays its activity on the History tab (Websh terminal recordings are masked and can be played back), and the Analysis tab adds an AI review once the session ends: a risk level, a plain-language summary, key metrics, a threat analysis (including a MITRE ATT&CK technique list when anything is found), and a response guide. See After a session.

Approval history. Your decisions are recorded too. Audit → Governance → Approval history shows past requests with the reviewer, the outcome, and any justification on record—useful for questions like “why was this approved?” and “what’s our approval-vs-rejection rate for sudo?” See Approval history.

When the requester is an AI agent

Alpacon lets AI agents request sessions from the CLI, but an agent’s request always lands on a human—you. A session requested by an AI agent requires human approval even when a Superuser makes the request, and no approval policy or self-approval shortcut changes that.

So an agent request gets the same care as any other, with a few things worth extra attention:

No automatic lane applies, so read the purpose and requested scopes yourself rather than assuming a policy vetted them.
Lean on the AI pre-review’s risk level and reasoning to spot a request that asks for more than the stated task needs.
Trim scope before granting, especially sudo, so the agent gets exactly the features and servers the work requires and nothing more.

See Request a session for how agent requests are made.