Skip to main content

SigmaShake Fleet Dashboard Tour

The Fleet dashboard lives at https://{YOUR_SUBDOMAIN}.fleet.sigmashake.com. Every screen is accessible from the left sidebar once you have signed in with your organization's SSO or service account.

Screenshots

This guide uses text descriptions and component names derived from the live dashboard. Screenshot slots are marked [screenshot TODO] — live screenshots require an authenticated Fleet session and are pending a captured update cycle.

IconScreenMinimum role
⬡Agentsmember
⊞Policiesmember
⊕Enrollmentmember
◈Hub Catalogmember
♡Healthmember
◎Observabilityauditor
≡Audit Logauditor
↗Log Forwardingorg_admin
⚙Settingsorg_admin

Agents​

Route: /agents
Role required: member

The Agents screen is the main device inventory. It shows every enrolled machine with:

  • Label — the hostname reported at enrollment
  • Status — active / idle / stale / offline / tombstoned
  • Last seen — when the agent last sent a heartbeat (default interval: 5 minutes)
  • ssg version — the version currently running on the machine
  • Policy compliance — whether the machine has pulled the latest compiled policy bundle
  • Lifecycle state — the day-scale staleness axis (active → idle@7d → stale@30d → offline@90d)

Actions available per agent (org_admin):

  • Edit label — rename a machine
  • Revoke — force-remove a machine from the org (the machine cannot re-enroll without admin action)

Agents → Coverage (sub-tab): shows the coverage report — which machines in your declared expected-device manifest are enrolled vs. dark (unaccounted for). Use PUT /api/v1/orgs/:org/coverage/expected to upload your machine manifest.

Related: Adding a Device

Policies​

Route: /policies
Role required: member (read); policy_author (create/edit); org_admin (approve)

The Policies screen manages governance rule bundles that are pushed to all enrolled agents.

Lifecycle of a policy:

  1. Draft — a policy_author creates or edits the policy using a ruleset slug from the Hub Catalog.
  2. Submit for review — the author submits the policy; it enters a pending-approval state.
  3. Approve — an org_admin approves it. The policy transitions to active.
  4. Compile — clicking Compile policies or triggering the compile API merges all active policies into a signed bundle stored in the BUNDLES KV. Agents pull the bundle on their next heartbeat (≤ 5 minutes) or immediately if a real-time poke is sent.
  5. Archive — superseded policies can be archived to remove them from the active bundle without deleting the audit history.
Change gate

No policy change reaches enrolled agents without an explicit approve → compile step. This is the diff-approval gate: an admin must review and approve before any rule change takes effect fleet-wide.

Related: Fleet Policies and Rollouts

Enrollment​

Route: /enrollment
Role required: member

The Enrollment screen manages enrollment profiles — pre-authorized tokens that let a machine enroll without an active Workspace browser session.

Each profile shows:

  • Name — a human label (e.g., "Dev team Q3", "CI runners")
  • Uses remaining — how many more machines can enroll with this token
  • Expires at — when the token stops accepting new enrollments

Create enrollment profile — generates a new profile token (ssg_ep_…) that you can distribute to developers or embed in onboarding scripts.

Download installer — generates a platform-specific installer script pre-seeded with the enrollment token for zero-touch onboarding.

Related: Adding a Device

Hub Catalog​

Route: /hub
Role required: member

The Hub Catalog screen shows the governance rulesets from hub.sigmashake.com that are available to add to your fleet policies.

  • Browse rulesets by category.
  • Click Add to policy to include a ruleset in a new or existing policy.
  • Rulesets are identified by a slug (e.g., protect-database, agent-safety-baseline) — the same slugs used in manual policy configuration.

Health​

Route: /health
Role required: member

The Health screen shows the overall posture of your fleet at a glance:

  • Active agents — count of agents that sent a heartbeat within the last 5 minutes
  • Policy compliance — percentage of agents running the latest compiled policy bundle
  • Coverage rate — enrolled / expected machines (from the coverage manifest)
  • Rollout status — progress of any active MDM update rollout

The Fleet health board also shows per-agent compliance deviations — machines that reported a different policy version than what the control plane compiled.

Observability​

Route: /observability
Role required: auditor

The Observability screen exposes time-series metrics and fleet-wide rule analytics:

  • Decision mix — ALLOW / DENY / ASK / FORCE / LOG / SHADOW breakdown across all agents over the selected time window
  • Rule effectiveness — which rules fire most frequently; which categories generate the most blocks
  • Agent distribution — OS, ssg version, and lifecycle-state breakdowns
  • Time-series graph — governance check volume over time, with per-category breakdown

Use this screen to spot anomalous rule-fire spikes, verify that a newly deployed policy is taking effect, and track adoption after a rollout.

Audit Log​

Route: /audit
Role required: auditor

The Audit Log is the append-only, merkle-chained record of every governance decision and admin action in your fleet.

Each event shows:

  • Timestamp — when the event occurred
  • Event type — e.g., agent.enroll, policy.compiled, audit.ingested, agent.unenroll
  • Agent / user — the machine or admin that triggered the event
  • Details — structured JSON payload for the event

Audit verification: events are merkle-chained via emitAdminAudit. Use GET /api/v1/orgs/:org/audit/verify to verify the chain integrity against a given sequence range.

Reports: GET /api/v1/orgs/:org/audit/report generates a structured compliance report suitable for SOC 2 evidence packages. The /soc2 endpoint generates a pre-formatted SOC 2 evidence export.

Updates (MDM Rollouts)​

Route: /updates
Role required: member

The Updates screen manages MDM-style ssg version rollouts — the same mechanism CrowdStrike and Intune use for staged software updates.

Creating a rollout:

  1. Select a target ssg version (must be a published semver).
  2. Define an agent selector — target all agents, a named group, or a filter expression (e.g., os=linux AND version_lt=0.29.150).
  3. Submit the rollout. Each matched agent receives an update directive on its next heartbeat.
  4. Monitor progress in the rollout status table: dispatched / converged / succeeded / failed / skipped / swept.

Rollout safety:

  • Agents with SSG_FLEET_NO_REMOTE_UPDATE=1 decline directives and report skipped.
  • Agents installed via brew, pip, or winget also report skipped (they cannot auto-update through the fleet channel).
  • The target version must be strict semver — the agent rejects non-semver values to prevent RCE via package-manager injection.

Log Forwarding​

Route: /settings/log-forwarding
Role required: org_admin
License: Enterprise only

Log Forwarding archives governance audit events to your SIEM. Supported destinations: Splunk HEC, Cribl HTTP-in, Confluent REST v3, and HMAC-signed webhooks.

Adding a destination:

  1. Click Add destination.
  2. Choose the destination type and enter the endpoint URL and authentication credentials.
  3. Click Test to verify connectivity before enabling.
  4. Toggle the destination to Enabled — events begin forwarding on the next archive sweep.

The archive runs on a background cron. Delivery status (last success, last error, delivery count) is visible on each destination card.

Enterprise feature

If your org is not on the Enterprise plan, this screen shows an upgrade prompt. Contact sales@sigmashake.com to upgrade.

Settings​

Route: /settings
Role required: org_admin

The Settings screen covers org-level configuration:

  • SSO — configure your OIDC or SAML 2.0 identity provider (see Fleet SSO Setup)
  • Service Accounts — create and manage API keys for CI/CD and admin automation (format: ssg_sa_…)
  • Members — view and manage org membership; assign roles (org_admin, policy_author, auditor, member)
  • IP Allowlist — restrict Fleet dashboard access to specific IP ranges
  • Org details — display name, slug, and license tier