The web console — what you can do in the browser

This page is for operators and integrators who need an exact map from the browser to the running control plane. Start with the product map if the workspace names are new.

trstctl serves its React console from the control-plane binary, on the same port and TLS certificate as the API. There is no second UI service to deploy. The console and API enforce the same session and tenant boundary, but feature coverage differs between the browser, REST API, CLI, and SDKs. This page names the served endpoint behind each screen and calls out summary-only or API-only behavior.

Navigation

The console is a unified shell: an icon rail of five spaces at the far edge, and a sidebar scoped to the active space. Home is the cross-space cockpit — Dashboard and Journeys sit above a few quick tasks (for example Expiring ≤30 days) that deep-link into a pre-filtered worklist. Each space owns every surface of one operator question:

• Certificate Lifecycle — which certificates need attention, and is renewal safe? It owns inventory, request, profiles, CA hierarchy, and enrollment protocols.
• Machine & Workload Trust — which machines can prove who they are, and what needs repair? It owns workloads, machine identities, SSH trust, and agents.
• Secrets & Access — which secrets need rotation, repair, or access review? It owns the store, dynamic engines, access, sharing, synchronization, and scanning.
• Software Trust — can we prove what was signed, by whom, and with a healthy key? It owns software signing and timestamp-verification work.
• Trust Operations — what cross-product risk, ownership, alerting, or system work needs attention? Its served overview at /trust-operations composes the existing risk, incident, ownership, alert-delivery, routing, and worker-health read models. Discovery, posture, graph, incidents, jobs, policy, approvals, audit, people, alerts, privacy, integrations, and administration remain reachable here.

The mechanism: the URL decides the active space — deep-linking any route lights up its owning space, and choosing a space in the rail lands on the first route your session may read. trstctl's cross-domain moat still meets in one place (one identity graph, one blast-radius view, one signed audit stream): every non-Trust-Operations space keeps a Change history (this space) row, a scoped lens over the single stream, and the command palette jumps across spaces from anywhere. A space with no readable routes disappears from the rail entirely, and route URLs are unchanged from the pre-spaces console, so old links and bookmarks resolve. Every nav row is gated by the same RBAC the API enforces, and every label resolves through the typed i18n catalog (see the web i18n catalog); a blank preview backs evaluation until the binary serves real data.

The surfaces

Home (/)

Home opens with the highest-priority credential work, not a wall of metrics. Each row names the affected workspace, operational consequence, deadline, current automation evidence, effective owner, and safest next action. The ranking comes from served contextual-risk evidence; current asset-specific ownership assignments override older discovery metadata. When either source cannot be read, Home says unknown or unavailable instead of showing a false zero.

An Outcomes section then routes to the three end-to-end workflows: certificate automation and assurance (starting at /certificates), agent and workload identity assurance (/workloads), and cryptographic risk and migration assurance (/posture). Each has an outcome page in these docs that lists every step with the evidence it leaves and how it is proved: certificates, agent and workload identity, cryptographic risk and migration.

Five compact workspace health doors then report certificate expiry, machine identities, stored secrets, recent signing outcomes, and open incidents. Their counts come from the current served APIs. The 47-day certificate-renewal readiness panel remains visible. Detailed KPI charts, including the issuance-rate chart, plus inventory mix, expiry distribution, endpoint verification, and audit activity are retained under Explore detailed metrics so the first screen answers what to do before it exposes analysis.

Alert channel and routing-policy authoring, test delivery, failures, and history live on /notifications in Trust Operations. A summary on Home is not proof that a notification was delivered.

Journeys (/journeys)

Journeys is the guided-onboarding hub: pick a journey (first certificate, respond to a compromise, manage secrets, and more) and work a step carousel checking served data — issuers, certificates, discovery sources/runs/findings, profiles, incidents, agents, secrets, members, audit — to auto-mark observable steps, leaving command-line steps for you to mark by hand. Each journey links to its full walkthrough doc.

Certificate lifecycle command center (/certificates)

Expiry totals come from the server, not a count of the currently loaded page. They refresh every 30 seconds while the tab is visible, immediately on return, and when a displayed active certificate expires. The cockpit shows the server observation time; during refresh it identifies the previous snapshot, and after a failed refresh it marks totals unavailable rather than leaving a reassuring zero. Reads time out after 15 seconds and overlapping refreshes share one request. The issuance result, workload history, inventory dates and certificate detail use the active display time zone. Exact UTC validity remains available on the time elements and is never changed in the certificate itself.

The certificate inventory is also a CLM dashboard: alongside the tenant-scoped, cursor-paginated, expiry-filtered table it renders issuer/profile/team/environment filters with URL-resident state, a Team column, estate-wide expiry/source health, expiry bands, the lifetime-reduction readiness panel (the server's verdict for each active certificate under the CA/Browser Forum's 200-, 100- and 47-day steps, the public TLS profiles that request more, and a CSV export naming the Baseline Requirements version), deployment receipts from the connectors, and one guided revocation center under Revocation & CT. Expiry action counts and bands cover active certificates; historical revoked and superseded rows remain in inventory without creating new expiry warnings. The Expiring inventory filter also selects active certificates only. The expiry metric links apply that filter when the workspace is already open, including after back/forward navigation.

The revocation center makes an operator choose a managed X.509 identity and RFC 5280 reason, then reads an effect-free, version-bound server plan before typed confirmation unlocks execution. The review keeps affected systems, queued CRL/OCSP publication, signed endpoint health, CRL availability, immutable audit evidence, and recovery guidance in one journey. Unknown graph or propagation state is labeled unknown; it is never rendered as healthy.

After first issuance, Review identity lifecycle opens that identity's detail drawer with the actions its current state permits. An issued certificate must be deployed before renewal. A deployed identity, or a failed renewal that can be retried, can offer Renew. A certificate's details also expose Review revocation without requiring the operator to find a protocol acronym in navigation.

Certificate list and detail responses include identity_ids only when retained issuance or successful delivery records establish the relationship. The console does not match a certificate to an identity by common name, owner, or row order. Missing or multiple bindings cannot authorize an automatic identity selection. Graph links use cert:<certificate-id> for the leaf and id:<identity-id> for the lifecycle identity; incident response receives the actual managing identity. The same workspace also contains the tenant CRL distribution panel (full CRL, shard count, delta base, freshness window), a Certificate Transparency queueing form (each log line may carry the log's public key after its URL), and a per-certificate renewal-history timeline in the detail drawer. The drawer's Certificate Transparency list shows each log's SCT (verified against the log key, invalid with the reason, or unverified) and whether the log proved the entry is in a tree head it signed. For a row recorded without the certificate itself, Certificate bytes offers to look it up in the tenant's CA records or read it from the host:port the row names, attaches it only when it matches the fingerprint, and then shows where it came from. The drawer's Assurance record section builds the certificate's signed lifecycle assurance record on request, shows which stages were independently observed, recorded only, or absent, and saves the signed file for offline verification. See Lifecycle & PQC and the 47-day journey. Backed by /api/v1/certificates, /api/v1/certificates/health, /api/v1/certificates/validity-readiness (and its /export), /api/v1/certificates/{id}/assurance-record, /api/v1/revocation/crls, /api/v1/revocation/health, /api/v1/revocation/ct-submissions, /api/v1/identities/{id}/transitions/preview, /api/v1/identities/{id}/transitions, /api/v1/graph/nodes/{id}/blast-radius, /api/v1/lifecycle/rotation-runs, and /api/v1/connectors/deliveries.

Identities & NHI governance (/identities)

The identity grid carries the lifecycle actions (issue, deploy, revoke, with the SURFACE-007 confirm and dual-control guards), and above it an issuance pipeline groups identities by stage. The dashboard's NHI inventory summary and the risk posture and orphan-governance panels on Risk and Owners complete the governance lens: counts by kind, custodian-less credentials, and a shared risk score. The grid searches the authenticated tenant on the server before pagination, so an identity beyond the first page can still be found and selected for an exact bulk action. Search matches a literal, case-insensitive substring of name, kind, status, owner name or environment, or an exact identity UUID. The type filter is an exact kind match. Previous and Next move through 50-row pages; selection is cleared whenever the search, type or page changes. API callers can use GET /api/v1/identities?q=...&kind=x509_certificate&limit=50 and must retain the same q and kind when following next_cursor. The health tiles use GET /api/v1/identities?limit=1&include_summary=true. Its summary.total and summary.by_status count the complete authenticated tenant, independent of the returned page and any search filter. If the summary read fails, the console shows an unavailable state and a retry control rather than presenting the first page as the complete estate. The lifecycle automation panel may list a due identity outside the inventory's current cursor page. Its review button reads that exact identity by ID before opening the effect-free transition preview; a failed or mismatched read is shown as an error instead of silently disabling a valid action. When a bulk revocation returns per-item failures, the result keeps the names from the exact identities the operator reviewed, even after the inventory refreshes to a different cursor page. See Workload identity and Observability & risk. Backed by /api/v1/identities, /api/v1/nhi/inventory, /api/v1/risk/credentials, and /api/v1/graph.

Ownership (/owners)

The opening answer is deliberately simple: which team is accountable for every identity and credential. The visible operations cockpit reports known assets, assets without an effective owner, owner reviews due, and missing contact or escalation routes. A genuinely empty inventory says that nothing is known yet; it does not masquerade as complete ownership. Add owner creates a durable person, team, workload, service, or vendor record. It does not silently assign an asset.

The accountability hierarchy then reads like an incident route: business unit → durable team or service → application and environment → contact and escalation route → affected assets. The ownership action queue stays visible, explains why each unowned asset needs work, and supports one-at-a-time or bulk assignment. An assignment requires a selected durable owner and a plain-language reason. The browser sends one idempotency-protected command; the server appends one immutable ownership.assigned event and projects the effective owner. For managed identities and certificates, the native lifecycle owner changes in that same projection, so admission checks and the browser cannot disagree. Retrying the same command returns the first result rather than writing a second decision. Coverage gaps and temporary exceptions opens the exact identity's existing exception history before another grant is offered. An active exception shows its reason, grantor and expiry, and can be revoked with a recorded reason. When the identity is no longer in the gap queue, enter its exact Identity ID and choose Inspect exception history. This read-only lookup still exposes any active exception's reasoned revocation control; it does not offer a new grant outside the gap queue. Reopen the identity to confirm the server reports it inactive. This removes the temporary ownership-readiness bypass; the underlying owner gap still needs an owner update or attestation. The queue searches by asset name, exact inventory ID, kind, or current owner, and shows 25 rows per page with the filtered result count and page controls. A gap beyond the first page remains reachable for individual or bulk assignment.

The exact machinery remains available in three closed disclosures so a first-time operator does not have to decode two large tables before learning whether there is a problem:

• Owner records, inheritance, and attestations searches and filters accountable records across the tenant's paged owner directory, including records beyond the API's first page, and exposes edit, re-attest, and exact-name-confirmed delete controls. If a directory page fails, the console reports the error rather than showing a partial roster as though it were complete. The application ID, service, business unit, environment, escalation recipients, and provenance show whether the precise application/environment model is current. Review due dates and source observation dates use the console's selected time zone.
• Coverage gaps and temporary exceptions separates missing, incomplete, never-attested, and stale ownership. Operators fix the owner record first. A reasoned exception is available only for urgent work and must expire within 30 days.
• Sources, disagreements, and review history explains the precedence rule and shows CMDB imports, conflicts, and the full ownership-attribution table. Exact owner IDs win; approved source data may inherit a match; imports never overwrite a human attestation; unresolved disagreements wait for review. It also shows CMDB ownership sync before setup, with a reviewed form for the deployment operator's approved HTTPS ServiceNow URL and relay_only binding, secret:// reference, CI query, interval, and enabled state. Saving a schedule does not claim a CMDB read completed; the panel separately reports relay progress, retained cursor, failure and terminal coverage, and Run CMDB sweep now starts the next sweep without waiting for the interval (refused while a sweep is in flight or the schedule is paused).

Backed by /api/v1/owners, /api/v1/owners/{id}, /api/v1/owners/{id}/attest, /api/v1/identities/{id}/ownership-exceptions, and /api/v1/ownership/attribution. Bulk and contextual assignments use POST /api/v1/ownership/assignments; the headless equivalent is trstctl-cli owners assign -f <decision.json>.

Agents (/agents)

Agents answers three questions before it exposes fleet machinery: which in-network workers are online, which presented certificate-bound role evidence, and which reported both a fresh heartbeat and a version. These are separate claims. An enrolled row is not automatically called trusted, and a reported version is not automatically called approved.

The API also keeps lifecycle and presence separate. status is the durable agent-reported lifecycle/operational state. presence.state is a server-evaluated connection receipt: online, stale, unreported, offboarded, or clock_skew. Online means the non-offboarded agent reported within two configured heartbeat intervals—the same rule used by the fleet alert—not “the status string happened to say online.” The receipt includes evaluated_at, fresh_until when a valid heartbeat exists, and an ELI5 technical reason so API, console, and alerting explain the same result. An impossible future heartbeat fails closed as clock skew. Fleet heartbeat, service-report, queue-measurement, revocation, and offboarding times use the console's selected time zone; API timestamps remain exact UTC values.

The only default action is Add agent. It opens a viewport-bounded dialog that chooses host and/or network-relay capability, mints one bootstrap token, and shows the install command. The role is signed into the enrolled client certificate; it cannot change silently, only through a recorded role change that the agent's next renewal signs. Closing or dismissing the dialog clears the token from page memory, and the console does not persist it.

Exact work remains in three closed disclosures:

• Fleet status and safe actions contains heartbeat and version rows, exact agent details, clock warnings, role changes, certificate revocation, and offboarding. An agent whose clock is past agent_channel.clock_skew_warning from the control plane's shows "Clock … ahead of (or behind) the control plane" under its last heartbeat, with the measured drift in its details. Change roles records the complete role set an agent's next certificate carries (it needs agents:relay.grant); the roles column keeps showing what the presented certificate carries, with "Next renewal: …" beneath until a renewal signs the change. A current agent renews at its next heartbeat. Each host or network agent's detail shows the job kinds this server build supports for the roles on its last reported certificate, including the matching connector families and required flags. This is a capability list, not proof that the enrolled binary has those flags or that a job ran; use its reported version, queue, and receipt evidence for those questions. An agent with no reported roles has no claimed job list. Revocation takes effect after revocation data propagates. Offboarding leaves a tombstone instead of erasing the record.
• Enrollment and trust evidence shows the roles each agent reported from its signed certificate. Missing evidence stays missing; the console never guesses that an old agent has host access.
• Versions, queues, and diagnostics loads only when opened. It shows the active upgrade target and version histogram, rollout rings, pending and claimed agent work, verified/rejected receipts, live credential redemptions, and the exact work kinds this build lets agents claim. Use Refresh diagnostics to remeasure the rollout, queues, and receipts without reloading the fleet page. Selected-agent diagnostics also show the served endpoint-discovery census, Workload API posture, and enrollment-proxy upstream/request evidence. Discovery capabilities come from the running build's compiled census (including build-dependent sources) and remain metadata-only; the console does not receive private-key bytes.

Backed by /api/v1/agents, /api/v1/agents/enrollment-tokens, /api/v1/agents/upgrade-campaign, /api/v1/operations/jobs, /api/v1/agents/{id}/offboard, /api/v1/agents/{id}/cert-revocations, and /api/v1/agents/{id}/roles.

Workloads (/workloads)

Workloads is where short-lived machine identities get issued: SPIFFE/SVID certificates gated on TPM, cloud, Kubernetes, or GitHub attestation; dynamic/ephemeral leases with TTL policy and renew/revoke controls; AI-agent broker identities scoped to allowed actions and a TTL; and attester trust-source create/rotate/revoke/delete. It also shows served Kubernetes CSR and trust-bundle-distribution posture, and rolls one CA bundle out to the clusters that report here, canary first: each rollout lists every cluster's state and the report that verified it, with pause and resume. Open Kubernetes controller evidence to see the last reported controller pass, ready/pending/failed object counts, each observed object's state and reason, and the public bundle hash. An absent, stale, or failed report does not appear active. The panel refreshes while the tab is visible and has a manual refresh control. Raw key material never reaches the browser. Backed by /api/v1/workloads/attested-issuance, /api/v1/workloads/attester-trust-sources, /api/v1/secrets/leases, /api/v1/broker/agent-identities, /api/v1/kubernetes/certificate-signing-requests, /api/v1/kubernetes/trust-bundles, and /api/v1/kubernetes/trust-rollouts.

Profiles (/profiles)

Profiles are versioned issuance rulebooks: allowed key algorithms (including ML-DSA/SLH-DSA hybrid PQC), minimum RSA/ECDSA strength, allowed EKUs, maximum validity, allowed DNS suffixes, and which enrollment protocols may use the profile. Build one with the guided form or a raw JSON editor, preview the resulting spec, and browse prior versions — issuance keeps the version it evaluated against, and a diff view compares any two versions field by field. From a historical comparison, Review recovery asks why the earlier rule is needed and opens an effect-free receipt. Only the confirmation copies that rule into a new active version; history is never edited, and a concurrent newer version makes the confirmation fail closed. Backed by /api/v1/profiles, /api/v1/profiles/{name}/versions/{version}, and the paired .../restore/preview and .../restore routes.

Find unmanaged credentials (/discovery)

This screen answers three questions in reading order: what trstctl found, why it matters, and what you can safely do next. The default view puts a short attention summary and Credentials to review first. Choose Review finding to see the human explanation and claim it into managed inventory; less-common lifecycle actions and raw evidence stay behind clearly named disclosures. A host trust-store root that the distrust list names itself (for example emSign ECC Root CA - G3) is marked On the distrust list in its detail, with Remove from host trust store: after confirming the path and host, the console queues the removal for the agent that found it and names the receipt that will carry the host's result (see Discovery & inventory).

Run scan takes you to the real discovery sources so you can run an existing source or add the first one. Sources, schedules, and run history remain one tab away. Exact CT-log monitoring, drift, coverage, fingerprints, source/run IDs, and repository API paths are available under Monitoring and exact scan evidence or Exact finding evidence. They are hidden at first so an operator can make a sound decision without decoding implementation details, not because the proof is missing. See Discovery & inventory. Backed by /api/v1/discovery/sources, /schedules, /runs, /findings, /findings/{id}/remove-distrusted-root, /monitoring, /ct-monitoring, /drift, and /nhi/posture/shadow.

Algorithms and future readiness (/posture)

This screen first answers one question: Which credentials use outdated or incompatible cryptography? The default view shows how many credentials were checked, how many need an upgrade, and a plain-language worklist that explains each current-policy or future-readiness problem beside the current and target algorithms. An empty inventory says that nothing has been checked; it never claims that the estate is safe.

Plan upgrade is the only primary action. It opens compatibility, PQC policy, campaign tracking, and the guarded migration workflow. The Community edition keeps CBOM discovery, readiness, campaign ownership, evidence, and signed campaign closure usable. Core migration execution requires an exact preview, selected assets, explicit confirmation, progress evidence, and a second confirmation before rollback.

The complete expert machinery remains on this page under three named disclosures:

• Algorithm inventory and scan evidence contains a three-step CBOM workflow: choose TLS/file scope, review the server-normalized effect-free plan and exact safety limits, then run and inspect durable results. Partial failures keep successful observations and show repair-and-retry guidance. A zero-finding run is marked inconclusive. An inventory receipt checks this run's exact asset IDs against a separate server read, so older records cannot mask a failed scan. The section also contains the policy floor, algorithm rollup, exact asset rows, and recommendations.
• Compatibility, PQC policy, and upgrade planning contains graph-bound readiness, attributed owners, dependency paths, core PQC campaigns, and the core migration workflow. Campaign creation defaults to graph binding, which requires the selected finding's owner to appear in crypto-agility readiness. Choose Track manually when the graph has no attributed owner. Manual tracking records an owner and evidence but does not prove dependency coverage or bind the campaign to graph changes. A certificate-key migration run can report issued without a usable subject key or installed replacement. The panel states this before approval; verify the served endpoint through the normal certificate lifecycle before recording campaign remediation.
• Certificate, AD CS, authority, and drift evidence contains CT monitoring, AD CS template/database checks, authority agreement, discovery findings, and the drift-remediation decision workflow.

The readiness rows use the same digest-bound graph evidence as Risk. Missing graph placement renders as Unknown, never ready, and later topology drift refuses stale evidence mutation. See Lifecycle & PQC → PQC. Backed by /api/v1/cbom/assets, /api/v1/cbom/scans/preview, /api/v1/cbom/scans, /api/v1/graph/crypto-readiness, /api/v1/graph/crypto-readiness/actions, /api/v1/graph/crypto-readiness/export, /api/v1/pqc/campaigns, /api/v1/pqc/migrations, /api/v1/discovery/ct-monitoring, and /api/v1/discovery/drift-remediation.

CA migration (/migration)

Migration separates a read-only assessment from execution. The three-step guided form loads active CA authorities, deployable X.509 identities, and enrolled host agents from the running tenant, then lets the operator map and reorder waves, set trust-anchor paths, and review the exact plan. An explicit Advanced JSON view remains available for automation and rejects incomplete or extra fields. After the review, assessment stops on unknown trust stores, deployment targets, or verification listeners; changing any mapping invalidates the result, including when a prior assessment response arrives late. The draft survives collapsing the plan section, and the review shows the normalized values sent to assessment. Start appears only after a matching ready assessment. The server derives the public anchor from the selected authority, so neither a CA private key nor pasted certificate text enters the browser plan.

The run table reads the durable event projection and shows every wave's membership, phase, and signed trust-plus-live verification percentage beside the run's current gate. Pause blocks publication after already-leased work, resume continues the same incomplete gate, and rollback restores predecessor leaves newest-first before removing successor trust. A failed signed gate starts that inverse automatically; the button remains the operator-initiated path. The buttons do not locally advance anything: only signature-verified host-agent trust readback and live-listener receipts move a gate. Backed by /api/v1/migrations/assess, /api/v1/migrations/runs, and the /api/v1/migrations/runs/{id}/{pause,resume,rollback} mutations.

What to fix first (/risk)

What to fix first opens with one ranked worklist of the credentials that create the greatest real-world risk. Human-readable reasons explain why each item matters, and Review risk shows the recommended action. Exact IDs, raw reason codes, the versioned CAP-POST-05 model contract, score inputs, evidence IDs, generation time, and projection coverage remain available under Exact score and evidence.

The full certificate score projection and NHI posture panels for policy compliance, over-privilege, stale/static credentials, exposure, and the automatic NHI posture actions the tenant's nhi_posture rules ask for (each match's action and last automatic run) stay available under Score inputs and supporting projections. They do not compete with the default decision. The exposure panel's Live reachability column shows each record's latest probe from a network relay, and Probe from a relay (discovery:write) queues a new one for up to 50 public endpoints. For fleet-wide crypto hygiene (drift, PQC readiness), see Posture. Backed by /api/v1/risk/credentials, /api/v1/risk/contextual-priorities, /api/v1/nhi/policy/compliance, /api/v1/nhi/posture/overprivilege, /api/v1/nhi/posture/stale, /api/v1/nhi/posture/static-credentials, /api/v1/nhi/posture/exposure, /api/v1/nhi/posture/exposure/probe, and /api/v1/nhi/posture/automation.

Secrets workspaces (/secrets, /secrets/*)

The Secrets space gives each workspace its own route in the sidebar (S-C2); historical /secrets?tab= deep links redirect permanently. /secrets is the store — an Infisical-style workspace: a folder tree over the served key-value store, a reference resolver that expands ${secret.path} chains, an environment diff, a version-history selector, and an explicit disabled bulk-import disclosure (the server route returns 501 until atomic event-sourced batch commands exist). See Secrets. Backed by /api/v1/secrets/store and /api/v1/secrets/store/{name}. Automatic secret sources (/secrets/engines) holds dynamic leases, CSR-first PKI-as-a-secrets-engine (the default; certificate-only), inert API honeytokens and operator-attached AWS IAM bait keys (effect-free review, plant, reveal once, inspect CloudTrail management-event coverage and observed use, rearm after triage, and retire), an explicit deprecated key-returning mode linked to its Audit receipts, and the Transit console for safe key-metadata readback, typed key creation/selection/rotation, and encrypt/decrypt/rewrap/HMAC/sign operations (/api/v1/transit/*). Key material never enters the browser; a decrypted value appears only in the dismissible reveal panel. One-time secret sharing (/secrets/sharing) covers authenticated token delivery and separate ephemeral API keys. A share is configured, reviewed without sending its value, created from the server-keyed plan, revealed once, and then redeemed/verified. If creation has an ambiguous network result, the page retains one in-memory recovery key and offers Retry same reviewed share; it does not create a new request. The recipient needs the token and secrets:read access in the same tenant. A lost redemption response can be recovered with Retry same redemption while the page remains open and the token unchanged. Shares expire or are consumed once; individual cancellation is not available. The same workspace shows the secret-change dual-control queue and keeps values/tokens out of browser storage. Find leaked secrets in code (/secrets/scanning) covers repository and pipeline checks through a three-step choose → review → prove workflow. Review is server-owned and effect-free: it validates the confined path, mode, scanner, and optional rules before any process starts. A failed or interrupted run stays visible and Retry reviewed scan reuses the same in-memory idempotency key, so a completed scan is recovered rather than run twice. Result rows show only rule, file, line, and redacted credential-reference metadata, then link to the durable discovery run. For third-party CI, registry, Slack, and Jira exports, expand Scanner setup and exact evidence and queue an artifact scan. The receipt opens the exact discovery run on this page; a saved /secrets/scanning?third_party_run=<run-id> URL reopens it after restart. The result shows terminal status and redacted findings, with a link to that run's full Discovery triage. The control plane must have the scanner binary and access to the operator-owned artifact under a configured scan root. Send secrets to systems (/secrets/sync) shows configured destinations and refuses a delivery when none is configured. Its cloud workload identity wizard lists only tenant targets whose actual cloud provider matches and whose workload identity switch is enabled. When none qualifies, it names the missing operator configuration instead of offering a static-credential target. The store's scheduled-rotation panel renders one tick's exact run and deferred-row receipt. Deferred rows use only the served approval_pending, command_in_flight, and command_claimed states, including schedule ID, due time, and optional error. If the tick consumes exactly 50 runs or 500 scans, a localized continuation notice says which bound was reached and directs the operator to run again from the durable fair cursor. A typed partial 503 keeps that tick's fresh receipt visible; a generic or malformed error clears older receipt and limit text so stale success cannot look current.

Machine access (/secrets/access) is the machine-auth console: grant a workload a scoped credential (standing token or TTL-bound ephemeral key) with a reveal-once display and a list-and-revoke ledger; inspect the configured auth methods — issuer, audience, scopes, source — and disable or enable one per tenant (a disabled method is refused at the login exchange itself); and review the issued-session ledger (GET /api/v1/secrets/sessions), an idempotent, event-sourced revocation record. The login test exchange completes the create-grant-verify loop in-console.

Use secrets in apps (/secrets/developer) is the separate developer workflow. Its opening form selects one stored secret, a child-process environment variable, and optional reference resolution. Review access plan calls the effect-free POST /api/v1/secrets/access/preview route, which transiently proves the current tenant-scoped value can be opened, wipes it, and returns only the current version, secrets:read boundary, server-keyed fingerprint, recovery and verification steps, and exact CLI, HTTP, and TypeScript examples. The examples are copyable only after that server review and never contain a real value. The separate access test executes the served read, compares its name and version with the plan, and renders only a value-free receipt. Changed inputs or a changed version invalidate the review; ordinary access failures keep an explicit retry path. Bulk secret import accepts a private JSON file, shows names without values for review, then displays the atomic batch's metadata receipt. One name collision refuses the whole import.

What could be affected (/graph)

This screen first answers one question: Which known targets depend on a selected credential? Search by name, serial, fingerprint, or graph ID when many renewals share the same certificate name; repeated names show distinct IDs. Choose the exact credential and select Explore impact. The answer counts known resource targets, which can be services or files, and labels each target's actual kind. It always warns that missing discovery coverage can make the real impact larger; zero known targets is not presented as proof of zero impact.

The relationship map, filters, node inventory, exact attributes, read-only query, and raw edge table remain available under three named disclosures. Each served edge can include its evidence source and confidence: foreign-key relationships are authoritative, inventory and discovery observations are observed, name correlation is inferred, and subject-only trust candidates are unverified. The prefilled expert query uses the server's typed-edge syntax to list DEPLOYED_TO relationships; operators can edit it before running a read-only query. A blast-radius JSON download keeps the selected node, known_affected_targets, reachable nodes, relevant edges, evidence labels, and coverage warning together. Its filename includes the exact graph ID so same-name certificate renewals do not overwrite each other's evidence.

Selecting an X.509 issuer also shows trust stores and distinct hosts whose discovered anchor has the exact certificate fingerprint or SPKI public-key identity. Same-subject/different-key matches remain a separate unverified-candidate count and never inflate authoritative trust or automation. Backed by /api/v1/graph, /api/v1/graph/blast-radius/{id}, /api/v1/graph/reachable/{id}, /api/v1/graph/query, and /api/v1/graph/trust-stores/{id}. See Graph, query & AI.

Compliance, audit & policy (/policy, /audit)

Rules and approvals opens with the decision an operator needs: whether fail-closed protection is on, whether a custom rule is active, what changed, and what needs approval. Create rule creates a draft only. Rule versions, safe testing, framework evidence, reports, and access reviews stay in four closed sections until requested; this keeps the default screen calm without removing exact evidence. Framework evidence includes PCI-DSS, HIPAA, SOC 2, FedRAMP, FIPS 140, CA/B Forum BR, and more, with the signed tenant/window, exact event/object references, and missing prerequisites. It also shows signed certificate-custody totals and the exact fingerprint/fields for every incomplete custody row, the CAP-OBS-02 inventory report, report schedules, and the dry-run workbench. A new report schedule can name notification channels and a ServiceNow ticket that announce each completed run; the review lists those announcements under After each completed run, the schedule list shows Announced on, and each signed run says where it was announced or why its ticket was skipped.

Change history opens with the newest 50 matching tenant events and answers who changed what, when, and whether the last event shown records a result. It does not call that window the complete history. Search activity opens the filters, event rows, and exact event detail. Signatures and export, plus collector delivery, remain in two separate closed sections until requested. This keeps the default page calm without removing tenant-scoped evidence or operational controls.

The tool chip is a server-side filter, not a word search. Workloads & Machines includes trust configuration, attestation, issuance, SPIFFE, SSH, agents, and related workload-certificate lifecycle events; it does not mean “contains ssh.” For a certificate revocation batch, the summary counts the recorded revoked, queued, skipped, and failed items separately. queued means an external authority still has work to do; an audit count alone is not CRL or relying-party proof. Open the exact event and verify the issuer's revocation evidence. The tool, feature ID, action, text, time window and as-of sequence intersect before selecting the newest or earliest matching events and applying the 1–100 event limit. Search, signed bundles and all file-export formats use the same applied filters. Clearing the tool keeps other filters; Reset removes all filters, and browser Back restores the previous URL and scope. A failed or still-loading search cannot export an older successful scope. Changing scope cancels its pending reads and export, so late evidence cannot replace the current view. These browser reads have a 15-second timeout; Apply filters retries a failed read without weakening authorization.

The event explorer filters the tamper-evident stream and exports a signed evidence bundle. Its plain search is case-insensitive across event type, privacy-filtered actor subject and roles, and event data, so copying the visible actor into the box returns that actor's matching rows without weakening tenant scope or erasure. The evidence section names the exact chain head, RFC 3161 kind, authority time, and whether the full token is present. Its download is the canonical JSON envelope from the served contract—not a display string—so the compact JWS and complete external timestamp remain together for offline verification against the operator's pinned audit JWK set and TSA root. CSV downloads likewise keep their proof in the final RFC-safe row rather than transient response headers.

The same Change history screen configures tenant-scoped scheduled Splunk HEC and Microsoft Sentinel feeds inside Collector delivery. That section loads only when opened. Its table shows the durable delivered cursor, exact queued-record lag, retry attempt/time, terminal error code, and collector request ID. The form accepts only an operator-allowlisted env:NAME credential pointer—never a token value—and clearly separates public HTTPS from permission-gated private CIDRs. A save records configuration and a same-transaction outbox intent; the browser never calls the collector directly. See Policy & governance and Compliance. Backed by /api/v1/compliance/evidence-packs/{framework}, /api/v1/compliance/inventory-report, /api/v1/compliance/report-schedules, /api/v1/policy/dry-run, /api/v1/policy/versions, /api/v1/audit/events, /api/v1/audit/export, and /api/v1/audit/feeds[/{id}]. A schedule can announce each completed run on notification channels or in a ServiceNow ticket; the notice names the run, its digest and its download route, never the report body. Native audit-feed delivery is a separate served workflow.

Evidence privacy (/privacy)

Answers who can access evidence, how long it stays, and what is removed before showing exact controls. Reading requires privacy:read; changing retention or erasure evidence requires privacy:write; every request remains tenant-scoped. One Review policy action opens the data map. Subject erasure/export, archive removal attestations, and retention jobs stay in separate closed sections and load on demand. Subject erasure and retention now open server-owned reviews before confirmation: both show exact current counts, prove the review made no change, and name prerequisites, durable effects, safe retry, irreversibility, and readback checks. Changing the subject or reason discards the old erasure review. See Privacy data catalog. Backed by /api/v1/privacy/subject-erasures, /api/v1/privacy/subject-exports, /api/v1/privacy/archive-erasure-attestations, /api/v1/privacy/retention-runs, their /preview routes, and /api/v1/privacy/catalog. The subject-rights section distinguishes direct operational erasure from signed audit archives and backups, whose disposition needs separate evidence. A subject export first shows counts, then offers a full JSON download named with the tenant-bound subject reference rather than the raw subject. Keep that local download under the same access and retention controls as other personal-data exports. Privacy timestamps follow the console's selected time zone; API values remain UTC.

Trust Operations and Software Trust (/trust-operations, /incidents, /codesign)

• Trust Operations overview — the cross-domain queue names the affected product area, deadline, accountability state, and safest next action. Separate health links show open incidents, ownership gaps, failed alert deliveries, and worker bulkheads. Its route-safety statement is derived from the served channel and routing-policy APIs; it never claims that a human received an alert.

• Incidents — the response console: compromise → blast radius → replacement-before-revoke → automated revoke/rotate/right-size playbooks → Splunk/Jira/Slack/ServiceNow dispatch → evidence, plus break-glass online m-of-n issue (/api/v1/breakglass/issue) and offline-quorum reconcile (/api/v1/breakglass/reconcile). The issued-certificate history reads tenant-scoped event-projected receipts and lets an operator download the original signed bundle and public certificate after a browser restart; the CSR subject private key remains outside trstctl. Its Overview also lists tenant-scoped receiver-command quarantines from /api/v1/incidents/outbox-reconciliation-conflicts: source sequence, old outbox row, lanes, agent demands, and SHA-256 command identities are visible, while the executable payloads are never returned to the browser.

• Code signing — a preview-first signing console (managed key and keyless/Fulcio). The first step submits only a SHA-256 digest plus signer metadata to an effect-free readiness oracle. Review shows exact execution effects, recovery, verification, and server-owned request/configuration fingerprints. Signing is disabled until that review is ready; editing any input invalidates it. An uncertain response can only retry the identical request with the same Idempotency-Key. Private keys and artifact bytes never enter the browser, and a keyless identity proof is never rendered after input (/api/v1/code-signing/preview, /api/v1/code-signing/keyless/preview, /api/v1/code-signing/sign, /api/v1/code-signing/keyless).

• CA hierarchy — the m-of-n key ceremony flow, existing-CA-chain import, offline-root import/intermediate-CSR workflow, and HSM/KMS managed-key custody (generate, list, inspect, rotate, revoke, zeroize), guarded by RBAC. The Imports workspace also re-keys an active offline root from one public successor certificate and both public cross-certificates. Its effect-free review binds the predecessor, reason, exact CA profile and all three certificates to a two-custodian ceremony. Editing a reviewed field disables activation. After quorum, the console activates the successor and shows the event-projected public trust-path receipt; a lost browser response is recovered by entering the ceremony ID and refreshing. The private keys stay on the disconnected systems. Independently verify both returned chains before distributing a new trust anchor. The offline-root import takes an optional possession signature: once the ceremony ID is entered, the panel prints the OpenSSL commands that sign the ceremony's challenge on the offline system, and after import it shows whether key possession was proven by that signature or not proven. The private key of an imported offline root stays outside trstctl. Its detail view opens the signer-held intermediate workflow and does not offer direct signing actions. The API returns a conflict with that recovery path if a client tries direct issuance. Key inventory comes from the durable tenant projection and survives refresh and restart; a key from a detached provider stays visible but cannot be changed until that provider is restored. The issuer catalog has schema-driven config forms for built-in and upstream issuer types, sensitive-field masking, and per-issuer Test connection actions. The issuer table shows each chain's certificate count; open Chain on a row to inspect the full public PEM in a readable dialog.

See Incident response & JIT and Code signing & timestamping.

Protocols (/protocols)

Protocols is the enrollment control room: a live register of ACME, EST, SCEP, CMP, SPIFFE, SSH CA, and TSA, backed by protocol-specific responder probes or authenticated effect-free qualification plus tenant-binding and profile-gate requirements. The TSA panel reads the exact in-memory mount, stable-certificate, isolated-signer, audit, and bulkhead posture; it issues nothing and keeps the stock OpenSSL commands as the real RFC 3161 wire proof. A DNS-01 provider catalog and provider-config table (preflight, edit, delete; configs are provisioned outside the console) support ACME's DNS-01 challenge; an MDM/SCEP panel does the same for Intune-style SCEP, plus challenge rotation and allow/deny telemetry.

The read-only ARI posture panel calls GET /api/v1/acme/ari/posture with lifecycle:read. It separates trstctl's own ACME publication from external CA fetching and local estimates. Each row labels its window source, external CA, fetch state and next poll when applicable, plus the durable scheduler state that consumed an ARI window. The API also exposes the exact external authority, closed failure class, and last fetch time. Loading, no affected certificates, permission denied, API error, and ACME-not-served are distinct states; the panel never turns an unavailable publisher into a success-looking empty table.

The read-only Revocation cache by segment panel calls GET /api/v1/revocation/caches with certs:read. It shows each certificate-bound network relay's segment, issuer fingerprint, CRL/OCSP local path, signed freshness window, validation time, and served/refused counts. Fresh, stale, empty, API failure, and never-reported are different states. The response is metadata-only: cached CRL or OCSP bytes, requests, issuer certificates, upstream URLs, and credentials never reach the browser.

A client-setup section gives copy-paste commands per protocol, with links to SSH Trust and Code Signing. Backed by /api/v1/acme/ari/posture, /api/v1/revocation/caches, /api/v1/acme/dns-01/providers, /api/v1/acme/dns-01/provider-configs, /api/v1/mdm/scep/status, and /api/v1/mdm/scep/policies.

SSH trust (/ssh)

SSH Trust runs the SSH CA workflow end to end: CA/KRL status (revoked-certificate count, trusted attestor methods, published authority key), a guarded trust-rollout recorder, attestation-gated short-lived user-certificate issuance, serial- or key-based revocation publishing an updated KRL, and host retirement. See SSH. Backed by /api/v1/ssh/status, /api/v1/ssh/trust-rollouts, /api/v1/ssh/attested-user-certs, /api/v1/ssh/certificates/revoke, and /api/v1/ssh/hosts/retire.

Connect other tools (/integrate)

Connect other tools first explains the direction of each connection: devices and services send credential requests to trstctl; trstctl sends credentials, alerts, and events outward; SDKs, GitOps, and infrastructure code make the setup repeatable. Its single Add integration action is a chooser, not a fake form. It links to the real destination, alert/webhook, secret-sync, CA, or runnable-API configuration screen.

The detailed enrollment and developer surfaces remain available in three closed sections. They preserve copyable ACME/EST/SCEP URLs, the Go, TypeScript, Python, and Java SDKs, Terraform provider, cert-manager issuer, SPIRE upstream authority, live GitOps manifest generation, policy dry-run, and drift comparison. The GitOps dry-run checks the declaration envelope and shows its allow/deny decision separately from whether the policy module compiled. It does not apply a declaration or validate every resource field. The installation inventory preview lists observed trstctl objects; it is not a Helm values file and does not compare a running Helm release. Use the Kubernetes installation guide to supply the exact release image digest and required external service and secret settings. GitOps live state is not fetched until that section opens. The permissions and delivery section explains API scopes, signed webhooks, plugin capability grants, and outbox-backed retries with receipts in plain language. The Terraform provider is source-ready; the hub offers a local installer because no public Registry package is published. See Enrollment protocols, Client SDKs, and Terraform provider.

API playground (/integrate/api)

API playground first answers one question: how to try a safe request and understand the response. Its default screen runs nothing. It explains the three-step path — start with a read-only operation, use only the access that operation needs, then read a plain-language result — and exposes one Try request action. Opening the workspace prefers an explicitly public GET with no required inputs. That first read runs without minting a key; protected requests still require an explicit scoped key, and sending any request remains a separate action.

The full OpenAPI surface remains reachable without putting hundreds of operations on the first screen. All contract operations searches by name, path, summary, or permission and renders at most 12 matches at once. Headers, body, and exact request preserves every served path, query, and header parameter; JSON body; recursive validation rule; idempotency header; and the exact normalized preview with the bearer secret hidden only on protected operations. Public reads show no Authorization header. OpenAPI schema and code examples links to the served contract and keeps matching curl and SDK snippets copyable. Keyboard users can focus every scrollable code region. A link containing ?operation=<operationId> opens the real workspace on that exact operation without creating access or sending it.

Only GET operations with an explicit served public rationale and no OpenAPI security or permission requirement run without a test key. The runner omits browser cookies as well as bearer headers for those reads. Other operations use a self-service 15-minute token scoped only to the selected operation. A write cannot run until its draft validates and the operator confirms the exact mutation preview; changing any input clears that confirmation. In-flight requests can be canceled, expired tokens fail closed in the browser, and a live token can be revoked immediately. The response starts with a plain-language answer, then shows the real status and content type. RFC 7807 problem details remain visible, and Raw response retains the exact payload. A denied or unavailable contract names the problem and recovery action; a successfully loaded empty contract never invents operations. Backed by GET /api/v1/openapi.json, POST /api/v1/access/api-tokens, and DELETE /api/v1/access/api-tokens/{id}.

Jobs and queues, and notifications (/operations, /notifications)

Jobs and queues answers two questions first: whether background work is moving and which failed job needs a person. The default view shows only failed, waiting, running, or approval-blocked work as responsive cards; raw UUIDs and internal outbox destinations do not crowd the decision path. Review failed job moves keyboard focus to the first failure. Opening that job reveals its exact ID, attempt count, served failure reason, connector destination, idempotency key, outbox payload ID, rollback reference, and a link to the matching immutable event log.

Three closed evidence sections keep the page calm without hiding proof. Worker pools and queue limits explains each bounded pool's worker count, current depth, capacity, saturation, rejections, and panics, then exposes the agent claim ledger, signed receipts, and live credential-redemption custody. All jobs and filters contains completed work plus type/status filters. Rotation run records contains the exact lifecycle history. The UI does not offer a generic cancel button because there is no served cancel operation; stopping or rolling back work stays with the owning workflow rather than pretending a button succeeded.

Approval work is loaded through every cursor page instead of stopping at the first 100. Each approval is visible only when the reviewer has the matching real authority: certs:issue for certificate actions, secrets:write for secret actions, or keys:approve for managed-key actions. Reject records an immutable denial of that exact request and does not retire, revoke, delete, or otherwise mutate the target resource.

Alerts and delivery answers one question first: which events currently reach which people or systems. The opening summary reports ready channels, routing rules, and failed deliveries without claiming that an unavailable read model is empty. It also shows a compact event-to-destination path and flags rules that reference only missing or disabled channels. Add channel is the one primary action. Its bounded dialog requires a public HTTPS destination and a credential reference, never a secret value. Alert, deadline, and delivery-receipt times use the console's selected time zone; the API keeps RFC 3339 UTC timestamps for exact evidence exchange.

Three closed evidence sections keep the default page calm. Channels and webhooks shows every supported family from GET /api/v1/notification-channels (email, Slack, Teams, SMS, SIEM, and more) and whether each is ready; a tenant authors its own Slack, Teams, webhook, PagerDuty, OpsGenie, or SIEM channel there, each delivered in that family's format with the credential its secret:// reference names, while email and SMS are the operator's to configure on the server. Routing rules and templates maps event severity to ready destinations, records an accountable owner, and queues a redacted test through durable outbox work. trstctl currently uses one fixed server alert envelope across channels; this build does not pretend to offer a tenant-editable template library. The console leaves policy and owner fields empty rather than showing sample data as if it were configured, and it enables Save policy only when every entered destination matches a ready channel. Delivery attempts and dead letters filters the durable inbox, marks unread rows read, shows retry/error/idempotency/owner/recipient evidence, and offers requeue only for failed delivery. Toasts report real success and failure.

Approvals, self-service & administration

• Request a credential (/request) and the approvals inbox (/approvals) are the self-service pair: preview and submit, then approve as a distinct principal — the inbox blocks self-approval of your own request. The request wizard reads the tenant owner roster and requires an explicit accountable owner; an authentication subject is never guessed to be an owner UUID. Submission opens the first-class issuance.request.opened lifecycle object, so the requester and approver read the same event-projected request instead of two independently inferred views. The exact preview is effect-free and submission cannot proceed when it is unavailable or stale. The first step also requires an explicit CA choice. It lists only requestable authority names and availability, even for a requester without issuer inventory permission. The preview, request record, approval view, and prepared identity retain that exact CA source and ID. An unavailable or unknown CA blocks opening the request; retries do not switch to the built-in CA. Older API clients that omit issuer receive an explicit platform-CA warning in preview and a pinned platform choice in the new request. Historical requests without a recorded CA remain labeled unknown rather than being rewritten as deliberate selections.
• Requests waiting for approval opens with the complete pending count and the next independently reviewable change. It states the reason, consequence, requester, and decision expiry before offering one Review request action. The bounded review shows the server-owned policy result, immutable request ID, bound target version and intent digest, evidence references, approval threshold, and audit history. A first-class certificate request uses the same direct action and shows its owner, profile, selected CA, purpose, requester, and seven-day decision expiry instead of dropping the operator into a long history section. Approve and reject record decisions only; neither performs the requested issue, rotate, revoke, create, sign, recovery, or delete operation. Rejection requires a reason, and self-approval stays disabled with an explicit dual-control explanation. The complete generic queue, issuance-request lifecycle, and exact-ID ephemeral tool remain available in three closed sections; ticket intake and specialized controls are not loaded or rendered until their section is opened. After a certificate approval, the issuance lifecycle opens and preserves a failed signer-backed attempt as an approved request with a safe retry under the same deterministic identity and issuance key. The signing worker records fulfillment even if the browser closes. A later recovery can reconcile the exact signed result after revocation or retirement; it does not restore that credential's validity or mint another certificate. Credential values and private keys never enter the review. Decision lifecycle and history reads completed general approvals from the tenant-scoped, authorization-filtered approval projection, one newest-first page at a time. Each row shows the outcome, quorum, exact request ID and intent digest, and an audit link. Load older decisions continues from the server cursor; a decision remains findable after it leaves the pending queue. The console displays the recorded decision and does not infer that the requested action ran.
• Rules and approvals (/policy) includes access-change approvals for NHI entitlement changes: a PR/ticket/CAB-backed request, evidence refs, and approve/deny by a distinct reviewer. The panel stores metadata and evidence references only, never credential values.
• Platform setup (/platform) is an API-free production-readiness doorway. It loads no protected detail and points to the first system check plus the three separately scoped administration pages. Historical tab-query deep links still redirect to their matching page. People and roles (/admin/access) covers members, roles, OIDC mapping, tokens, offboarding, and JIT sessions. Its SSO disclosure shows the current session's exact sign-in subject so an operator can bind SCIM userName or externalId to that value before provisioning. System health (/admin/system) answers whether the control plane is securely configured, then keeps exact checks, configuration evidence, dependency health, and exceptions available on demand; it is the read-only packaging, tenant, transport, scale, and support disclosure; and Plan and license (/admin/editions) answers which signed features are enabled and when the license expires, with one Add license operator guide. Signature verification, the exact feature table, and entitlement evidence start closed. Federation availability belongs to System health; an unavailable federation capability does not prevent license inspection or relabel this page as unavailable. License read failures remain visible on the license page itself. Packaging stays nested under entitlement evidence; distribution and active-active issuance proof load only when the operator opens the nested architecture section. The browser never uploads or stores the license: the guide uses an operator-owned 0600 file and restarts the control plane and isolated signer together. Where credentials are installed (/connectors) answers destination coverage and verified health first. One Add destination action is followed by three closed evidence sections for safe target actions, health/retries/rollback, and the full connector/plugin capability registry. Expert APIs load only when their section opens; identity binding, test, deploy, rollback, delivery receipts, listener proof, key custody, circuits, grants, and provenance remain available. A selected destination's Verification address panel shows the address its deployments verify, or suggests the host:port where a discovery scan saw a certificate delivered there, with the findings; Use this address sets it only after the operator confirms.
• Wizard (/wizard) is the onboarding carousel: connect an issuer, enable the evaluation enrollment profile, issue a first certificate, optionally prove a configured connector/upstream-CA/dynamic-secret backend, enroll an agent, then complete. Lease credential material is never retained in component state.

Product help (/assistant)

Product help opens with one Ask a question action. The opening page explains what answers can read, how tenant and role permissions limit every record, and how exact record references let an operator check the result. It does not contact the AI runtime or load the Model Context Protocol (MCP) tool catalog until the operator opens the corresponding workspace or detail. A server with Product help disabled therefore shows a calm overview instead of an unrelated availability error before the user asks for help.

After Ask a question, the default form accepts plain language and reads only certificates, owners, dependency links, cryptography inventory, and change-history evidence allowed by the caller's tenant and role. A hint under the question box lists question shapes the planner answers exactly (certificate filters and counts, who owns a certificate, crypto assets, graph inventories); each such answer begins with how the question was read. Advanced subject and evidence-scope controls stay under Evidence and request details. Investigate a cause keeps the grounded root-cause workflow, and Use read-only tools loads MCP tools only on demand. If the server reports write-capable MCP tools, the generic subject form remains disabled; an operation-specific, permission-checked workflow is required instead.

Every answer says whether its evidence is grounded and sufficient and lists its sources and exact surface#record references. Runtime and privacy details loads the served enabled state, model, egress mode, personal-data policy, redaction boundary, residual refusal gate, and endpoint host. Query, cause investigation, and tool calls remain fail-closed when the surface is disabled. The route is backed by /api/v1/ai/status, /api/v1/mcp/tools, /api/v1/ai/query, /api/v1/ai/rca, and /api/v1/mcp/tools/{tool}. See Graph, query & AI.

Cross-cutting console capabilities

• Bulk operations: fan an idempotent mutation (renew/revoke/rotate) across selected inventory rows and read a per-row result, so a partial failure is visible row by row.
• Saved views & export: persist an inventory's columns, sort, and non-sensitive filter metadata as a reusable view — never row payloads or auth material — and pull it as CSV on demand; scheduled exports are not served.
• CTA empty states: first-run pages use action-shaped empty states that point to the next served workflow, such as issuing a certificate or connecting an issuer.
• Command palette: Cmd+K has local commands plus debounced server-side record search across certificates, issuers, and identities, and quick actions for served workflows.
• Accessibility & theming: keyboard-navigable, screen-reader-labeled, reduced-motion aware, light/dark, and RTL-capable; theme preference is the only thing the SPA keeps in browser storage.
• VPAT evidence: docs/accessibility-vpat.md is the Voluntary Product Accessibility Template packet, backed by CI's automated axe gate and a manual audit receipt.

Reference: route → screen

Use it

# The console is served at the control-plane root — open it in a browser:
open https://trstctl.example.com/

# It is the same served control plane the CLI drives:
trstctl-cli certificates list --limit 50
trstctl-cli privacy retention run

Pitfalls & limits

• The console is a view, not a second backend — it adds no capability the API lacks. If a surface looks read-only for you, that is RBAC, not a missing screen.
• A few adjacent capabilities are API-only today — scheduled digest delivery is not served as a console workflow, and the Provider console shows neither tenant templates nor customers' assurance reports yet. PQC migration preview, start, progress and rollback are available in the console's upgrade-planning section as well as the core API and CLI.
• Auth lives in an HttpOnly cookie, never in web storage; only the theme preference (and non-sensitive saved-view metadata) is persisted client-side.

See also

Platform & API · All features · Getting started · Current limitations