Protected Surfaces
A protected surface is an application URL or domain that TrustPlane Auth protects. Before any client policy in Client Vault can reference it, the surface must exist, prove ownership, and point at an Auth target. The Protected Surfaces console is where you govern that catalog: each surface’s activation and ownership readiness, its attachments, and the declared operations client policy resolves against, backed by environment-scoped Control reads.
Select the scope first
Section titled “Select the scope first”The page requires an environment and a fleet; without both it shows Environment and fleet required instead of data. Site selection is explicit:
- Auth Site selection required — multiple Auth Sites are in the fleet; select the exact site in the persistent context bar. No protected surface is inferred.
- Selected Auth Site is out of scope — the requested
site_idis not in the selected environment and fleet. No other site or surface is substituted. - Protected surfaces not loaded — Control did not return the surface list.
Filter and read the readiness table
Section titled “Filter and read the readiness table”The Protected surface filters panel is GET-only: activation_status, ownership_proof_status, auth_fleet_id, auth_site_id, and search. A metrics row summarizes the selected-site surfaces: Surfaces, Authorable, Pending ownership, Ownership failed, and Missing auth target.
The Protected surface readiness table lists each visible surface:
| Column | What it shows |
|---|---|
| Surface | The surface name (or ID). |
| URL / domain | The surface URL. |
| Activation | Activation status badge — active is healthy; ready, paused, pending_ownership, and draft are flagged as in-progress. |
| Ownership | Ownership proof status badge — verified is healthy, pending is in progress, failed is critical. |
| Auth target | The auth fleet and site the surface points at, or “fleet not set”. |
| Updated | Last update time. |
| Detail | An Inspect link that opens the surface detail. |
Empty states are explicit: “No protected surfaces for the selected Auth Site” when Control returned none for the exact site, and “No protected surfaces match these filters” when filters hide all returned surfaces.
Inspect a surface
Section titled “Inspect a surface”The Protected surface detail panel repeats the surface’s name, URL, activation, ownership, auth target, and last update, then shows two tables:
- Protected surface attachments — which APIs are attached to the surface, with columns Attachment, API, Route (or “all routes”), Status, and Attached time. If Control did not return attachment state, the panel says so rather than showing an empty list.
- Attached declared operations — the surface’s operation catalog, with columns API, Method, Path, Match type, Route status, Attachment, and Authoring route ID. A surface with no operations shows “No attached operations”.
These declared operations are what Client Vault policy selects from: a client’s protected-resource policy can only resolve to operations declared here.
Understand authorability
Section titled “Understand authorability”A surface is authorable only when it is active with verified ownership. For an authorable surface (when a mutation client is available), the detail panel includes a Reconcile protected resource form that declares an operation — protected API, access mode (Read only or Read + write), path, and match type (Exact or PathPrefix) — and Control materializes the canonical operation catalog and automatically reconciles affected Client Vault policies.
For a non-authorable surface, the console shows Resource authoring unavailable: existing operations remain visible, but the authoring form is disabled until the surface is active with verified ownership. In a read-only rendering with no mutation client, the panel reports Operation mutation unavailable instead.