Reviewing requests
Open a request from the approvals queue to see its details: the requester’s justification, the requested resources (or before/after changes for a modification), a risk level, and—for work sessions—an AI pre-review and any adjustments you make.
AI pre-review
Work session requests include an AI pre-review card showing:
- a recommended risk level — Low, Medium, High, or Critical risk;
- the AI’s reasoning for that assessment;
- recommended features for the session.
The recommended features are highlighted in the feature editor so you can apply them by selecting them—there’s no automatic apply. Use the pre-review as guidance, then decide.
What Alpacon checked
Work session requests also show a “What Alpacon checked” block with the facts the access rule was decided on. The approval card lists:
- Approval rule: the rule that handled the request and what it requires, such as how many approvers.
- Agent: the name the AI agent’s client reported about itself, marked as self-reported, and the name the rules matched it as. When no name was declared, it says so.
- Connect as: the account the session runs as, or the assignee’s own account when none was named.
- Purpose: whether the requester provided a purpose.
- Approver: shown only when the rule doesn’t let the requester approve their own request, saying that an approver other than the requester is needed.
- Approval: says the requester approved their own request, when that happened.
The session’s own page shows the agent, account and purpose rows only.
The Slack and email messages for an approval request name the AI agent too.
Review the servers, account, purpose and the command details before you approve.
Below the block, “Policy check, not malware detection.” links to What Alpacon checks, and what it doesn’t.
Risk scoring
Each request shows a risk level so you can gauge sensitivity at a glance:
- Service tokens — risk is computed automatically from the requested scopes, with a per-scope breakdown and reason.
- Work sessions — the risk level comes from the AI pre-review (Low, Medium, High, or Critical).
Risk is color-coded (for example, Low green, Medium amber, High red).
Urgency warnings
For time-sensitive work session requests, a warning appears when the session’s window is nearly over:
- Expiring soon — the session window is about to expire, so approve soon or the requester won’t be able to use it.
- Already passed — the session window has already passed; approving now leaves the requester with no usable time, so consider rejecting and asking for a new request.
Approve or reject
Pending requests show Approve and Reject actions. Approving or rejecting notifies the requester. For a work session, approving sends along any adjustments you made to features, servers, or recommendations; for a session extension, it sends along the end time you left in place, shortened or as requested.
If the rule does not let the requester approve, their own attempt is refused with a message that another approver has to decide.
When a decision asks for MFA
Some requests ask you to complete MFA before your decision counts, and the rule is the same in the console and in Slack.
Requests that grant standing authority always ask for MFA, in every workspace, whether you approve or reject: sudo policy requests, service tokens, token modifications, API token scope expansions, and accepting a discovered server account. Decide these in the console. If you completed MFA within your workspace’s Sensitive action MFA timeout, 15 minutes unless an administrator changed it, you aren’t asked again. In Slack, these requests show only an “Approve on the web (needs MFA)” button that opens the console, instead of approve and reject buttons.
Every other request, sudo requests and held commands included, asks for MFA only when your workspace lists Approval under MFA required actions. Otherwise you can settle it with one tap in Slack, the same as in the console.
Held commands that run sudo
A command held for approval shows the whole command line, and the Slack card also shows its risk level and whether it runs with sudo. Approving the command also covers the sudo written in that line: it runs without a second sudo approval and is not refused for its risk level. Read the whole line before you approve. See Privilege elevation (sudo) for the forms that are still checked on their own.
When a command line is too long for a Slack message, or is formatted in a way that could hide part of it, the Slack card links to the console instead of showing buttons.
Shortening the session window before approving
When approving a pending work session request, you can grant less time than was asked for. Pick one:
- New duration — a shorter length than requested, from a preset or a custom number of minutes.
- New end time — an earlier end time than requested.
You can’t lengthen the window here—only shorten it, and never past what was requested or beyond your workspace’s maximum session length. For a session scheduled to start later, the shortened window is measured from that start time rather than from when you approve.
The requester sees the shortened window on the session once it’s approved. The approval’s detail also shows a Reviewer adjustments line with the original value, the shortened value, and who made the change.
Bulk actions
Select multiple pending requests to act on them together:
- Approve all — “Each request will be approved without individual review. This action is irreversible—make sure you’ve verified every selected request before proceeding.”
- Reject all — “All selected requests will be rejected and the requesters will be notified. This action cannot be undone.”
Bulk actions skip individual review and can’t be undone, so verify your selection first.