Wardengate
Capability guide

Secrets brokering

Users authenticate as themselves. Targets never see them. Wardengate retrieves credentials from your vault at connect time, injects them in the brokered session, and ensures operators never copy standing passwords.

Brokered credential model

The operator proves identity to Wardengate. The gateway retrieves the target credential from HashiCorp Vault, AWS Secrets Manager, or the built-in vault — injects it during protocol handshake — and never exposes it in the client UI or shell history. Disconnect ends the credential's use for that session.

Different from password checkout

Checkout workflows give humans copyable secrets. Brokering keeps secrets in the gateway boundary. Audit shows who opened a session and what they did — not merely who copied a password at 2am.

Rotation and lifecycle

Pair brokering with vault rotation policies so injected credentials are always current. When a credential rotates, the next session picks up the new value — no manual kubeconfig or SSH key distribution. Account discovery and push patterns can feed the vault without operators in the loop.

Break-glass without shared clipboards

Emergency access uses the same brokering path with shorter TTL, extra approvers, and mandatory recording. There is no shared break-glass password in a wiki — only a time-boxed grant with full attribution.

Operational docs

Ready to deploy? Continue in documentation

Ready to evaluate?

See the platform on your architecture

Walk through gateway brokering, recording, and audit exports in a working session — or start with the interactive demo.