Control console overview
Running TrustPlane Auth across more than a handful of services raises questions a single runtime can’t answer: which fleets are healthy, which signed bundle each Auth Site is serving, whether a revocation has actually landed, and what evidence exists for auditors. TrustPlane Control is the governance plane of the two-plane TrustPlane platform — the cockpit for every authorization operation: workload enrollment, trust anchors, signed policy releases, revocation and propagation, fleet visibility, audit evidence, and operator access. Control is the enterprise offering, delivered as managed SaaS; TrustPlane Edge is the self-hosted deployment of Control with advanced, tailored capabilities. The Control console is where you work with it.
What Control does — and what it never does
Section titled “What Control does — and what it never does”Control handles fleet governance, bundle signing and distribution, revocation propagation, workload enrollment, and audit evidence. It signs policy and trust material into bundles, distributes them to Auth Sites, and records how each site acknowledges what it received.
Control is never a hot-path dependency for request verification. TrustPlane Auth — the free-to-use enforcement plane — verifies every request locally against the signed material it already holds. If Control is unreachable, protected traffic keeps flowing; what pauses is governance — new bundles, new enrollments, fresh evidence.
Tour of the console
Section titled “Tour of the console”The console is organized into sections, each backed by its own screen.
Operate
Section titled “Operate”The Operate cockpit is the landing screen: fleet, bundle, distribution, revocation, and audit state in one view, built from same-origin Control reads. Start here to see whether your fleets and Auth Sites are healthy and whether revocations have propagated.
Client Vault
Section titled “Client Vault”Client Vault is the client, key, route-grant, signing-profile, and propagation inventory backed by Control truth. It shows which clients and public keys exist and what routes they are granted.
Trust Anchors
Section titled “Trust Anchors”Trust Anchors lists exact-site Trust Anchor Sources and enrollment policies. Sources validate external workload proofs; they are not the Control bundle-signing root.
Enrollment Approvals
Section titled “Enrollment Approvals”Enrollment Approvals is where workload identity decisions are made: trust inspection plus guarded approve/reject actions through the same-origin signed BFF. An approval here is what turns a verified workload proof into a derived client key.
Audit shows runtime authorization evidence with separate TrustPlane and upstream outcomes, so you can distinguish what TrustPlane decided from what the upstream service returned.
Protected Surfaces
Section titled “Protected Surfaces”Protected Surfaces governs the application surfaces Auth protects — activation, ownership proof, Auth targets, and the declared operation catalog — backed by public environment-scoped Control reads.
Auth Sites
Section titled “Auth Sites”Auth Sites governs each site where Auth runs — lifecycle, ownership verification, distribution targets, and bootstrap handoff material — with signed BFF connectivity and readiness in view.
Billing and Settings
Section titled “Billing and Settings”Settings and Billing covers operator identity and session capability, plus the subscriptions surface for managed Control and enterprise/Edge packages and the feature grants they confer.
The console’s safety model
Section titled “The console’s safety model”The console is deliberately conservative about what it can change.
Every screen loads its data through same-origin signed reads from a backend-for-frontend (BFF). The console never talks to Control’s API directly from the browser; if the BFF is unreachable, the shell reports “BFF unavailable” rather than rendering stale or guessed data. While data loads, the shell shows a “Loading console” notice.
In the current console release, several screens report state rather than change it; each screen’s guide notes where that applies. Where the console does mutate state, the mutation is explicitly guarded and documented on that screen — for example, enrollment approve/reject actions in Enrollment Approvals go through the same same-origin signed BFF, and Auth Site lifecycle actions require typed confirmation and eligibility checks.
The console also fails safely at the rendering layer. If a screen cannot render, it shows a “Route could not be rendered” notice and asks you to refresh — Control data is never replaced with a guessed empty state. Switching organizations discards every environment, fleet, and site selection rather than carrying stale IDs into a context that never authorized them.