Sudo

Every time someone gets permission to run a privileged command on one of your servers, Alpacon records it. The record covers what command was authorized, on which server, for which user, and how the authorization was decided — whether the person already had standing permission, matched a policy, or got a one-time approval from an admin.

How to get here

Open the sidebar and go to Audit → Events → Sudo (or My events → Sudo if you’re a regular user).

What’s in the list

User — the OS user the authorization applies to, or the owning application when a service token ran the command (there is no person behind it).
Server — the server the authorization covers.
Command — the specific command that was authorized.
Type — how the authorization was decided. Six values:
- Direct permission — the user has standing privilege on the server (staff, superuser, or server manager).
- Predefined policy — a sudo policy matched the user, server, and command.
- Admin approval — an admin reviewed and approved a one-off request.
- Approved work session — a session-scoped policy that skips the per-command MFA prompt.
- Low-risk command — a service token ran a command whose assessed risk stayed under the workspace ceiling, so it was allowed automatically. See Command patterns and sudo.
- Advisory (not gated) — the workspace’s execution control is set to Advisory, so risk did not decide this authorization. The command still had to clear the authority sudo requires; what the mode removed is the risk gate on top of it.
Status — where the authorization is in its flow: pending MFA, pending approval, authorized, rejected, expired, or used.
Date — when the authorization was issued.

Filtering

Use the filter bar to narrow the list by user, server, type, or status. Useful combinations:

“Who got admin approval to run anything on prod-db-01 this quarter?” → filter by server and type Admin approval.
“Were any sudo attempts rejected on this server?” → filter by server and status Rejected.
“Which users got policy-based sudo on a sensitive command?” → filter by command and type Predefined policy.
“What did our deployment pipelines elevate last month?” → filter by type Low-risk command.

Who sees what

The page is open to all users, but the rows scope to your role.

Regular users see only the authorizations issued to themselves. The sidebar label is My sudo.

Administrators see every authorization across the workspace. The sidebar label is Sudo.

The narrowing is enforced server-side — direct URLs follow the same rule.

How sudo authorizations get created

There are three ways:

Inside a work session. A session that includes the sudo scope can issue authorizations under the policies attached to that scope. The grant ties back to its parent session in the audit trail.

On the fly. A user runs sudo <command> inside a Websh terminal. Alpacon checks standing permission first, then matching policies, then asks an admin for one-off approval. Whichever layer authorizes (or rejects) the request gets recorded here.

From automation. A service token runs a command that needs sudo. There is nobody to answer an approval prompt, so the decision is made from the command’s assessed risk and recorded here as Low-risk command, attributed to the application.

Approvals — approval-type sudo grants link to an underlying approval decision. The reviewer, the timing, and the justification all live in Approvals.
Sessions — sudo grants issued inside a work session link back to that session.
Command patterns and sudo — how elevation is decided for a token, and what each denial code means.