Governed access for AI agents

AI agents now operate real infrastructure—deploying, debugging, running commands. The question is no longer whether to give an agent access, but how to keep that access under your control.

Alpacon’s answer is the same model it uses for people: let AI operate your infrastructure under your control. Most access tools gate who gets in. Alpacon governs what gets executed—by a person, a CI pipeline, or an AI agent—through the same time-bound, approved, and recorded work session.

Why agents need more than a key

Handing an AI agent an SSH key or a long-lived token gives it standing, unbounded access. That’s the same risk as any static credential, but now in the hands of a non-deterministic actor. If the agent is misled or jailbroken, there is nothing to contain the blast radius.

Alpacon removes standing access for agents the same way it does for people: the agent connects as a governed identity, and every action is scoped, approved where it matters, and recorded.

Agents are governed identities

An AI agent doesn’t get its own backdoor. It acts through an Alpacon identity—either a person it works on behalf of, or an application for automation—so it inherits the same identity, role-based access, and audit trail as a human user.

Agents connect through MCP (Model Context Protocol):

  • Hosted: point your MCP client at https://mcp.alpacon.io and sign in with OAuth in your browser.
  • Local: run the Alpacon MCP server yourself (uvx alpacon-mcp).

Either way, no SSH keys or VPN credentials are handed to the AI. It works with Claude, Cursor, VS Code, and other MCP-compatible tools.

Scope control: the work session

Before an agent can run a command, transfer a file, or open a terminal, it opens a work session—just like a person does. The session declares:

  • Intent: why the work is happening (for example, “fix nginx 502 on prod-web-1”)
  • Scope: which operations are allowed—web terminal, file transfer, command execution, port forwarding, or privilege elevation
  • Servers: the specific machines it can touch
  • Expiry: when access ends automatically

The scope is a hard ceiling. An action outside the session’s scope is refused—even privilege elevation, and even for an otherwise-privileged identity. A misled or jailbroken agent cannot exceed what its session was opened for, because there is no standing privilege to fall back on.

See Work sessions for the full model.

Real-time control for sensitive actions

Routine work runs within the session’s scope. Sensitive actions are gated while they happen:

  • Privilege elevation (sudo) and other high-risk actions are held and routed to a human approver. The agent waits for the decision—approved or rejected—before the action runs.
  • An agent can’t impersonate a person. Steps that require a human’s multi-factor verification can’t be satisfied by an agent, so they escalate to a real person instead of quietly proceeding. See sudo with MFA.
  • Every command and transfer is recorded as it runs.

Approval requests reach the right people through the workspace and notifications, so a human stays in the loop for the actions that matter. See Approvals.

Alpacon is extending this runtime control further, so that more of an agent’s actions can be held for review automatically—building toward judging every action as it happens, not only the privileged ones.

One timeline for people and agents

Because people, pipelines, and agents all run through the same work-session model, their activity lands on a single recorded timeline. After a session ends, Alpacon adds an AI risk analysis of what took place.

So when someone asks “what happened on prod-web-1 in the last 24 hours?”, the answer is one timeline that mixes human commands, agent actions, and CI runs—not separate, partial logs to stitch together. See Audit.

Next steps

Last updated: