Storing a secret safely is only half the problem. The other half is using it — logging into a device, calling an admin API, running a change — without ever handing the secret to the person or the machine doing the work. Versus Privileged Session Management (PSM) brokers the connection and injects the vaulted credential inside a trusted server, so the actor operates the target and never sees the password. This is the companion to The Day in the Life of a Secret: that doc is how a secret is stored and read; this one is how a secret is used without disclosure.
1. Use without disclosure
The traditional privileged-access anti-pattern is "check out the password, paste it into PuTTY." The moment a human can read the password, three things are true: it can be written down, it can be reused off-platform, and it cannot honestly be said to have rotated when the session ends. PSM removes the read entirely. The credential is resolved from the vault inside the broker, injected into the live connection, and used there — the actor sends commands and receives output, but the secret itself never crosses back to them.
This is a structural property, not a screen that hides a value. There is no API field, no console view, and no code path in PSM that returns a plaintext secret to the actor. The only thing the actor ever references is a vault:// pointer.
FIG 1 · THE NON-DISCLOSURE BOUNDARY
The credential is resolved and used only inside the broker. Commands and responses cross back to the actor; the secret never does. This is a structural guarantee, not a UI convention — there is no code path that returns a plaintext secret to the actor or to the API.
2. The session lifecycle
Every session — SSH, HTTPS, RDP, and the database kind (roadmap) — moves through one spine: authorize → (optional approval) → active & injected → recorded → close → rotate-on-close. A just-in-time lease bounds how long the session may live; a background reaper closes anything past its maximum duration or idle timeout. Because the credential rotates when the session closes, the window in which that specific secret is valuable ends with the session that used it.
FIG 2 · SESSION LIFECYCLE
Every privileged session moves through the same spine regardless of protocol: authorize → (optional approval) → active/injected → recorded → close → rotate-on-close. A just-in-time lease bounds the session; the reaper closes anything past its max-duration or idle timeout. On close the credential the session used is rotated, so a session's exposure ends when the session does.
3. Authorization: the session capability
Opening a session passes the same first two gates as any vault operation — the module must be entitled (licensed) and the actor must clear RBAC — but the decisive third gate is a new vault capability: session. It is deliberately disjoint from read. A role can be granted the right to use a credential in a brokered session while being denied the right to see it. That separation is the whole point: the operator who runs a change on the core firewall never needs — and is never given — the firewall's admin password.
NoteGranting session does not imply read, and the common configuration is to grant session alone. The capabilities are checked independently by the same VaultPathPolicy engine that governs reads, writes, and rotations.
FIG 3 · AUTHORIZATION · USE-WITHOUT-SIGHT
Opening a session is gated by three independent checks, and the decisive one is a new vault capability: 'session'. It is deliberately disjoint from 'read' — a role can be granted the right to USE a credential in a brokered session without ever being granted the right to SEE it. Superuser access is allowed but audited as such. Granting 'read' is not required and is often deliberately withheld.
4. SSH sessions — command brokering
For an SSH target the actor submits a command in the console. The broker resolves the credential (username + password, or a private key), opens its own authenticated SSH connection to the target, runs the command, and returns only the resulting output. The credential exists as a local variable inside a single broker call and is never serialized into the response, the recording, or the audit event.
FIG 4 · SSH COMMAND BROKER
For an SSH session the actor submits a command. The broker resolves the target credential from the vault, opens its OWN authenticated SSH connection, runs the command, records the I/O as an asciicast frame (envelope-encrypted), appends a hash-chained 'command' event, and returns only the output. The credential is a local variable inside the broker for the duration of one call and is never serialized back.
5. HTTPS sessions — injected requests
For a web target — a device management API, an appliance UI, a SaaS admin endpoint — the actor issues a method and path. The broker builds the URL, injects the vaulted credential as a Basic / Bearer / cookie header, forwards the request, and returns the status and body. The Authorization header is added on the broker and stripped before anything reaches the actor's browser. This is the same credential-injection the on-site collector already does for device APIs (for example F5 Basic auth), promoted into a user-facing proxy.
FIG 5 · HTTPS INJECTED REQUEST
For a web target the actor issues method + path (and body). The broker builds the URL, injects the vaulted credential as Basic / Bearer / cookie, forwards the request, records request/response metadata, and returns the response body and status — never the Authorization header. This generalizes the credential injection the on-site collector already performs for device APIs (e.g. F5 Basic auth) into a user-facing proxy.
6. RDP sessions — injected native client
RDP is a stateful graphical protocol, so it can't be command-brokered like SSH. Instead the actor opens a one-time .rdp in their native client (mstsc, or any RDP client). That file carries a random routing token but no password, and it disables CredSSP so the connection uses the TLS (SSL) security path. A TLS-terminating gatewaymaps the token to the session, resolves the vaulted credential in-broker, and rewrites the RDP Client Info PDU (TS_INFO_PACKET) so the domain, username, and password are the vaulted ones — then relays the stream to the target. Whatever the actor typed at the prompt is discarded and overwritten on the gateway: mstsc reaches the box with a credential it never held.
NoteThe gateway runs as its own process — on the Versus side for a directly reachable target, or on the collector for a site-bound one — and is not part of the web service. The injector (Client Info PDU rewrite) and the full inject-and-relay path are covered by automated tests, including an end-to-end test that proves the vaulted credential reaches the target while the actor's decoy password does not.
CautionRequires the target's RDP listener to allow the SSL security layer (i.e. NLA not enforced on that listener); an NLA-only target rejects the gateway's connection and the session errors cleanly. Transparent outbound CredSSP — so NLA-enforced targets work unchanged — is planned. RDP recording currently captures connection metadata (screen-capture recording is on the roadmap).
FIG 6 · RDP · NATIVE-CLIENT INJECTION
The actor opens a one-time .rdp — it carries a routing token but NO password, and disables CredSSP so the SSL security path is used. A TLS-terminating gateway maps the token to the session, resolves the vaulted credential in-broker, and rewrites the RDP Client Info PDU (TS_INFO_PACKET) so the domain/username/password are the vaulted ones before relaying to the target. Whatever the actor typed is discarded and overwritten — mstsc reaches the box with a secret it never held. Prereq: the target's RDP listener must allow the SSL security layer (NLA not enforced); transparent outbound CredSSP is future work.
7. Cloud vs. on-site injection
A session declares where the credential is injected. For a directly reachable target the cloud broker injects. For a site-bound device on a collector-only network, the session rides the collector tunnel and the credential is resolved from the collector's local vault — so for on-prem devices the secret is injected on-site and never leaves the customer network. The three vault modes documented in the vault deep-dive (A local, B cloud-relayed, C external) apply to sessions unchanged.
FIG 7 · WHERE THE CREDENTIAL IS INJECTED
A session declares an inject point. For a directly reachable target the cloud broker injects. For a site-bound device on a collector-only network the same session rides the collector tunnel, and the credential is resolved from the collector's LOCAL vault (Mode A) — so for on-prem devices the secret is injected on-site and never leaves the customer network. The three vault modes (A local, B cloud-relayed, C external) apply unchanged.
8. Recording & tamper-evident audit
Every session produces two independent evidence trails. The recording — an asciicast for SSH, a request log for HTTPS — is stored envelope-encrypted with the same per-secret DEK scheme as the vault itself. In parallel, each state change and command becomes a SessionEventwhose hash covers the previous event's hash, forming a chain: deleting or editing any event breaks the chain and is detectable on verification. Neither trail ever contains the credential.
FIG 8 · EVIDENCE · RECORDING + HASH-CHAINED AUDIT
Two independent evidence trails are produced for every session. The recording (asciicast for SSH, request log for HTTPS) is stored envelope-encrypted with the same per-secret DEK scheme as the vault. In parallel, each state change and command is a SessionEvent whose hash covers the previous event's hash — so any deletion or edit breaks the chain and is detectable. Neither trail contains the credential.
9. Approval & rotate-on-close
A session policy can require dual-control approval: the session sits in requested until a second, different person approves it (self-approval is rejected), and only then does it go active and start recording. When any session closes — by the actor, by an admin terminating it, or by the reaper on lease/idle expiry — the policy's rotate-on-closetriggers the vault RotationEngine against the credential the session used, verify-before-commit, as a best-effort step that never blocks the close.
CautionRotate-on-close means a credential used in a session is changed the moment the session ends. If an external system holds a synchronized copy of that credential, it must be a system Versus rotates (a managed device, a directory, an auth provider) — otherwise plan the rotation policy around that dependency. This is the same rotation surface described in the vault doc.
10. One model for humans and machines
The session spine is identical whether the actor is a person opening an interactive console session or a machine (a service account or the collector) opening one programmatically through the tunnel. Both authorize against the session capability, both are recorded and hash-chain audited, and both rotate on close. "Who used this credential, when, and what did they do" is answered the same way for a workload as for a human.
FIG 9 · ONE MODEL FOR HUMAN & MACHINE
The same session spine covers both actors. A person opens an interactive brokered session from the console; a machine (service account / collector) opens one programmatically through the tunnel. Both authorize against the 'session' capability, both are recorded and audited, both rotate on close — so 'who touched this credential, when, and what did they do' is answered identically whether the actor was a human or a workload.
11. In the product
PSM lives under Secret Vault → Privileged Sessions. From there an operator opens a session against a vault:// credential path they hold the session capability on, then works in a brokered SSH console or HTTPS request console, downloads a one-time .rdpfor an RDP target, watches the audit chain verify in real time, and replays the recording afterwards. Session Policies (admin) map credential paths to how sessions may be opened — allowed kinds, approval, recording, lease limits, and rotate-on-close. The same experience is available as a self-service App Builder template, so an entitled end user gets it without the admin console.
NotePSM is part of the Secure Vault module. The session spine, the SSH / HTTPS / RDP brokers, injection, leasing, recording, audit chain, approval, and rotate-on-close are live today; an interactive database console reuses the same spine and is on the roadmap.