External access
External access is where your team reviews logins that reached a server without going through Alpacon: SSH, the local or cloud console, and su. Each one is recorded, matched against the workspace’s list of allowed direct access, and either counted under a standing entry or raised as a finding for a reviewer to decide. Detection records logins. It does not block them.
Work done through Alpacon (Websh, commands and deploys) never appears here, and neither does su run inside a Websh session.
How to get here
Open the sidebar and go to Audit → Governance → External access. The page has three tabs:
- Review queue: findings that need a decision, open ones first. See Review direct logins.
- Summary: a period’s direct logins, findings, standing entries and coverage, and Export evidence. See Summary and evidence.
- Logins: every recorded direct login, newest first.
External access appears for the reviewer, auditor, security_admin and admin roles. Anyone else who opens it, for example from a link, sees You need a review role to read External access.
If you can record dispositions, the dashboard shows Direct logins awaiting review whenever at least one finding is waiting. The card comes after your other dashboard cards (after Pending approvals if you approve requests), shows how many findings are waiting and when the oldest was received, and Review opens External access.
Turn on detection
Detection is off in every workspace until someone turns it on, and nothing is recorded until then. A user with the security_admin or admin role turns it on:
- Go to Policies → Server access.
- In the Direct-login detection card, turn on Detect direct logins.
- Complete MFA verification if you’re asked for it.
Turning detection on or off needs a person signed in to the console. API tokens and service tokens can’t change it.
Detection classifies the logins that arrive after it’s turned on. Logins stored before then stay unclassified and never alert. There is no quiet learning period: the first week is the loudest, because each existing direct-access pattern (one server, OS account and source) alerts once. Each of those findings offers a standing entry, so a pattern you allow stops alerting the day you review it.
A server reports direct logins only when it is covered. Check coverage before you rely on a quiet queue: see Direct-login coverage.
How a login is classified
Each SSH, console and su login is matched against the allowed direct access list and lands in one class:
| Class | When | Who is interrupted |
|---|---|---|
| Standing | A standing entry names the OS account and the server, and either allows SSH from a network the login came from, or allows the console and su and the login is one of those | Nobody. The entry’s logins are reviewed once a week |
| Unexpected, high risk | No entry matches, and the account is shared (including root), a system account, or one Alpacon has not classified, or it is bound to a removed member, or the source is new for this account, or a standing entry names this account on this server but not this source | Reviewers, by email, the workspace’s Slack channel and the bell |
| Unexpected | No entry matches, the account is bound to a current member or an Application, and the source has been seen before | Reviewers, by the workspace’s Slack channel and the bell |
| Not classified | sudo, and logins stored before detection was turned on | Nobody. These appear on the Logins tab only and never open a finding |
A source is new when this account hasn’t logged in directly from it in the last 90 days, or within your plan’s retention window if that is shorter (30 days on Free). A source reported as a hostname, or an SSH login that reported no source address, never matches an entry’s network.
Findings
Logins are grouped into findings, and a reviewer records one decision per finding.
- Unexpected logins: one finding per server, OS account and source while it awaits review. Later logins with the same three join it without a new alert. The exception is a login that raises the finding to high risk, for example because the account’s member was removed in the meantime: that alerts once more. After the finding is disposed of, the next such login opens a new finding.
- Standing entries: one finding per entry per week, Monday to Sunday in the workspace’s time zone, listing that week’s logins under the entry. It is readable while the week runs and can be reviewed once the week has ended.
A login can reach Alpacon well after it happened, for example while the server’s Alpamon is disconnected. Alpamon 2.8.2 and later keep a login made while disconnected and deliver it once they reconnect. A login received more than 60 seconds after the time the server reported is marked Reported late and shows both times. It still opens or joins a finding as usual.
Notifications
| Notification | Severity | Who gets it | How it arrives |
|---|---|---|---|
| A finding opens as Unexpected, high risk, or an open finding rises to high risk | Critical | Reviewers | Bell, email and the workspace’s Slack channel |
| A finding opens as Unexpected | Warning | Reviewers | Bell and the workspace’s Slack channel |
| A member answers Not me, every time, also after the finding was disposed of | Critical | Reviewers | Bell, email and the workspace’s Slack channel |
| A covered server stops being covered | Warning | Reviewers | Bell and the workspace’s Slack channel |
| ”Was this you?” | — | The member the account is bound to | Bell and browser notification |
| ”Was this your automation?” | — | The maintainers of the Application the account is bound to | Bell and email |
The reviewers are the members who hold the reviewer role. When nobody holds it, the workspace’s admins receive these notifications instead, and each one says why. A reviewer alert names the server, the OS account and what Alpacon knows about it, the source and the login time, and links straight to the finding.
The “Was this you?” and “Was this your automation?” prompts go out when an unexpected finding opens and the account is bound to a current member or an Application. They link to the claim view for that one login: see Claims.
The coverage warning goes out at most once per server per day, and never because detection was turned off. If an alert couldn’t be sent when its finding opened, it is sent as soon as it can be and says when the finding opened.
Standing logins, sudo, and work done through Alpacon notify nobody.
The Slack post goes to the channel connected under Integrations → Slack, so it needs the workspace connected to Slack. It names the server, the OS account and the source, so keep that channel to your reviewers and approvers. These emails can’t be turned off in notification preferences; browser notifications follow each member’s preferences. See Notifications & webhooks.
Roles and permissions
Assign these roles workspace-wide. A role bound to one server or one group doesn’t open External access.
| What you can do | reviewer | auditor | security_admin | admin |
|---|---|---|---|---|
| Read the review queue, findings, Summary and Logins | Yes | Yes | Yes | Yes |
| Export evidence (paid plans) | Yes | Yes | Yes | Yes |
| Record a disposition, one at a time or in a batch | Yes | No | No | Yes |
| See Direct logins awaiting review on the dashboard | Yes | No | No | Yes |
| Read the allowed direct access list and the standing-entry requests | Yes | Yes | Yes | Yes |
| Request standing entry | Yes | No | No | Adds the entry directly |
| Add, change or remove standing entries; grant or decline requests | No | No | Yes | Yes |
| Turn Detect direct logins on or off | No | No | Yes | Yes |
A workspace superuser can do all of these. A reviewer can also read the records a finding points to (servers, commands, work sessions, Websh sessions and their records, file transfers and sudo grants), as an auditor can, so the decision can rest on the evidence.
Some actions need no role:
- Any member can answer That was me or Not me about a login.
- A maintainer of the Application an account is bound to can answer That was my automation and request a standing entry from the claim view.
- Anyone who can open a server sees its coverage on the server page, and the time and OS account of each direct login on its Activity tab.
Dispositions, claims, standing-entry changes and requests, the detection switch, Summary and the evidence export need a person signed in to the console. API tokens and service tokens are refused. Adding, changing or removing a standing entry, granting or declining a request, and switching detection also ask for MFA verification.
A person may dispose of a finding about their own login. The record labels it Self-reviewed.
For the permission names behind these roles, see Set permissions and the scopes reference.
Plans and retention
Every plan gets detection, coverage, alerts, the review queue, dispositions, standing entries and the Summary tab. Essentials and Enterprise add Export evidence. On Free the button opens an upgrade prompt.
The summary and the export answer only for the days your plan keeps records:
| Plan | Retention window |
|---|---|
| Free | 30 days |
| Essentials | 120 days |
| Enterprise | 365 days |
A workspace on an agreement with its own retention window uses that window instead. When a period reaches back past the window, the days outside it are left out and named, never counted as zero: see Days outside your plan’s window. Open findings stay in the review queue until they are disposed of, however old they are.
For plan changes, see Plans & billing.