Two trust planes

TrustPlane uses the words “trust anchor” in two different places, and they name two different trust planes. Reading one as the other leads to wrong security conclusions, so the docs always qualify which plane is meant. This page defines both and shows where each one acts.

The two planes

1. Auth route-source authorization (request plane)

The runtime trust model inside signed bundles. A route’s policy (allowed_sources) lists which signed caller sources — issuer, trust domain, subject, required key binding — may access a protected route. The verifier evaluates this per request, locally, against the mounted bundle policy. Control is never a hot-path dependency for this decision.

2. Control enrollment Trust Anchor Sources (enrollment plane)

Control-plane Trust Anchor Sources validate external workload evidence once, at enrollment time — for example an OIDC JWKS source verifying a projected ServiceAccount token — before a derived client key is issued to the workload. The supported end-to-end profile is documented in the OIDC JWKS enrollment runbook; keys can also be registered manually in the Client Vault without an enrollment source.

What each plane proves — and what it does not

Enrollment validates workload evidence once. It does not itself prove that each subsequent request originated from the original workload. After enrollment, what authorizes a runtime request is:

possession of the derived private key (the request is signed with it),
the key’s status in Control (active, not expired, not revoked), and
route policy — the request’s source must match the route’s allowed_sources on the protected surface.

A stolen or exported derived private key may be usable from another network location until it expires or is revoked, unless provenance/device binding or network controls are additionally enforced. The derived key’s effective lifetime is the earlier of the enrollment policy’s maximum key lifetime and the identity proof’s expiry; re-enroll before expiry, and revoke plus re-enroll on compromise. Every allow/deny decision leaves audit evidence you can interpret after the fact.

Enrollment plane flow

Runs once per enrollment (and again on renewal):

flowchart LR
  W["Workload"] --> P["Workload proof<br/>(e.g. projected SA token)"]
  P --> EP["Control enrollment policy<br/>(Trust Anchor Source validates proof)"]
  EP --> DK["Derived client key"]
  DK --> A["Auth adapter"]
  A --> API["Upstream API"]

Request plane flow

Runs on every request, locally at the verifier:

flowchart LR
  SR["Signed request<br/>(derived key possession)"] --> RA["Auth adapter<br/>route/source authorization"]
  RA --> API["Upstream API"]