Gurd Console

The Console reads from Guard Cloud. Guard Cloud owns the data, the rules that classify it and every permission check. The Console only formats what the server returns.

Sign-in

• Same origin only. The Console and the /v1/console/* API are served under one HTTPS origin, behind a trusted TLS reverse proxy. Set GUARD_CONSOLE_ORIGIN on Guard Cloud to that exact origin. Browser sign-in stays off while it is unset. A cross-origin Console is not supported, and there is no CORS allowance.
• Access keys. The first administrator key (rgk_…) signs in as administrator. Administrator API keys always sign in as administrator. Issue separate read-only Console keys for viewers.
• Single sign-on. SAML and OpenID Connect sign-in, and SCIM 2.0 provisioning, map identity-provider groups to roles (see Roles below). They need the sso plan feature. OIDC is tested against a fixture provider and, in an opt-in test, Keycloak; SAML only against signed fixtures; SCIM with Entra- and Okta-shaped requests. None has run against a live Okta or Entra ID tenant. An OIDC client authenticates with a client secret or a key Guard holds (private_key_jwt): an ES256 key Guard generates, or an RSA key and certificate imported for Microsoft Entra ID. Guard publishes the key set at a JWKS URL for the provider, and a new key is staged and tested with a sign-in before it replaces the current one. With "Require SSO" on, an administrator of the server can turn it off for one organization with guard-cloud disable-sso-requirement --organization-id UUID if the identity provider is unavailable.
• Sessions. Sessions use Secure, HttpOnly, host-only, SameSite=Strict cookies, with Origin and CSRF checks on every request, reads included. Sessions are revocable: a revoked session gets 401 on its next request. With OpenID Connect, signing out can also end the session at the identity provider, which then returns you to the Console.
• Suspended organizations are refused before any role check.

Note: Keep the Guard Cloud listener private. Only the TLS ingress may reach it, and the ingress must preserve Host and overwrite X-Forwarded-Proto. See Guard Cloud for deployment.

Devices

The Devices page lists every enrolled device, with filters for state, operating system and name, and shows overview counts. Each device has one state. When several apply, the first wins in this order: revoked, tampered, maintenance or removal, offline, buffer loss, stale or unknown, other degradation, healthy.

The Console labels the last state reported healthy. Health is the device's own signed report plus server receipt times. It is not independent attestation of collection or coverage.

Each device also lists what the server has no evidence for, such as last contact, agent version or hook states, so a missing value is shown as missing, not as a default. Device coverage also shows sensor health signals, for example when the sensor can't see the environment an agent CLI started with, or can't keep correlation state across a restart.

Administrators also see device health, which shows the sensor's own posture: the account it runs as, its Linux capabilities or Windows privileges; whether its executable's signature is valid (Linux binaries carry none) and, on macOS, its signing team and whether notarization was confirmed ("not confirmed" can also mean Apple's service was unreachable); whether its data paths changed, as keyed hashes rather than paths; the offline store's state and counts; and Windows sensor problems and counters. It all comes from the latest signed status. A value the device didn't report is unknown, never zero or false.

Finding and integrity counts cover the last 24 hours by server receipt time. They are row counts, not incidents, users or blocked attacks.

The Devices page never shows paths, commands, prompts, finding messages or raw status. Filters, selections and paging stay in browser memory, not in the URL or browser storage.

Device owners

Enrollment says which organization a device belongs to, not which person. An administrator sets the owner, through a directory synced from Okta or Entra ID or, without one, through the organization's people directory in Guard Cloud.

The simplest way is to name the owner when creating the enrollment token in the Console: a person from the people directory, or a name and email. The device that enrolls with that token is assigned to that person automatically. The device sends no user name for this; the owner is set only on the server.

Policy preview and managed MCP

A valid policy version's panel has a Preview impact button. It asks Guard Cloud for an estimate against the findings it has stored from your devices, over a window of 1 to 30 days (7 by default) and optionally one device group. The publish dialog doesn't show the preview, so an approver opens it from the version before publishing. The preview distinguishes estimates, lower or upper bounds and unavailable results. Counts describe findings, not every tool call or confirmed prevented action. New rules and changed selectors cannot recover events that were never recorded. Device rule history stays on the device; this is not a simulation over every device’s full history, and previewing does not publish the draft. Device counts of 1 or 2 are withheld as "fewer than 3", along with any finding counts that would reveal them. No preview names a device, a person or an account.

MCP server rows show reported gateway adoption, and the per-device view counts wrapped, unwrapped, removed and excepted entries. Missing or older evidence stays unknown. A block preview shows which devices a proposed block would stop, from each device's newest MCP upload, and a server can be followed to the devices and sessions that used it. Only calls actually routed through the gateway are mediated; an installed extension or a reported wrapper count is not proof of complete coverage. See MCP tools.

Investigations

Finding inbox and device timeline

The finding inbox filters by device, rule, harness, category, severity and receipt time, and can sort by severity. Severity is shown as a band: low, medium, high or critical. Informational findings show as low. A rule Guard can't score shows as unknown, never a default band. When a command rule couldn't establish an agent's context on the device, its finding says why and what fixes it, such as running guard inventory.

The device timeline merges a device's findings with its findings-log integrity events, newest receipt first. Device time and receipt time are shown separately. A gap over five minutes is labelled as a delayed upload or clock skew.

Every event states its outcome honestly:

Each event also lists the evidence it lacks. An empty list means every field was supplied, not that the evidence is complete. Candidate OWASP LLM and MITRE ATT&CK mappings are partly reviewed and are not compliance claims.

Incidents

Group 1 to 50 findings into an incident, or let Guard Cloud group them. Incidents move through these states:

Each change must name the incident's current version, so two people can't overwrite each other. An incident has one assignee, who must be an active Console user; findings are assigned through their incident, not on their own. Creation, state changes, assignment, notes and exports are written to the incident history and the audit log. Another organization's incident always looks like it doesn't exist.

Automatic grouping

Guard Cloud opens incidents itself for high and critical findings. Lower and unscored findings are left for analysts to link. The first rule that applies groups a finding:

A finding joins the open incident for its group. Once that incident is resolved, a false positive or holds 100 findings, the next finding opens a new one, so a closed incident never gains findings silently. Activity across a window boundary stays together: the first finding in a new window joins the previous window's incident for the same group while it is open, has room, and last gained a finding of that group within one window length. Findings of two organizations never share an incident. Grouping says findings share a session, a team and rule, or a device within a window, not that they share a cause.

Findings stored before automatic grouping existed are grouped by the same rules. Publishing a severity policy that raises a rule to high or critical groups that rule's unlinked findings; lowering a rule doesn't unlink anything. Findings that keep arriving add one history entry, not one per batch, and appear on the timeline.

Each incident shows a root-cause stage: the earliest linked finding in evidence order and the first session event it recorded, such as untrusted input or a sensitive access. It is the earliest evidence Guard holds, not proven causality, and it says when earlier evidence may be missing. It also names the step where the finding's agent session first became tainted on its device, or says why it can't: the finding has no session, the device sent no step log, or no taint came before the finding. That is the earliest taint Guard holds, not a proven cause.

Administrators and analysts can merge up to 10 open incidents into one, or split up to 50 findings into a new incident. A merged incident is resolved as a duplicate and keeps its findings and history. After a split, a group whose grouped findings all moved sends its later findings to the new incident; otherwise they keep joining the original. Both are audited.

Incident timeline

The incident timeline gathers the linked findings, nearby findings and integrity events from the same devices (within one hour), incident history and response actions, up to 500 items. Device clocks are not trusted:

• A device time more than five minutes after receipt is clamped to receipt time.
• Within one findings log, sequence order wins over device time.
• Gaps, restarts and rewritten records appear as integrity items where they were found.
• Late and backfilled records are marked, so a late upload is visible instead of silently reordering the view.

A completeness summary counts every partial-ingest signal. The order is evidence order, not proven cause and effect.

What the Console never shows

Prompts, commands, tool arguments, messages, file paths, process details, network destinations and container details are marked redacted or not collected. Their values, lengths and digests are never returned or exported. Session keys are replaced by a scoped reference.

Session content excerpts appear only to administrators, and only under the session content opt-in or an approved, time-bound escalation. See privacy.

Response actions

Approving and attempting need an exact confirmation phrase, and the proposer can't approve. Results that Guard Cloud recorded can't be overwritten. Every transition is audited.

Approval is not execution. The action states keep the two apart:

Guard Cloud also has signed remote response commands (session quarantine, kill switch, process-tree termination, device isolation), which devices pull on their next sync. The kill switch can go to one device, a device group or every device. Linking those commands to an incident's response action is not built yet.

Evidence export

An export bundle holds the incident, its completeness summary, the ordered timeline and the response actions, with the same redaction as the Console. Entries are hash-chained, and Guard Cloud stores the chain head and entry count. Verification recomputes the chain, so edits, reordering, removal and truncation are detected. Verification is audited.

Exports are recorded by your Guard Cloud, not independently signed attestations.

Roles

Every session has one of five roles. Guard Cloud enforces the role on every Console route. The Console uses the session's permissions only to show or hide controls.

Authoring and publishing policy also need a per-person policy grant. A grant held by someone whose role lacks the capability stays stored but inactive, and applies again if they become an administrator.

With single sign-on, a user in several mapped groups gets the first match in this order: administrator, operator, analyst, auditor, read_only. The default role is read_only or none.

A route without a permission entry is refused for every role. Refusals are audited, with repeats from the same person on the same route grouped per 60 seconds. Role changes and new accounts are audited too.

Not built yet

• Policy exceptions and suppression, notifications, saved investigations and playbooks beyond the three response actions.
• Per-device risk on the Devices page, deployment rollups, user and team inventory, configurable freshness thresholds and historical health snapshots.
• Independent, cross-platform verification of device health.
• Signed export attestations, and complete prompt and tool-call session trails.