Client Vault

Client Vault is the console’s service-principal surface — where you create client identities, register keys, author client policy, revoke access, and answer the question “can this workload sign requests right now, and for which routes?” It is a site-scoped view of client identities, their public keys, the route grants and signing profiles materialized from client policy, and the propagation state of the Auth Site target that has to acknowledge all of it before requests succeed.

Everything on this page is scoped to one environment, one fleet, and one exact Auth Site. Client Vault never falls back to another site or infers policy from a different scope.

Select the scope first

Client Vault refuses to render an inventory until the scope is unambiguous. You will see one of these notices instead of data:

Environment required — Client Vault endpoints are environment-scoped; select an environment or pass environment_id in the URL.
Fleet required — select a fleet; there is no environment-wide client fallback.
Auth Site selection required — multiple Auth Sites are in scope; open Auth Sites and return with an exact site_id.
Selected Auth Site is out of scope — the requested site_id does not belong to the selected environment and fleet; no policy is inferred from another site.
Auth Site required — no site exists yet; create or select one before viewing policy.
Clients unavailable — Control did not return the client inventory for this scope.

If a URL carries a client_id or key_id that is not in the selected site, the console shows Selected client is out of scope or Selected key is out of scope and selects nothing else in its place.

Review propagation readiness

The top of the page shows a metrics row — Clients, Active keys, Active grants, Eligible resources, and Wildcard resources — followed by the Auth Site propagation readiness panel. The panel reports, for the selected site’s distribution target:

Auth Site and target IDs
Desired / materialized policy publication status
Published bundle / version and promoted target version
Exact target acknowledgement status and instance quorum (activated / expected instances)
Signing profiles active (active / total)
Last pull / reload timestamps
An overall target readiness summary

Readiness resolves to one of four labels:

Label	Meaning
Selected target unavailable	Control returned no site-scoped readiness record, or the site has no distribution target. This is not evidence that policy was published.
Selected target publication pending	The selected-site publication has not been promoted or published yet.
Selected target awaiting acknowledgement	The publication landed, but the target has not acknowledged it with a full instance quorum.
Selected target acknowledged	The target has an acknowledged quorum. Still check the latest policy reconciliation evidence before treating a brand-new policy as active.

Add a client identity

The Add client panel creates an identity only. You enter a display name (for example, Payments worker), and the console previews the generated site-scoped Client ID and Subject before you submit. Step 1 creates only the identity; you save a client-level protected-resource policy in step 2 and add public keys in step 3. No public key or route ID is entered here, and a new client intentionally has no key and no access.

Work the clients table

The Clients table lists every client in the selected site with columns Client, Subject, Status, Keys, and Action. The selected client shows its exact key count; other rows show a reported count or “Open to inspect”. Open a row to load its detail, policy, and key inventory.

The Selected client detail panel shows Client ID, display name, subject, and last update, plus a Deactivate client action. Deactivation is a typed-confirmation action: the console states the blast radius (the client, its active keys, and its route grants are revoked, and Auth Site bundle propagation runs automatically), and you must type the exact client ID to proceed.

Save client policy

The Add client policy editor selects protected resources for the client. A resource is a protected surface + API + normalized path + match type; declared methods are resolved by Control and never entered manually. Each row pairs a resource with an access mode:

Read only resolves the resource’s declared GET and HEAD operations. Choosing it retains those and revokes active POST, PUT, PATCH, and DELETE bindings for that submitted resource.
Read & write resolves every declared operation and requires at least one declared write operation. It never degrades to GET-only on a zero-match.

The editor seeds from the durable persisted-policy readback, flags zero-match rows, coalesces duplicate rows (Read & write wins), and saves through one atomic selected-site reconciliation. If no eligible resource exists, the editor links to Protected Surfaces to attach active declared operations.

After a save, three readback sections confirm what actually persisted:

Persisted policy reconciliation — the reconciliation ID, persisted and revoked binding counts, materialized grant count, selected target, and the separate asynchronous publication and acknowledgement statuses.
Persisted client resource policy — the durable source of truth, with columns Protected surface, API, Path, Match, Access mode, and Resolved route IDs.
Client operation policy — a materialized compatibility view with columns Protected resource, Method, Path, Match, Access mode, Binding status, Source, and Canonical signing route. Every active key inherits these bindings.

A policy save is only presented as successful once the durable selections, materialized grants, and signing profiles read back from Control. If that readback fails, the console reports policy_readback_failed and blocks further saves until Retry policy readback succeeds — the persistence itself was confirmed, so retrying the save is what it prevents.

Add a key to a client

The Add key to client panel accepts one base64url Ed25519 public key. Before you submit, it previews the derived Key ID, KID, and Public-key fingerprint, alongside the inherited client subject. The key inherits the persisted client subject and access policy and triggers propagation. Retrying the same public key reuses the same active record.

Keys can also arrive without this form: workloads that enroll through a Control Trust Anchor receive a derived key that inherits the same client policy. See OIDC JWKS enrollment runbook.

Read the client keys table

The Client keys table lists every key for the selected client:

Column	What it shows
Key	The KID, linked to the selected-key detail.
Status	Key status badge (`active`, `revoked`, `pending`, and so on).
Fingerprint	The shortened `sha256:` public-key fingerprint.
Effective route	The route labels of the key’s active signing profiles, or a No active route badge.
Target readiness	The selected-target readiness label for the site.
Actions	For active keys: the verification-request action (or No active signing profile) and Revoke key. Inactive keys show “No action”.

Two states in this table matter operationally:

No active route means the key has no active grant with an active signing profile for the exact acknowledged target version. The key exists, but nothing it signs will be authorized — check client policy, grant status, and target acknowledgement before assuming the key is usable.
No active signing profile means no verification command can be generated for the key. Canonical routes and verification commands remain unavailable until the exact key-containing target version is acknowledged.

Revoke key is a typed-confirmation action: the console states that it revokes the key and its active route grants and that Auth Site bundle propagation runs automatically, and you must type the exact key ID.

Inspect the selected key

The Selected key detail panel is the per-key truth view:

Client ID, Key ID, KID, Subject, Public-key fingerprint
Key origin — manual for pasted public keys, or trust_anchor_derived for keys produced by an enrollment flow such as the OIDC JWKS enrollment runbook
Key expiry and Runtime activation status
Profile state — the signing-profile state and reason (for example, active, profile_pending, revoked, expired, source_inactive)
Canonical route — the canonical signing route ID, method, and path; shown as “Unavailable until profile is active” otherwise
Audience — from the active signing profile
Selected target readiness — the same site-level readiness label as above

When the key has more than one active grant, a Granted route selector chooses which grant’s signing profile the panel and verification command use.

Run a verification request

The verification-request action appears wherever a key has an active signing profile. Copy and run smoke command copies a generated command to the clipboard; Inspect command expands it for review before running.

The command reads only TRUSTPLANE_CLIENT_PRIVATE_KEY_FILE, the local base64url private-key file — it never embeds key contents. For body-bearing methods (POST, PUT, PATCH), set TRUSTPLANE_SMOKE_BODY_FILE to a local body file first; the exact bytes are signed and sent. The console refuses to render a command unless it references the canonical route ID and passes the private key by file, so a malformed template is shown as unavailable rather than as a runnable command.

If the profile is not active, the panel shows Test request unavailable: the key’s profile is not active for the exact acknowledged target version, so verification commands stay hidden.

Advanced: materialized key grants

A collapsible Advanced compatibility: materialized key grants section lists the effective key-level compiler records for the selected key — columns Grant, Route, Status, and Signing profile (including inactive-profile state, reason, origin, expiry, and runtime activation). These records are derived from client policy for compiler and signing-profile compatibility; make normal policy changes through the client policy editor, not here.