What Alpacon checks, and what it doesn’t

Approval cards and session views show the line “Policy check, not malware detection.” It means Alpacon compared the request with your workspace’s access rules before it reached you. It did not inspect what the request will do.

What Alpacon checks

Before a request reaches an approver, Alpacon checks it against the workspace’s access rules. A rule can match on:

  • Request type: The kind of access being requested: a session, sudo, or a command, one tab each.
  • Requester: Anyone, a person, an AI agent, or people with a role.
  • Server group: The servers the request targets. Every tab offers it.
  • Agent name: The name the agent declares for itself, on session rules.
  • Assignee role: The role of the person a session is for.
  • AI rating: How the AI rates a command, for sudo in commands and for commands.
  • End date: When the rule stops applying.

A matching rule can allow the request, ask an approver, or block it. By default an AI-agent session waits for a person, even when a Superuser requested it. An Allow rule for AI agents admits an agent session that states its purpose without a person; a session with no purpose waits for a person. If your rules block every agent name except the ones you accept, a request with another reported name is refused, and the agent is told it needs an allowed agent. The rules do not verify which agent is running.

Two more checks apply to the approver:

  • Who may approve: A rule that asks for approval can be set so the person who asked can’t approve it. Otherwise the requester may approve their own request, and the approval record marks it as self-approved. On a deployment that cannot tell the approving client from the requesting one, the person who requested an AI-agent session cannot approve it; add a second approver. If a rule requires someone else and nobody else can approve, the request is refused at once.
  • Step-up and MFA: Where your workspace’s security settings require it, an approver confirms with step-up or MFA before approving.

What Alpacon does not check

  • Malware. The policy check is not malware detection or a security scan.
  • Commands, at admission. This check does not inspect commands or file contents. Read the servers, account, purpose and the command details on the card before you approve. Commands are judged separately while they run, and completed sessions get an AI analysis; see Session features and After the session.
  • Who the agent is. The agent’s name is what the agent’s client reports about itself. Alpacon shows it as self-reported.
  • Sandboxing, EDR and privilege inference. Alpacon does not sandbox what a session runs, is not an EDR or malware-detection tool, and does not work out fine-grained privileges from sudoers or group membership.

Known limits

  • A name rule only tightens. A determined agent can report a different name or none. A rule on an agent’s name can therefore only add requirements, and a changed name can sidestep a rule written for one agent. To require more of every agent, add a rule for AI agents that blocks the request or asks an approver.
  • The approval-card check runs when a request is made and when it changes. It does not repeat while a session is running. Per-action checks, such as sudo on each use, are separate.
  • Advisory mode ends risk-based holds. In a workspace set to Advisory, new work sessions and commands are no longer held or refused because of risk, and the result is recorded. Service token and identity requests, requests already pending, sudo authority and MFA are unaffected.

You configure these rules under Policies > Access rules, on the Sessions, Sudo, and Commands tabs.

Last updated: