Identity Intelligence

Identity Intelligence pillar in the LinuxGuard console — cross-server identity profiles, risk scoring, SSH keys, and access patterns.

Identity Intelligence aggregates identity data across all monitored servers into unified profiles with cross-server risk scoring, behavioral baselines, and non-human identity inventory.

The pillar contains six pages accessible from the left sidebar: Identity Overview, Accounts, Groups, Non-Human Identities, SSH Keys, and Access Patterns. This page walks through each sub-section, explaining what it shows, how risk signals are surfaced, and how to interpret the data.

Identity Overview

The Identity Overview page (/identity) is the entry point to the Identity Intelligence pillar. It presents a fleet-wide view of all identities — human and service — aggregated across every monitored server.

Five metric cards appear at the top of the page, each clickable to cross-filter the identity table below:

• Total — all identities discovered across the fleet

• Human — accounts classified as human users

• Service — accounts classified as service accounts

• Dormant — accounts with no recent activity

• High Risk — accounts flagged as high risk by their fleet-wide score

Clicking a card filters the table to show only matching identities. Hold Ctrl or Cmd and click additional cards to build a multi-category selection.

The identity table is sorted by risk score in descending order by default, placing the highest-risk identities first. Each row represents a single identity aggregated across all servers where that identity appears — not a per-server row. The table supports search, paginates at 25 items per page, and offers CSV export.

Risk scoring is a cross-server composite — LinuxGuard evaluates each identity's profile across every server it appears on and produces a single fleet-wide score. Identities crossing the high-risk threshold get the High Risk classification.

Use case: Identify your highest-risk human accounts fleet-wide, regardless of which servers they log into. An account whose risk adds up across several servers will surface near the top before a per-server review would catch it.

Accounts

The Accounts page (/identity/accounts) provides a complete inventory of all accounts across the fleet in an identity-centric view. One row represents one identity, with data aggregated across all servers where that account exists — not one row per server instance.

Key columns include username, type (human or service), risk score, server count, last seen date, and status. The status column surfaces dormancy detection — accounts that have not authenticated recently appear as dormant. The table defaults to risk score descending, showing the most concerning accounts first.

Use this page to audit which accounts exist fleet-wide, verify whether expected accounts are present across the right servers, and spot accounts that have gone dormant but remain active.

Groups

The Groups page (/identity/groups) shows group memberships across the fleet with cross-server correlation. A group that exists on multiple servers appears as a single entry with a server count column rather than duplicated per-server rows.

This view is useful for identifying groups with unexpectedly broad server presence or unusual membership composition. A group appearing on 30 servers where you expected 5, or a group that has gained new members without an accompanying change ticket, becomes visible here.

Non-Human Identities

Non-Human Identities (NHI) are Linux user accounts that run automated processes rather than interactive human sessions. LinuxGuard links each NHI account to the automated work it performs, so you can see what a service account is actually doing across the fleet.

LinuxGuard auto-sorts every non-human identity into one of three tiers based on where the account came from.

System Default accounts are created by the operating system or system packages during installation. These accounts are expected, low-churn, and rarely change after initial provisioning. When a system default account shows unexpected credential aging or configuration changes, it signals potential system-level compromise.

Application Service accounts are created by well-known third-party software during package installation. Package managers typically manage these accounts, so their lifecycle is usually predictable. The primary risk here is credential rotation compliance: application service accounts frequently hold SSH keys used by deployment pipelines, and stale keys in those pipelines can persist long after a rotation policy requires remediation.

Custom Service accounts are everything your organization created for specific automation purposes that does not match the system or application lists. These are your homegrown automation accounts, cron runners, and pipeline service accounts. Custom Service accounts carry the highest operational risk because there is no shared knowledge base: you must verify their purpose, confirm an owner, and establish a credential lifecycle yourself.

Six metric cards appear at the top of the NHI page, cross-filtering the table:

• Total NHIs — all non-human identities across the fleet

• System Default — count of OS/system-package accounts

• Application Service — count of well-known third-party service accounts

• Custom Service — count of organization-defined automation accounts

• Unowned — NHIs with no owner assigned; shows a grace period subtitle when any newly discovered NHIs are still within their grace period before appearing as unowned

• Stale Credentials — NHIs whose SSH keys or credentials require rotation

A classification donut chart shows the proportion of System Default, Application Service, and Custom Service accounts. Clicking a segment filters the table.

The NHI table has eight columns: name, classification, risk level, server count, credential age in days, a freshness indicator (fresh, warning, or critical), owner, and last seen. Available filters include account type, risk level, owner status (yes or no), search, minimum server count, and maximum credential age.

Risk factors for NHIs are credential age, owner assignment, and grace period status. A Custom Service account with no owner, stale credentials, and high server count represents the highest-priority remediation target.

SSH Keys

The SSH Keys page (/identity/ssh-keys) provides fleet-wide visibility into all SSH keys discovered across monitored servers, with classification by algorithm strength, age, and cross-server presence.

Five metric cards appear at the top, cross-filtering the table:

• Total Keys — all SSH keys discovered fleet-wide

• User Keys — authorized_keys entries (user-type keys)

• Host Keys — server host keys

• Inactive (>90d) — keys not observed in the last 90 days

• Shared — keys whose fingerprint appears in authorized_keys on multiple server accounts

Two charts follow the metric cards: an algorithm distribution donut showing the proportion of key types across the fleet, and a key age histogram displaying how many keys fall into each age bucket with severity coloring.

Algorithm Strength

LinuxGuard grades each SSH key by algorithm strength — Critical, Weak, Acceptable, or Strong — with matching severity coloring, so the weakest keys in your fleet are easy to spot. Deprecated or undersized algorithms grade low; modern algorithms grade Strong.

Key Age

LinuxGuard assigns each key an age bucket — from Fresh to Stale — so keys overdue for rotation are easy to spot at a glance.

Cross-Server Sprawl

A key is flagged as shared when the same fingerprint (SHA-256) appears in authorized_keys on multiple server accounts across the fleet. Sprawl severity scales with how broadly the key has been authorized.

The risk of sprawl is compounding: a single compromised credential grants access to every system where that key is authorized. One leaked private key becomes a fleet-wide incident rather than an isolated one. The SSH Keys page surfaces the most broadly shared keys first, enabling targeted deprovisioning before a compromise occurs.

Orphaned Keys

An orphaned key is a key entry that remains in authorized_keys on one or more servers after the account that originally owned the key has been deleted. LinuxGuard finds these keys left behind after account removal, even when they're still authorized on other servers.

Orphaned keys represent persistent access credentials with no associated owner — a particular concern because no active account lifecycle governs their rotation or removal.

SSH Keys Table

The SSH keys table has the following columns: fingerprint (SHA-256, truncatable and copyable), key type, key size, algorithm grade, age and age bucket, posture score, primary owner, and server count. Additional fields visible in the row or detail panel include whether the key is shared (is_shared), whether it is inactive (is_inactive), and a detractor count summarizing negative posture contributors.

Default sort is by posture score ascending — the most problematic keys (lowest posture) appear first.

Available filters: key type (user or host), algorithm grade, inactive (yes or no), shared (yes or no), environment, and tag.

Access Patterns

The Access Patterns page (/identity/access-patterns) provides behavioral analytics for identities across the fleet, with a supervised rollout that administrators explicitly control at every stage — nothing advances or reaches other users automatically.

Analytics starts disabled. Once enabled, LinuxGuard spends an observation period learning baselines, with no anomalies surfaced yet. From there, administrators can promote to a shadow stage, where detection runs and alerts are visible to admins only, and finally to an active stage, where anomalous events and the full behavioral feed become visible to all users. Administrators can revert to observation or disable analytics entirely at any point.

Note: Access Patterns does not surface anomalies immediately after deployment. During observation mode, LinuxGuard learns behavioral baselines for each identity. Anomaly detection only becomes active after observation mode completes and baselines are established.

Observation Period

During observation mode, LinuxGuard records behavioral patterns for each identity and shows a progress bar toward completion. The observation period length is configurable per server group.

Baselines and Maturity

The Baseline Maturity % metric shows what proportion of tracked identities have accumulated enough data to support anomaly detection. Administrators should wait for high maturity before promoting to Shadow mode — promoting too early results in higher false positive rates because immature baselines have not learned full behavioral patterns for the identities they cover.

Stat Cards

The Access Patterns page shows four stat cards whose labels change depending on the active mode:

• Identities Monitored — count of identities being tracked, with how many servers are reporting in

• Anomalous Events (labeled "Behavioral Insights" in observation mode, "Shadow Alerts" in shadow mode) — mode-aware count of behavioral anomalies

• FP Rate — false positive rate with a trend indicator showing whether the rate is improving, stable, or worsening

• Days Remaining (observation mode) or Baseline Maturity % (shadow and active modes)

Activity Heatmap

The heatmap is a 7-day by 24-hour grid. Each cell shows the activity count for a specific day-of-week and hour-of-day combination. Color intensity indicates activity volume — the deepest color marks peak activity cells. An optional overlay highlights statistically unusual activity relative to the baseline.

Heatmap filters include: dimension (combined, SSH, sudo, or other activity types), identity (typeahead search by name), server group, and time range (30, 60, or 90 days).

Behavioral Feed

In shadow and active modes, the Behavioral Feed appears below the heatmap as a chronological list of anomalous access events. Each entry shows the identity name, what looked unusual about the event, a confidence level (low, medium, or high), server, and timestamp.

In active mode, entries carry severity badges (critical, high, medium, or low) at full opacity — these are live signals integrated into the alert system.

In shadow mode, severity badges are shown at 50% opacity to indicate that detection is running but signals have not yet been promoted to full alerts. Shadow mode lets administrators validate detection quality before committing to active enforcement.

---

Related: Console Overview | Zero Trust Enforcement (SUDO Policies) | Glossary | Security Architecture