Workstations

Fleet management for every AI-agent workstation in your organization. Know who is using agents, what they are working on, whether their environment is hardened, and which versions are deployed from a single dashboard.

Why fleet visibility matters

AI agent runtimes give developers extraordinary power. A single session can read files, execute shell commands, make web requests, and modify your codebase. Without centralized visibility, security teams are blind to:

• How many developers are using Claude Code, Cursor, Codex, Gemini CLI, Google Antigravity, Windsurf, Copilot, or Cowork.
• Whether sandbox mode and hook coverage are healthy across the fleet.
• Which workstations are running outdated versions with known issues
• What projects agents are operating on right now

AgentKeeper Workstations solves this. Each connected agent reports a heartbeat and source badge, giving you real-time fleet intelligence with minimal developer friction.

How it works

Workstation registration is source-aware:

• Claude Code registers through the SessionStart hook, which sends POST /api/v1/claude-code/checkin. The plugin path uses a command SessionStart hook so it can also report Inventory Lite data for skills, MCP servers, and installed plugins.
• Cursor, Codex, Gemini CLI, Google Antigravity, Windsurf, and Copilot register on the first hook event that reaches POST /api/v1/evaluate.
• Cowork registers through the Cowork installer/status check-in and refreshes heartbeat on hook events.
• MDM preseed detection can register a workstation before runtime activity when Jamf, Iru/Kandji, or Intune reports known AI IDE presence or AgentKeeper hook coverage through POST /api/v1/runtime/managed-coverage.
• Native Linux RPM enrollment registers a device with provider agentkeeper and install source native_linux_rpm. Its peer-authenticated broker reports package/service state plus per-surface discovery for each explicit target user; no fleet API key or device credential is exposed to that user.

For Claude Code, the SessionStart check-in:

1. Authenticates the request using the API key in the hook configuration
2. Extracts identity: stable machine_id first, then hostname from the hook payload or X-Hostname header
3. Creates or updates the workstation record in the database with platform, Claude Code version, sandbox status, and git remote
4. Records a session with the working directory, git remote URL, and session ID for activity tracking
5. Returns the shield policy so the Claude Code session knows the enforcement configuration (strict/moderate, warn/block)

Subsequent hook calls update the heartbeat timestamp, keeping the online status current while the agent is active.

Developer starts Claude Code
        |
        v
SessionStart hook fires -> POST /api/v1/claude-code/checkin
        |
        v
Host record created/updated in database
        |
        v
Shield policy returned to session context
        |
        v
PreToolUse / PostToolUse hooks keep heartbeat alive

No manual registration. The developer installs the plugin or hook config, triggers one supported event, and their workstation appears in your fleet automatically.

Fleet table

The Workstations page at /workstations displays every registered workstation as a triage table. The list answers which machines need attention first. Detailed posture evidence lives on the workstation detail page.

Active sessions are shown inline next to the hostname when a developer is currently working.

Protection states

The Protection column presents Runtime evidence for operators without changing the raw state stored by the backend.

When supported AI-agent activity is persisted and the next heartbeat reports a healthy classification, a Standby workstation moves to that healthy state. An explicit failure moves it to Degraded, while a stale Runtime heartbeat becomes Unknown. For a Standby workstation, the detail page keeps the raw backend state and restart_required value under Advanced diagnostics.

Risk states

The list treats unknown telemetry as unknown, not failed. Use the detail page Metadata tab to review full install provenance, MDM aliases, stable identifiers, sandbox, version, baseline, activity, anomaly, and compliance evidence.

Source filtering

Filter buttons appear above the table for every connected source: Claude Code, Cursor, Codex, Gemini CLI, Google Antigravity, Windsurf, Copilot, and Cowork. Each filter shows a count badge. Workstations connected to multiple products show compact source chips in the IDEs column.

MDM-preseeded and Native Linux RPM hosts can also be filtered by Shadow AI present or Missing expected hook. Linux/provider filters distinguish the signed native package path from MDM evidence. Runtime health filters show Runtime standby, Runtime degraded, Runtime missing, and Runtime unknown from the presentation state. Standby is excluded from Runtime degraded. These filters use setup/runtime evidence, not Activity volume, so they can show a machine that needs install attention before the IDE has launched.

Fleet stats

Six stat cards sit above the fleet table, giving you an at-a-glance health summary:

When a workstation shows Tamper evidence, inspect Activity for control integrity events, repair managed hooks through MDM, and use a scoped security-testing exception for authorized retests. See Control integrity.

Version distribution

When your fleet reports multiple agent runtime versions, a visual bar chart appears below the stat cards. Each version gets a colored segment proportional to its count, so you can see at a glance how fragmented your fleet is and who needs to update.

Workstation limits by plan

Existing workstations stay visible and keep their history. New workstation registration is limited by plan, so a Team organization can enroll up to 20 workstations before upgrading to Enterprise.

When a new workstation is over the plan limit, AgentKeeper rejects registration with a plan-limit message before creating another host record. Existing workstations continue to check in and evaluate policy normally. Team organizations that were already above 20 during the packaging cutover keep their existing evidence, but should move to Enterprise before adding more machines.

Upgrade your plan

Onboarding

First-time users who visit the Workstations page see a wizard-style setup flow instead of an empty table. The wizard:

1. Asks which agent surface you are securing.
2. Shows the recommended setup path for that surface.
3. Generates an API key inline with a one-click button, no need to navigate to Settings.
4. Shows the connect command for Claude Code or links to the relevant setup guide for other agents.
5. Polls for the first workstation and auto-refreshes the page when it connects.

For team deployments, use GitHub Repo Hooks or Enterprise install to distribute runtime coverage without relying on each developer to install manually. Use provider appendices only for MDM upload mechanics.

Hooks configuration

Under the setup wizard, an advanced panel shows the raw hooks JSON configuration with your API key pre-filled. This is the configuration that gets written to .claude/settings.json (project) or ~/.claude/settings.json (global):

{
  "hooks": {
    "UserPromptSubmit": [
      { "matcher": "*", "hooks": [{ "type": "http", "url": "https://www.agentkeeper.dev/api/v1/claude-code/evaluate", "headers": { "Authorization": "Bearer ak_live_..." }, "timeout": 10 }] }
    ],
    "PreToolUse": [
      { "matcher": "*", "hooks": [{ "type": "http", "url": "https://www.agentkeeper.dev/api/v1/claude-code/evaluate", "headers": { "Authorization": "Bearer ak_live_..." }, "timeout": 10 }] }
    ],
    "PostToolUse": [
      { "matcher": "*", "hooks": [{ "type": "http", "url": "https://www.agentkeeper.dev/api/v1/claude-code/audit", "headers": { "Authorization": "Bearer ak_live_..." }, "timeout": 10 }] }
    ],
    "SessionStart": [
      { "matcher": "*", "hooks": [{ "type": "http", "url": "https://www.agentkeeper.dev/api/v1/claude-code/checkin", "headers": { "Authorization": "Bearer ak_live_..." }, "timeout": 10 }] }
    ]
  }
}

A copy button lets developers paste the entire configuration in one step.

Adding workstations

The Add workstation button in the top-right corner opens a slide-out panel with the same guided setup flow as onboarding. This is useful when onboarding new team members or setting up additional machines.

The Add workstation flow supports Claude Code, Cursor, Codex, Gemini CLI, Google Antigravity, Windsurf, GitHub Copilot Agent Mode, and Claude Desktop / Cowork from the same panel. Pick the agent surface, follow the guide, and wait for the first check-in.

Developer identity enrichment

When your organization has an Identity Provider connected (Okta, Azure AD, Google Workspace, etc.) via the Identity Providers integration, AgentKeeper enriches the Developer column:

• Display name from the directory replaces the raw username
• Department and job title appear as secondary text below the name
• Matching uses the session's user hint against the directory user's email prefix and display name

This transforms the fleet table from a list of hostnames into a people-centric view of who is using Claude Code and where they sit in the organization.

Session tracking

Claude Code SessionStart creates a session record with:

• Hostname and developer username
• Claude Code version and OS
• Sandbox enabled/disabled
• Working directory (cwd)
• Git remote URL (the project being worked on)
• Start time, last seen time, and end time

Other agent surfaces create or update sessions when their hook payload includes a session ID. Sessions feed the Sessions (7d) column in the fleet table and the sessions today count in the page header. The working directory and git remote are used to determine the current project shown in the fleet table when those fields are reported.

Host detail

Clicking a workstation hostname navigates to the host detail page, which provides deeper information:

• Overview: shield status, security insights, score history, scan history
• Checks: phase-by-phase pass/fail details from connected endpoint telemetry and hook check-ins
• Monitoring: shield events, threat detection timeline, active sessions
• Metadata: endpoint runtime protection state, credential state, policy fetch health, last command preflight, last HTTP evaluate, last self-test, last live event, repair result, and restart-required state

Each workstation is a full host record in AgentKeeper, meaning it gets the same security intelligence (insights, CVE audit, score tracking) as any other monitored host.

Frequently asked questions

Do developers need to do anything special?

No. Once the plugin is installed or hooks are configured, the workstation registers automatically on Claude Code SessionStart or the first supported event from another agent surface. There is no separate "register workstation" step.

What if a developer changes machines?

Each machine gets its own workstation record based on hostname. When a developer moves to a new laptop, the new machine registers as a new workstation. The old one will show as offline after 15 minutes of inactivity.

Can I remove a workstation?

Workstation records are managed from the host detail page. Removing a host removes it from the fleet table. The workstation will re-register on the next Claude Code session unless the hooks are removed.

What data is sent during checkin?

Claude Code SessionStart sends hostname, machine ID, working directory, git remote URL, Claude Code version, OS platform, sandbox status, and session ID. With the plugin Inventory Lite hook, it also sends names and metadata for configured skills, MCP servers, and installed plugins. No file contents or code are transmitted during check-in; skill inventory sends only a short preview and hash for risk scoring. Tool-level data is sent only when a hook event is evaluated or audited for threat detection.

Does this work with the plugin or repo hooks?

Both register workstations. The plugin method (/plugin install agentkeeper, then /agentkeeper:connect) configures command-based SessionStart and reports Inventory Lite. Repo-level .claude/settings.json usually uses HTTP SessionStart, which registers the workstation but cannot read local inventory unless you also deploy a command scanner through MDM or the gateway path.

What happens when I exceed my workstation limit?

New workstation registration is blocked once the organization reaches its plan limit. The local hook returns a plan-limit message and no new host record is created. Upgrade to Enterprise before rolling AgentKeeper out to additional machines.