Product update: what the audit log stops keeping—and stops missing

Command audit records are now safer, with more precise control over server access and approval requests.

Command audit trails travel far. They stream into SIEMs, remain on record for years, and become part of audit evidence.

This release keeps plaintext credentials out of that trail and adds visibility into direct access outside Alpacon. Approval rules can now distinguish who is making a request and which servers they are targeting. Notification preferences have also moved from the workspace to each user.

Commands containing credentials are refused before execution

Before this update, a credential entered directly on a command line could be copied anywhere the audit log was sent. Rotating the credential did not remove those copies.

Alpacon now refuses the command when it is submitted through the CLI, command API, or MCP, before it runs. The audit record stores a redacted command instead of the plaintext credential.

The check covers recognizable credential formats, including:

• A -p or --password flag
• A KEY=VALUE secret such as PGPASSWORD=...
• A user:pass@host connection string

Pass the secret through the write-only environment variable field instead. In the Alpacon CLI, use --env="KEY". The CLI reads the value from your environment without placing it in the command submitted to the server.

When Alpacon refuses a command, the CLI explains why and shows the correct form to use. The MCP connector passes the same guidance back to the agent.

Submitting the same command again will produce the same result. Rewrite it to use --env before retrying.

Direct SSH access can now appear in the console

For environments that close external SSH ports and allow server access only through Alpacon, the access path is already limited to one route. Other environments may need to keep direct SSH access open for operational reasons. In those cases, direct connections may be the ones a security team most needs to see.

Alpamon can now detect direct SSH access on the host and report it to Governance → External access. Once detection is enabled, the console shows connections that did not pass through Alpacon.

The records are organized by server, username, service, and remote host. This feature is optional and begins collecting events after external-access detection is enabled in the security settings.

Approval rules can now include the requester and target server

Under Policies → Approval rules, an approval policy can now consider who made the request and which server it targets.

The requester can be a user or an agent, and the rule can also consider the requester's role. The target can be an individual server or a server group. These conditions can then be combined with the command's risk level.

For example, a custom rule could automatically approve commands up to HIGH for users with the admin role working on the staging server group.

Custom policies take precedence over the built-in defaults.

You can also set an approval floor for the highest-risk commands. These commands must wait for human approval even when another condition would allow them.

Rules can carry an expiration date as well, preventing an exception created for a specific task from remaining active after the work ends.

A rule can also use the runtime engine's confidence in its assessment. This allows uncertain decisions to be routed to a person without sending every request for manual review.

Choose which notifications reach you

Open Notification preferences in your personal settings to choose which notification categories reach you through email, push notifications, or Slack DM.

These choices apply only to you. You can mute alerts you do not need without changing notification behavior for the rest of the workspace.

The notification bell is quieter too:

• Repeated reminders for the same approval appear as one item with a count.
• One action marks every notification as read across both sources.
• If the approval list is already open, it updates in place instead of stacking toast notifications over the page.

If push notifications stop arriving, the console explains why and shows how to turn them back on. Notification text also appears in the recipient's language rather than the server's configured language.

Also shipped

• View a user's effective permissions in one place and see why a specific action was denied.
• Service tokens are issued when requested and activated when approved. The key remains visible while the request is pending.
• Service-token activity appears in audit history again. Internal system commands are excluded based on who executed them rather than through a blanket filter.
• alpacon event watch streams the live event channel in the terminal.
• Reboot, shut down, upgrade, and refresh servers from the Alpacon CLI.
• When a sudo call is denied, agents receive the reason for it instead of an opaque failure.
• Alpamon now installs and upgrades correctly on openSUSE and SLES hosts. Both remain best-effort platforms.
• The 157 server error codes that previously fell back to English now appear in Korean. When a translation is missing, users see readable text instead of a translation key.
• Row action menus no longer get clipped inside tables.
• Modal focus handling and other accessibility details have been improved.
• This release includes security improvements. We recommend that self-hosted customers update.

Behavior changes

Commands carrying credentials are refused with no grace period. The check is active from the release that introduces it. A script or CI job that passes a password on the command line will start failing once you are on that version, and the error message names the fix. Move those values to --env="KEY".