Access rules reference

These tables distinguish session admission, account selection, sudo risk and command execution. Unless stated otherwise, defaults describe enforce with no matching workspace rule. Follow each console section’s notice and preview for the checks that apply. An allow at one check does not bypass authentication, scope, account authority or required MFA.

For context, read How access is decided. For authoring and preview steps, use Access rules.

Actors and credentials#

A session requested with a personal API token, through MCP, by a CLI that declares an agent, or by an unidentified client is put into agent mode.

Default session admission rules#

Session admission has no AI command rating. The requester and the person the session is for are separate role conditions.

For a session spanning several server groups, the decisions are combined so a more restrictive target is not lost. Account rules can make an otherwise allowed request stricter. A rule based only on a self-reported agent name cannot remove the human-approval requirement.

Default account rules#

These are account-classification defaults. Their effect also depends on the deployment’s account-policy enforcement and the account’s actual reach. The account selection guide covers available choices; the table is not a promise that every listed account is selectable.

Another person’s personal account is a hard refusal in every mode, before rules or advisory can relax anything. It also applies to sudo, su and runuser switching into that account. A user-switch command whose target cannot be determined is refused. For other accounts, Alpacon still checks reach, direct-root settings and whether the session was approved for that account.

Default sudo rules for people and agents#

This table is the in-session sudo risk decision, not the session-admission rule or a final grant. The work session must include sudo, the caller must have account authority, and a person must still have the required recent MFA verification.

A workspace rule can change the risk outcome, but a Critical rating cannot resolve to automatic sudo approval. An explicitly reviewed Critical rule can request approval. A person’s approval of a held command can cover sudo explicitly visible in that line, including Critical, without overriding scope or account checks or a workspace deny/quorum requirement. Unseen sudo inside a script or wrapper is not covered by that approval.

Terminal sudo has additional authority checks. A matching session policy that substitutes session approval for MFA is considered before one-time approval and ordinary risk/MFA checks. Otherwise, the deployment must support step-up MFA. After the risk check, workspace admins, or owners and managers of a group bound to the server, or people with a matching standing sudo policy, can proceed with MFA; other people need approval and then MFA.

The console separates Web terminal from CLI and API. Follow the selected section’s notice and Try it. When Web terminal shows The rules under Commands decide sudo here too., the sudo rules under CLI and API also decide web-terminal sudo; standing authority and MFA checks still apply.

Default service-token execution rules#

Service-token sudo uses a separate risk policy. That policy also decides what happens when AI rejects a token command that has no work session. The token’s scopes, account, server reach and pre-approved commands/files remain required.

Under enforce, the token risk policy uses these defaults:

Under enforce, a command explicitly rejected by AI is refused even without a rating. This differs from an unrated result caused by an outage. Under enforce, no risk rule can auto-approve CRITICAL token execution. On Alpacon Cloud under enforce, a command matching a pre-approved ledger entry is still refused at the critical ceiling.

Under enforce, a token sudo policy outcome requiring one or more approvers becomes a refusal. A token command without a work session never waits for approval and is refused at CRITICAL under enforce. Advisory automatically approves token execution at the risk check, including at the critical ceiling.

On Alpacon Cloud in either mode, a command with no matching pre-approved ledger entry is refused, as is a command whose ledger lookup fails. An allow in this table does not promise execution when verification or pre-approval is unavailable.

A command attached to a work session can enter that session’s command-approval path; a human approval covering sudo in its visible line can authorize it, subject to remaining restrictions. Do not infer token behavior solely from an AI-agent label.

The workspace must allow sudo. On a default self-hosted deployment, service-token sudo is refused; a risk table alone does not enable it. See Service tokens for credential setup and deployment requirements.

An application/token condition applies regardless of group membership unless a group condition is also included. A group-only restriction does not match an ungrouped server. Test the concrete token and an ungrouped target when reviewing a restriction.

Default command and file-execution rules#

For commands that have passed verification, the built-in command rules are evaluated in this order:

An approved-file match covers the reviewed bytes, server, account and arguments. A changed file does not inherit it. A matching workspace rule or a departure from the session’s purpose can still require review; an approved-file match is not an unconditional bypass.

An ordinary Allow rule does not turn AI rejection into verification. Where human review of an AI rejection is available, a person must decide whether to approve that command. Advisory and service-token handling have the qualifications described on this page.

Commands typed in a web terminal do not use this per-submitted-command policy. Their sudo is checked separately. If a deployment only records command-approval outcomes, its notice says commands are not held for these rules. See Verified file execution for the file workflow.

Matching, order and expiry#

Within each approval-rule action, the first matching enabled, unexpired workspace rule wins over built-in defaults. All conditions on that rule must match. A missing value does not match a condition that needs it. When no workspace rule matches, the built-in rules decide.

Set order using the console list; a new rule is added after existing workspace rules for its action. An optional end date must be in the future when saved. A rule without an end date keeps applying until disabled or deleted. Expired and disabled rules do not decide, and deleting a rule leaves the remaining rules and defaults in effect.

This ordering is not one global list for every access check. Hard account refusals, session limits, standing sudo authorization and recent-MFA checks retain their own effect. Session rules naming a declared agent are evaluated separately and can only make the otherwise applicable result stricter. The preview shows the selected path and the rule that decided it.

Conditions by action#

The console exposes a subset of the supported conditions. Existing conditions without an editor field are kept when editing; the presence of a condition in a stored rule does not mean the editor can create it.

Requester and assignee roles are global roles, not user-group membership. A server group selects targets. Declared agent names are matched without a version; use the agent requester class to express who acts, and an optional name to narrow it.

The offered session account kinds are own account, shared/system account and root. Existing other-account conditions remain visible as stored, but cannot lift the hard refusal on another person’s account. Use sudo command patterns for standing policy matching and token command patterns for token pre-approval.

Outcomes and approvers#

The requester may approve by default where they are an eligible approver. A rule can forbid self-approval. If nobody else may approve, the request is refused instead of waiting indefinitely. The preview identifies the eligible approvers and shows when fewer are available than requested. Approver resolution checks role routing first, then group bindings and workspace-wide bindings, then the workspace’s active Superusers. Group and workspace bindings both contribute eligible approvers. If a configured role has no active holder, resolution falls directly back to active Superusers.

Stored multi-stage rules are treated as one approver group using the first stage; they are not a sequential approval workflow. Session-bound MFA substitution and one-time sudo approval are distinct from a standing terminal policy’s allow-after-MFA outcome.

Risk ratings and signals#

Risk bands are INFO, LOW, MEDIUM, HIGH and CRITICAL; unrated means no band is available. They are categories, not a published numeric score range. Low AI confidence is a separate condition from a LOW risk band.

The purpose and wrapper checks apply under every sudo rule in enforce, including workspace Allow rules. A custom Allow does not remove them. These checks can only make an automatic result stricter; they do not relax a deny or a higher approval requirement. The console does not offer editable signal lists. Configure its exposed conditions and outcomes instead.

The preview uses a supplied rating and does not run AI, execute a command or create a request/grant. It is a console feature, not a public CLI or MCP evaluation API.

Advisory and enforce#

Enforce applies execution-control outcomes. Advisory records judgments without enforcing the risk decision, including Critical and a session’s manual sudo-approval requirement. Under advisory, session admission, sudo and command execution never create an approval request. Requests for a permission the person does not hold, such as a standing sudo policy, service-token issuance or changes, or username or account approval, still go to approvers as usual. New sessions do not wait for execution-control approval, but account denies still apply.

Authentication, credential permissions, session scope, account denies, token access rules and inline-credential checks remain. They still refuse actions they do not permit. Terminal sudo with no standing authority or matching policy is refused with sudo_no_authority. Advisory is not universal sudo permission.

Switching posture does not auto-approve pending requests. They retain their existing expiry rules. A new request uses the current posture. See Server access for workspace configuration.

Plan and permission availability#

MFA controls also depend on the deployment’s identity provider and supported settings. A disabled control is not permission to bypass the requirement. Current deployment notices and the preview determine which rule surface is effective.

Related error codes#

Use the serialized lowercase code and, when supplied, the refusal’s gate, missing and approval reference. Read the English hint for guidance; programs should use the structured fields. Do not infer a pending approval request from the code alone.

For recovery steps, use PAM and sudo issues or Command troubleshooting. Error messages are maintained in the generated catalog; these tables explain which decision to investigate.