Choose how far commands are gated, confirm the server account during approval, and give automation credentials of its own.
Not every server needs the same amount of control. Where it is not warranted, waiting on an approval for each command is its own cost.
Each workspace now decides how far its commands are gated. You can keep every command judged and recorded while nothing is held, or read what those judgments say and move to enforcing on the strength of them. Approval requests also show the server account a session will connect as, and a service token can be set up while its approval is still pending.
Evaluate every command, then decide when to enforce
A new Execution control card is available under Policies > Server access policies. It determines whether AI command verification and command signature verification can hold or block commands in your workspace.
Enforce is the default. In this mode, verification results control execution: commands may be held for approval or blocked. Commands rated CRITICAL are always blocked, even if another rule would otherwise allow them.
In Advisory mode, every command is still evaluated and recorded in the audit trail, but execution is never interrupted. Commands run without approval and none are blocked. This lets you review how your team's actual commands would be judged—and which ones would have been held—before switching to Enforce.
Advisory mode changes only command enforcement. Sign-in and identity verification, roles and permissions, token authorization, session scope and expiration, session recording, audit logging, and the rejection of commands containing credentials continue to work as before.
Only a workspace superuser can switch modes. If your deployment runs the exec-sudo gate in monitor mode, switching to Advisory does not change how sudo behaves.
The server account is confirmed during approval
Connecting to a server means choosing an account on that server. You select it under Connect as when creating a session, with your own account selected by default.
Only accounts you can actually use are selectable. The rest are listed beneath them, showing how many are unavailable and why: bound to another user, bound to an application, or direct root access disabled for the workspace. Where an administrator can make an account available, the entry says to ask for a rebind, so you can tell immediately whether to contact someone or choose another account.
Your selection is included in the approval request. The approver can see which account the session will use and either approve it as requested or replace it with another account they are authorized to select.
The approved account carries through the rest of the workflow. Alpacon CLI example commands, the Run button in the console, and WebFTP auto-connect all use it.
The record remains after the session ends. Command details show which account ran each command, making it possible to compare what was approved with what actually happened.
Automation no longer needs to borrow a person's credentials
A service token is a credential for a non-human actor that needs access to your servers, such as a CI pipeline, deployment script, or AI agent. Instead of sharing a person's token, you can issue a dedicated token directly to the application.
Create an application under IAM > Applications, then issue tokens for it. Each token has a defined scope that determines what it can do and how much risk it carries. Issuing a token with a high-risk scope may require administrator approval.
Once the token is used to sign in to the Alpacon CLI, the automation can run without a user signing in.
This release changes the order of issuance and approval. A token is now created as soon as it is requested, and approval activates it. The key remains visible while approval is pending, so you can finish configuring a CI job or agent in advance. The key cannot be used to run anything until the token is activated.
A request blocked by an access rule now comes back with a permission error naming the rule. The Alpacon CLI prints it, so a broken integration and a rule doing its job no longer look the same.
The application itself records its service type, such as AI agent. Server access pins the account it uses on each server, one per server, so an agent reaching several servers connects as a known account on each. Credentials holds its tokens, Roles its permissions, and Activity what it actually ran.
Register openSUSE and SLES servers from the console
Registering a server starts by asking what its OS is, and SUSE family is now one of the answers, next to Debian, RedHat, macOS, and Windows. It covers openSUSE Leap, openSUSE Tumbleweed, and SLES, and returns an installation command the same way the other options do.
Also shipped
- Anyone with approval permission can now open the approval console; workspace superuser access is no longer required.
- An agent must declare its purpose before a held command is added to the approval queue.
- When a request has multiple approvers, each decision is recorded and resolved together. Once the request is decided, notifications for the remaining approvers are cleared.
- Permission to manage command and file ACLs is determined by token-binding permission.
- If you are already viewing a session, approval requests appear inline instead of accumulating as notifications over the page.
- Links to completed approval requests now open the relevant request instead of an empty list.
- When an account cannot be deleted, the console explains what is preventing its deletion.
- Ctrl+Shift+C and Ctrl+Shift+V now work in Websh.
alpacon note lsnow handles--tailand--servercorrectly and displays whether a note is pinned and when it was added.- A misconfigured self-hosted AI connector now fails at startup rather than when a user first signs in.
- This release includes security improvements. We recommend that customers with self-hosted deployments update.
Behavior changes
An off-purpose sudo command now exits with code 4 instead of 1. It is classified as pending approval rather than failed. When --wait is used, the command waits up to five minutes for an approver's decision instead of failing immediately. Scripts that branch on exit codes must be updated.
Allowed-domain settings and domain-based signup have been removed. Users no longer join a workspace automatically just because their email address matches a registered domain. If you relied on this flow, switch to invitations.
