Product update: intuitive access rules, logins worth a look

You can now set access rules intuitively, by completing a sentence, and test how they apply before a real request arrives. Approval cards and audit records keep the rule that decided each request, and only the direct logins that need a look go to a review queue.

Set access rules intuitively, and see them at a glance

Rules you managed separately on Privileged access and Approval rules now live on one page, Admin > Policies > Access rules. Open a rule and it reads as a sentence such as "when an AI agent opens a session on this server, ask an approver." Press an underlined part to fill in that blank, and the sentence becomes the rule. Session, sudo and command rules all work this way, and you drag rules in the list to change their order.

Try it shows what would happen if a person or an agent made a specific request on a server. For example, pick "admins and group managers open a session on servers in alpacon", as in the screenshot below, to see who would be asked to approve, which rules did not apply, and which rule decided. You can also pick an AI agent and give it a name such as Claude Code. No real request is made, and you can try a rule you are still editing before you save it. That way you catch an agent being blocked or let through unexpectedly before it happens.

The Checks before your rules section at the top of the list holds restrictions that no rule can change. For example, a session can't run as another person's own account.

To see how all of these rules apply at once, open the Overview tab. It shows, in one table, how admins and group managers, other members, AI agents and service tokens are handled by request type and risk level, and pressing a cell shows the rule that decides it.

Creating or widening a sudo policy through the CLI, MCP or an API token is no longer allowed. A person has to make that change in the console. An agent can still request sudo, but its token can't grant it. Access rules is available on all plans. Requiring an approver other than the requester is available on Essentials and higher.

Approval cards show the rule that decided the request

The rules you set in Access rules now show up on the approval card when a real request arrives. When an approver opens a request in Execution > Pending approvals, the top of the card says which rule asked for approval. The Evidence tab lists the deciding rule, why you were asked to approve, and the name the agent reported about itself. Whether the requester type was verified is a separate row.

The deciding rule is also recorded on sudo approvals, held commands, work session pages and sudo history, so you can check the record to see why a request was allowed.

Only the direct logins that need a look reach you

External access records direct logins: logins that reach a server without Alpacon, such as SSH with a key or the console. It now puts only the ones that need a look in a review queue, and keeps a record of each reviewer's decision.

Alpacon now matches each SSH, console or su login against your list of allowed direct access. Expected logins are grouped under a standing entry, and only unexpected ones go to the review queue. High-risk logins, such as a shared account or a source never seen before, alert reviewers by email and Slack right away.

Reviewers close each finding as Allowed, Violation or Not a real finding, with a reason. Access that keeps recurring can be added as a standing entry so it stops alerting. The decisions can be exported as audit evidence with Export evidence on the Summary tab. Export evidence is available on Essentials and higher. When an auditor asks how access outside Alpacon is handled, these review records are the answer.

Detection records logins but doesn't block them. It starts once Detect direct logins is turned on under Admin > Policies > Server access.

Also shipped

• The approvals screen lists requests one per row. Selecting a request opens its decision card beside the list, so you can approve or reject without leaving the screen. Settings, theme and sign-out moved to the account menu at the bottom of the sidebar.
• In Websh, a sudo command that needs approval now waits instead of failing, and runs once it is approved. Self-hosted deployments need Alpacon 2.44.0, Alpamon 2.8.4 and alpamon-pam 1.2 or later.
• Each server shows whether sudo through Alpacon is actually enforced, so you can find a server that is missing the PAM module and install it right away.
• All members can see plan limits on the usage page.
• Under Workspace settings > General, workspace owners choose whether pseudonymized session records are used to improve Alpacon AI's detection. It is on by default, except for workspaces that started on the Enterprise plan.
• This release includes security improvements. We recommend updating self-hosted deployments.

Behavior changes

• Creating or widening a sudo policy through the CLI, MCP or an API token now fails with sudo_policy_console_only. Narrowing or deleting a policy still works through any channel.
• alpacon approval ls now lists the requests you can decide. Use --my to see your own requests.
• Creating a server no longer makes its creator the maintainer. Root and manage access follow the maintainer role.
• On Windows, commands still running when the agent restarts are ended. Run long work as a scheduled task or service.