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.
- Server — the server the authorization covers.
- Command — the specific command that was authorized.
- Type — how the authorization was decided. Four values:
- Direct permission — the user has standing privilege on the server (staff, superuser, or server manager).
- Policy-based — a sudo policy matched the user, server, and command.
- Admin approval — an admin reviewed and approved a one-off request.
- Policy-based (MFA bypass) — a session-scoped policy that skips the per-command MFA prompt.
- 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, grant type, or status. Useful combinations:
- “Who got admin approval to run anything on prod-db-01 this quarter?” → filter by server and grant type 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 grant type Policy.
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 two 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.