Product update: what your AI agents did, and why their commands were stopped

Three changes stand out in this update.

• The dashboard's Security view: see what your agents did, which commands were refused and why, on one screen. You no longer gather the monthly numbers from each audit screen.
• Refusal reasons: when a rule refuses a command, the agent gets the reason in its response. When an approver rejects one, the agent is told an approver rejected it, and through MCP it also gets the approver's reason. An agent is less likely to guess at the cause and try another way.
• File execution approvals: approve a script request after reading the file that will run. You no longer approve a script by its name alone.

See what your AI agents did, and why their commands were stopped, on one screen

In every workspace, View at the top of the Dashboard now lets you pick the screen for your role:

• Operations: your sessions, requests and alerts
• Management: approvals, live sessions and direct logins
• Security: access control posture, AI agents and threats

If you report on AI agent use every month, you used to gather the numbers from several audit screens. Now they are on one screen in the Security view.

AI agent control breaks agent commands down by source (MCP, CLI, API token or service token) and shows each agent's denial rate and reasons. Denials fall into four categories: not allowed, judged risky, approval rejected or unanswered, and integrity or system. In the screen above, an approver rejected 3 of the 11 commands Claude Code sent.

The same screen also shows:

• Access control posture: four indicators with a 30-day trend (managed assets, access via Alpacon, session analysis and reviewed direct logins)
• sudo privileges: which policies granted sudo
• Account and token review: accounts inactive for 90 days and service tokens close to expiring

Click a number to open the records it counts. You can answer questions like "How many agent commands did we stop last month, and why?" with the counts and the records. On Free, the lists show only your own records from the last 7 days.

Agent names come from the agents themselves and are labelled Self-reported. The dashboard is available on all plans, and each item shows only when the viewer can see the records it counts. View appears when you have more than one view to choose from.

When a command is refused, the person and the agent both know why

Without a refusal reason, an agent may guess at the cause and try another way. Now the MCP server, not just the Alpacon CLI, returns the reason the server recorded to the agent.

Commands refused outright

For example, Claude Code tried to run a command as root in a Work Session that wasn't approved for that account. The request was refused right away with this reason:

reason        : the command runs as an account the session was not approved for; a session runs only as the account named when it was created
required scope: command
target server : prod-web-01-demo

An AI agent's Work Session runs only as its approved account, whether the request comes through a command, Websh, the editor or WebFTP.

Commands that need a person's approval

A command that needs a person's approval is held until someone decides. Here's what happens with sudo systemctl restart nginx.

1. The agent is told the command is held.

Warning: Approval required—this command is held for human approval in the Alpacon console (web). It runs automatically once approved; pass --wait (or --wait-approval DURATION for a longer wait) to block until then.

The message tells the agent to wait for human approval. It doesn't tell the agent how to widen its own access. A command held this way runs once approved. If the CLI instead exits with code 4 (pending approval) without saying the command runs once approved, run the command again after it is approved, or pass --wait on the original request.

2. An approver reads the AI check's assessment and decides.

The request appears in the decision panel in Execution > Pending approvals. If the AI check judged the command risky, the panel shows that assessment, and the approver approves or rejects the request after reading it.

3. The agent is told the command was rejected.

Error: command <command-id> was rejected: an approver rejected it (rejection_cause: approval_rejected, rejection_gate: approval).

The response tells the agent that the command didn't run and that an approver rejected it. Through MCP, the agent also gets the reason the approver gave (alpacon-mcp 1.25.0 or later). The Alpacon CLI points to the console for it.

4. The rejection reason is recorded.

The rejected command appears in Audit > Events > Commands. Open it to see its Rejection reason and what to do next.

On a personal API token's detail page, Refused commands lists commands sent with that token that were refused before they ran, with each reason, newest first. The Access rules reference in the docs explains what each refusal code means.

Approve what a script will run, not just its name

An agent can run a script in two ways: as a command, like bash /opt/deploy.sh for a script already on the server, or as a file execution, which sends the script file itself to Alpacon.

For a command, Alpacon receives only the command line, so the approver could see only the script's name, not its contents. Now the decision panel for such a command request (Execution > Pending approvals) shows this notice:

The script's content isn't shown until the requester resubmits it as a file execution.

Rather than approve without seeing the content, the approver can reject the request and ask for it as a file execution. An agent uploads the file and asks to run it in one step, with alpacon exec --file … --upload in the Alpacon CLI or one execute_file call in MCP.

When a file execution request comes to an approver, the decision panel shows the file's path, the account it runs as and the file's SHA-256 digest.

Below that, the whole script is shown line by line, with the AI check's summary. Approval covers running this file with these arguments, on this server, as this account. Alpacon checks the file's digest before it runs, so changing one byte of it needs a new approval. Other files the script calls are not covered.

An approver reads the script before it runs only when a file execution request comes to them. Under the default rules, scripts the AI check judges risky come for approval, and low-risk scripts run right away. You can still read what a low-risk script ran afterward in its command detail. To read low-risk scripts before they run too, add a rule in Admin > Policies > Access rules.

• Verified file execution requires AI review enabled and Alpamon 2.8.3 or later on the target server.
• If the same command has been approved several times, the panel also notes that it could be set to Always allow when resubmitted as a file execution, if the rule allows it.
• Standing approvals are listed in Audit > Approved file executions.

Also shipped

• A session risk analysis that is mailed is also posted to the workspace's Slack channel, with a button that opens the analysis. Available on Essentials and higher.
• The server list shows the alert types on each server and when an offline server last connected. You can also filter the list to the servers you maintain.
• Members who can't approve can follow their own requests on the dashboard, and a request sent for approval because the AI check was unavailable says why.
• If a cloud account lacks the remote-command permission, the Alpamon install stops and shows the reason. You can check again after fixing it.
• The docs were reorganised around tasks, and every page is also served as Markdown so agents can read it directly.
• When HTTPS_PROXY is set on a server, Alpamon connects to Alpacon through that proxy. HTTP_PROXY applies only to plain HTTP addresses, so it doesn't cover the connection to Alpacon. Requires Alpamon 2.8.5 or later.

Behaviour changes

• New personal API tokens can't get command or file-transfer rights, even through * or another wildcard. Existing tokens keep theirs; use a service token for automation.
• An AI agent's Work Session runs only as its approved account across commands, Websh, the editor and WebFTP.
• A requester who can approve their own request is notified first, and other approvers 10 minutes later.
• On Free, a Work Session can't be assigned to someone else.
• MCP no longer resends a command after a timeout or dropped connection; it returns an error saying the command may have run and to check list_commands.
• File transfers and Linux editor requests sent straight to the API are refused if no group is given, or if the account doesn't belong to the given group. Requests through Alpacon are unaffected. Requires Alpamon 2.8.5 or later.