LAYER · VALIDATE · ACTIVATE
Secret references: pinned versions and tenant boundaries
Edit real JSON layers. Trace each winning value and compare the candidate with the configuration that is actually active.
Scroll the diagram horizontally to compare candidate and active values. The table below gives the same fields as text.
Edit candidate layers
Use synthetic values only. Do not paste credentials. Request overrides allow only timeoutMs, maxTokens and temperature.
Validation report
Your experiment
Choose the cross-tenant reference example. Confirm that even a correctly formatted reference cannot bind another tenant’s secret. Then use a matching v2 reference and compare disabled and denied outcomes.
Explicit teaching schema
timeoutMs: integer 50–60,000; maxTokens: integer 1–8,192; temperature: number 0–2; retries: integer 0–5. timeoutMs × (retries + 1) must not exceed 90,000 ms. Model: atlas-lite or atlas-pro. Secret reference: fixture:team-a:v1/v2 or fixture:team-b:v1/v2, matching the selected tenant.
Defaults apply first and request overrides last. The middle layers use the selected precedence. All fields are validated, even when a later layer would overwrite them. A rejected candidate changes nothing in the active revision.
Value provenance and active revision
| Field | Candidate value | Winning source | Currently active value |
|---|
Applied-field history
Offline teaching model, not an ADK/Gemini configuration API or a security boundary. Precedence, validation ranges, allowed keys and retry budget are explicit lesson policies. Environment JSON is manually entered: this page never reads process environment variables. Secret references resolve to synthetic metadata; there are no secret values, network requests, cloud credentials or real IAM checks. Unknown fields, invalid types, forbidden request overrides and failed bindings reject the complete candidate. When a reload is rejected, Re-check the serving binding also tests the retained revision 1 against the same secret state: a denied runtime identity, or a disabled version that revision 1 itself pins, is reported as a failed serving binding instead of a healthy retained revision. Production reload semantics depend on the application and must be tested separately. Configuration separation · Secret-reference and version guidance.
A reference is configuration; the secret is not
Applications should hold a reference naming a secret and an exact version, never the value. Here secretRef must name team-a or team-b and version v1 or v2, for example fixture:team-a:v1. The page opens in Activation mode Reload, so revision 1 keeps serving while a candidate is checked. The opening candidate takes fixture:team-a:v1 from the defaults layer, validates, binds to mock metadata and activates as revision 2. No secret bytes exist in the model.
Rotate by changing the pin
Open the Tenant tab and set the tenant JSON to {"maxTokens": 1024, "temperature": 0.4, "secretRef": "fixture:team-a:v2"}. The candidate activates as revision 2 bound to v2, and the provenance table shows secretRef from tenant. Rotation becomes a reviewed change that can be validated and reverted. Replace v2 with latest, a floating alias, or v3, a version this fixture does not have: both fail the reference-format check, binding is never attempted and revision 1 keeps serving. A floating alias would let the credential change without a new revision.
Version state and runtime identity
Keep the v2 pin and set Synthetic pinned version to Disabled version. Validation passes, binding fails with Pinned synthetic secret version is disabled, and the result is previous revision retained. A disabled state applies only to the version the candidate pins, so revision 1, pinned to v1, is unaffected and the result line ends revision 1 binding re-checked. Choose Runtime identity denied: the candidate fails with a denied-access error, and the gate changes for a reason the next section explains. With Activation mode Startup a disabled version gives startup blocked and no live configuration, because nothing is serving yet.
Re-check the revision still serving
Keeping the old revision is only safe if it can still read its own secret. Serving revision check opens on Re-check the serving binding, so a rejected reload also tests revision 1 against the same secret state. Press Restore valid example, so the candidate pins fixture:team-a:v1 like revision 1, and set Synthetic pinned version to Disabled version. The candidate fails as before, but the gate reads retained revision binding failed, the result line ends revision 1 binding failed, and the validation report adds Revision 1 binding re-check failed: its pinned version fixture:team-a:v1 is disabled. Runtime identity denied fails the re-check for either pin, because revision 1 reads its secret with the same identity. Set Serving revision check to Trust the serving revision and the same run shows previous revision retained, a healthy-looking revision that cannot read its secret.
Tenant boundaries and which layer wins
Load a complete example resets every input, so pick it first. Cross-tenant reference pins fixture:team-b:v2 for Team A and fails with Synthetic secret belongs to another tenant; set Fixture tenant to Team B and the same reference activates. The Request JSON editor accepts only timeoutMs, maxTokens and temperature, and opens supplying temperature 0.2; Forbidden request override puts secretRef there and is rejected at validation, so a caller cannot pick credentials per request. For precedence, restore the valid example and add "secretRef":"fixture:team-a:v2" to the environment JSON and "secretRef":"fixture:team-b:v1" to the tenant JSON. With Middle-layer precedence Environment then tenant, the Team B reference wins and binding fails; choose Tenant then environment and v2 activates. The tenant check must run on the merged value. Invalid environment string and Retry budget too large fail on other fields.
Playback, assumptions and limits
Eight stages sit 7 seconds apart on a 49-second inspection: the four layers from 7 to 28 seconds, validation at 35, binding at 42 and activation at 49, where the serving re-check is reported. Play becomes Resume after a pause and Replay at the end. Next stage jumps one stage, Restart inspection rewinds, Speed changes pace and Inspection time seeks. Restore valid example resets all inputs. This is not an ADK API, a cloud secret manager or Vault. There is no IAM policy, secret payload, cache lifetime, audit log, or propagation of a rotation to processes already holding a value. The re-check runs only when a reload is rejected; a real service would also probe its live binding on a schedule.