Privileged access

This section is for the people who guard the accounts attackers want most: root, Administrator, service accounts and database administrators. It does five jobs. It vaults those credentials so nobody has to know them. It brokers access, so a person opens a recorded session through a gateway instead of typing a password. It governs who may do that and when (approval, tickets, time limits, trust scores). It gives people temporary elevation and emergency access when the normal path is not enough. And it watches what happened (recordings, command rules, behaviour scoring, reports).

It has 22 screens, so this guide is organised to be searched rather than read from top to bottom. Start with the table below.

Find a task

I want to...	Go to
Understand where passwords live and who can read them	Where a secret lives and who can see it
Add a server and vault its admin account	Resources
Require approval before an account is used	Require approval for an account
Give someone temporary admin rights on a host	Just-in-time
Reveal a critical password in an incident	Break-glass
Find out why a session has no recording	Session recordings
End a session when someone types a dangerous command	Command control
Hide a column from people in a database session	Data policy
Let an application fetch a password without hard-coding it	Application credentials
Reach machines in another network	Gateways
Find privileged accounts nobody vaulted	Discovery
Rotate or restrict an SSH key	SSH keys
Track TLS certificate expiry	Certificates
Fill vault credentials into a web login	Browser extension
Read what the behaviour scoring does and does not mean	Behaviour analytics

Before you start

Permissions

The Privileged access group appears in the left navigation for anyone holding vault:read. Inside it, every control is shown only to an account that holds the permission it needs. A reader without the permission sees no control at all, not a disabled one, so a missing button usually means a missing permission rather than a missing feature. The permissions these screens use:

Permission	What it unlocks
`vault:read`	The section itself; list resources, accounts, grants and events; Reveal and Check out a credential (subject to the checks described below); Verify against the host; Deployments on a certificate
`vault:write`	Almost everything that changes state: add, edit, share and delete resources and accounts; rotate; set policies, workflows and landing servers; approve and deny access requests; approve, withdraw, open and close break-glass; approve and revoke JIT; register and revoke applications; classify columns; SSH-key and certificate actions; gateways; groups; Terminate a live session
`sessions:request`	Connect, Request access, Files, the Database session, and Request access for JIT
`sessions:write`	Add rule and Remove on Command control; Save policy on the recording policy (retention and the pre-connect notice)
`sessions:shadow`	Watch (join read-only) on a live session
`audit:read`	Reading the list of command-rule matches

Where a secret lives and who can see it

Every secret is held in the vault (OpenBao), not in the platform database. The database holds metadata only: which account, which resource, who checked it out, and when. The vault holds:

a vaulted account's password and the username beside it;
vaulted or generated SSH private keys (a rotation's new key waits in a pending location until every host has acknowledged it);
a certificate's private key, certificate and issuing CA;
a personal-vault item's secret and TOTP seed.

Only the platform server holds a vault token. The browser never has one, and neither does any agent.

The endpoint agent holds no vault token and does not reach the vault. Every agent request goes through the platform API. On a host, the agent:

discovers the host's local administrator or sudo accounts and reports them (at start, then about every 15 minutes);
grants and removes local-admin membership when the server queues an elevation command (this is how JIT works);
changes a local password when the server queues a rotation, and writes a new authorized_keys line when the server queues an SSH-key deployment.

Commands travel from the server to the agent through a queue. When a password is rotated through an agent, the new password sits in the command queue (in the platform database) until the agent acknowledges, and for at most 15 minutes if it never does. It is cleared on acknowledgement. During that window the password is in the queue, not in the vault's history.

Who sees a plaintext password, and when. There are only a few moments:

Reveal / Check out on Resources or Vault puts the password in the operator's browser. It is an audited check-out, not a view. The console offers Reveal to holders of vault:read; the server then applies the sharing level, any access workflow, any ticket requirement and the Zero-Trust decision.
Break-glass: Open shows the password once, to the browser that pressed it.
Application credentials hand the password to the calling application over the API.
Browser extension fills the password into a page without displaying it (see the caveat under Browser extension).
A brokered session (Connect) does not show the password to the operator. The server places it inside a signed connection request that is exchanged for a gateway token; the operator's browser receives a gateway URL carrying that token, not the credential.

A resource can be set to Use only (Resources, Edit, Password visibility). Reveal is then refused and the attempt is written to the audit log; connecting and autofill still work. This is a speed bump rather than cryptography: a password filled into a web page can be read by that page.

The personal vault is separate. Items are returned only to their owner, and administrators cannot see them in the console. That is an application-level rule: the platform server, and anyone with access to the vault itself, are outside it.

Inventory and vaulting

Overview

Route: /pam. Counters shared with Vault and Reports: vaulted resources, vaulted accounts, checked out, active sessions, pending approvals, rotations overdue and rotations failed. A counter that could not be read shows a dash, not a zero. The screen also lists active sessions (with Terminate, vault:write) and the privileged resources, and has Request access (vault:read, a just-in-time request) and an add-resource shortcut (vault:write).

Resources

Route: /pam/resources. The hub for day-to-day work: target systems and their privileged accounts. Open a resource to get Edit, Share, Add account and Delete (all vault:write).

Per account you see Request (only on an access-controlled account), Connect (sessions:request), Reveal / Hide (vault:read) and a menu: Rotate secret, Turn auto-rotation on/off, Check the password against the host, Use this account to manage the host, Remove from vault.

What the pills mean:

password works / password does not work: the platform checked the vaulted password against the host and it matched or did not.
unconfirmed or never checked: the platform has not been able to confirm. Over WinRM a wrong password and an unreachable host look the same, so it cannot say which. Only password works means the vault and the host agree.
access-controlled: an access workflow is bound; people must request first.
manages this host: this account is the one the platform uses to list and change the host's other accounts.

Resource-level settings in the edit form:

Session recording (vault:write): Always record, Let the operator choose or Never record. See Session recordings. Changing it is audited with the old and new value.
Autofill address: where the resource's web console lives. If it is empty, the browser extension never offers this resource's accounts anywhere.
Password visibility: Can be revealed or Use only.

Remove from vault deletes the platform's copy of the password only. The account stays on the host with its password, and reappears on Discovery.

Rotate secret does not change the vault first. See Vault.

Vault

Route: /pam/vault. A flat list of every vaulted account, with views for Expired, Conflicting, Never checked, No policy and Disabled. The row menu has Check out (vault:read, shows the password in a panel and is audited), Check in, Verify against the host, Rotate secret, Set password policy, Set access workflow, Set landing server, Enable / Disable and Delete account. The account-level bindings (policy, workflow, landing server) live here; the Resources hub is for day-to-day use. Start remote session is the same recorded Connect as elsewhere.

Things to know:

Rotate secret hands the new password to the host's agent, a gateway serving the host's network, or the server itself, in that order. The target is changed first and the vault is updated only once the host confirms. If the host has no agent, gateway or direct route, the rotation is recorded as failed and the vault is not touched. Through an agent it is asynchronous: the account is not rotated until the agent acknowledges.
A check-out is a ledger entry, not a lease on the password. Every check-out gets a deadline (the workflow's window, or 60 minutes if no workflow is bound) and an expired one is closed automatically. The vaulted password itself does not change when the window ends unless rotation runs (Auto-rotate on check-in, or a workflow with Auto-reset secret on check-in). Someone who copied the password still has a working password until then.
Delete account destroys the vaulted secret and is refused while the account is checked out.

Personal vault

Route: /pam/personal. Your own private passwords, separate from the shared vault. Add personal item takes a category, title, username, URL, secret, optional TOTP seed and notes. Items are returned only to their owner; the secret and TOTP seed are held in the vault and the database holds non-secret metadata only. The export carries titles and usernames, never the secret.

Discovery

Route: /pam/discovery. Accounts found on hosts. Two sources feed it. An agent reports the accounts that can administer its own host (at check-in). A scan (Scan now) reads the host's full account list, including disabled and unprivileged accounts, and records which is which. A scan can be done by the server, or by a gateway serving the host's network. A row that cannot be scanned shows the reason instead of a button.

Controls (vault:write): Expect a host (name a host whose agent will fill this in), Scan now (or Scan through the gateway), and Add to vault on a discovered account (choose a resource first). The platform never invents a password for an account that already exists on the host, so adding one needs its Current password (checked against the optional password rules before it is stored).

Groups

Route: /pam/groups. Resource groups and SSH-key groups, static (explicit members) or dynamic (a criterion matched against the inventory). Grouping is for organising and reviewing. A group does not apply a policy or a share to its members.

Requesting and approving access

Access requests

Route: /pam/access. Two lists: Pending approvals (approve or deny, vault:write) and My requests (with Check in, sessions:request, to end an approved window early). Requests for an access-controlled account land here; access is time-boxed once approved.

If the account's workflow asks for more than one approval, the window starts only when that many different people have approved. The requester cannot approve their own request, and the same person approving twice counts once. A request whose workflow cannot be read is refused rather than treated as needing one approval.

Just-in-time

Route: /pam/jit. See Choosing between just-in-time and break-glass.

A JIT request asks for temporary admin rights on a host, not for a password. Request access (sessions:request) takes an Access type, Target host, OS account to elevate (only for Local admin and Linux sudo), Duration (minutes) and Reason. It goes to the approvals queue. Approve and Revoke now need vault:write.

On approval the platform creates the grant and then tries to provision it:

Local admin and Linux sudo are provisioned. If the host has an enrolled agent, the server queues the change to that agent (the grant shows Provisioned: see note until the agent acknowledges). If not, it falls back to an agentless SSH connector that logs in with a vaulted account on that host and adds the user to the sudo / wheel group.
AD group, Cloud IAM and Database role are listed in the type picker but are not provisioned. An approved request of those types becomes a grant marked failed that confers nothing, and Provisioned reads see note with the reason. The approval itself stays on record.

Expiry. A background process marks grants past their deadline expired and removes the privilege. For agent-managed hosts the queued command also carries a time limit of its own (the grant's duration), so the agent removes the privilege itself even if the server's revoke never arrives. Revoke now ends a grant early and removes the privilege the same way. If the host has no agent and no connector can reach it, the removal is the part that can fail: check the Provisioned column and the grant detail.

A grant is only the privilege it provisioned. It does not gate session brokering or check-outs.

Break-glass

Route: /pam/break-glass. See Choosing between just-in-time and break-glass.

What it is for. Last-resort access to a critical vaulted credential when the normal paths have failed, under dual control. What it costs: two other people's attention, a recorded reason, and a credential that is rotated afterwards.

The ceremony, as the Stage column shows it:

Requested. Request emergency access (vault:write): pick a Vaulted account, write the Reason (required: it is the whole justification on the record), and choose Approvals required (1, 2 or 3; 2 is the default). The request is also raised in the approvals queue as a critical request.
Approved. Approve (vault:write). The requester can never be one of the approvers, and nobody can approve twice. A refusal is shown on the row in words. An approval from the approvals queue counts the same.
Opened. Open (reveal secret) (vault:write). The audit entry (pam.break_glass.open) is written before the password leaves the vault; if the audit write fails, nothing is revealed. The password is shown once, in a dialog.
Closed. Close & rotate (vault:write) rotates the account's secret, writes pam.break_glass.close, and closes the event.

A request that should not proceed can be ended with Withdraw request while it is pending or approved. That records who ended it and why (withdrawn by the requester, denied by anyone else). Once opened it cannot be withdrawn: close it, which rotates the credential.

What to know before you rely on it:

Break-glass reveals the vaulted account password, taken from the vault the same way a check-out does. Opening it does not go through the sharing, workflow, ticket or Zero-Trust checks; the dual approval is the control. Open is available to any holder of vault:write.
The emergency window is recorded, not enforced. Opening stamps an expiry 60 minutes out. The event stays open and the credential stays valid until someone closes it.
Closing needs the account to be rotatable. If the account cannot be rotated (no agent, gateway or route to the host), Close & rotate returns an error and the event stays open with the credential revealed. On an agent-managed host rotation is queued, the event is marked closed, and the audit entry records rotated: queued; the host changes when the agent acknowledges.
Approval is by people with vault:write, not by a named approver group. Anyone with vault access other than the requester can approve.

This is not the offline endpoint recovery key. The platform has a second feature also called break-glass: lifting a device's network isolation. An administrator reads a 15-minute key from the device page; the person at the machine types it into the desktop app; the agent verifies it against a sealed secret on the machine with no network involved. The agent counts attempts and stops after 10, until the agent is restarted. That belongs to the device screens, not to /pam/break-glass; see Home for devices. It does not reveal any vaulted credential.

Choosing between just-in-time and break-glass

They are easy to confuse because both are used when someone needs more access than they have. They answer different questions and carry different controls.

	Just-in-time (`/pam/jit`)	Break-glass (`/pam/break-glass`)
What you get	Admin rights for an OS account on a host (sudo / local admin)	The plaintext password of a vaulted account, once
Who may ask	`sessions:request`	`vault:write`
Approval	One approval in the queue by default (a threshold may be configured per request type)	2 by default (1 to 3), never the requester, never the same person twice
Reason	Required on the form	Required, and written to the audit log before the reveal
It ends by	Expiry; Revoke now; the agent's own time limit	A person pressing Close & rotate. The 60-minute figure is recorded, not enforced
What happens to the credential	Nothing; it grants a privilege, not a secret	Rotated at close (can be refused or queued)
Provisioned by	The host's agent, or an agentless SSH connector	Nothing is provisioned; the secret is read from the vault
Works for	`Local admin` and `Linux sudo` only; the other three types fail	Any vaulted account

Use JIT for routine temporary elevation. Use break-glass when the normal paths have failed and you need to log in as the account yourself.

Sessions and monitoring

Connections

Route: /pam/connections. The launcher. Search or filter Favorites; per account Connect, Files (SFTP: browse, upload, download, delete) and Request access, all sessions:request. Connect takes a Protocol, a Reason, and a Ticket when ticketing is required (checked against your ticketing system; it must be open). The credential is injected by the gateway and never shown. The lower card lists Active privileged sessions: Watch (sessions:shadow, joins read-only) and Terminate (vault:write).

Before a session opens the server applies, in order, the share level, the access workflow, the Zero-Trust decision and the ticket gate. The ticket gate fails closed: if the ticketing system cannot be reached the session is refused. The gateway must be configured; if it is not, the broker refuses instead of opening a session that cannot load. The operator's browser must be able to reach the gateway directly.

Database session

Route: /pam/sql. Run SQL against a vaulted database account without ever seeing its credential: the server checks the account out and is itself the database client. Pick an Account, give a Reason (sessions:request), then Open session and Run (Ctrl or Command plus Enter). Only database engines with a session driver are offered, and the screen says how many vaulted database accounts it cannot offer and why. PostgreSQL and MySQL/MariaDB are supported.

It is one connection, one statement at a time, with bounded result sets (a result cut at a row limit says so) and a two-minute statement timeout. It is not a replacement for a SQL client. An idle session is closed after about ten minutes; the page sends a heartbeat every minute.

Two kinds of refusal appear differently on purpose. A command rule set to end the session refuses the statement and the session ends. A data policy denial leaves you connected. The check-out, approval gate and ticket requirement apply exactly as elsewhere.

Session recordings

Route: /pam/recordings. Every privileged session brokered, and what became of its recording: Available (with Replay), Purged, Not recorded or Pending. Tiles count recordings, unrecorded sessions, purged recordings and recorded bytes. Below the table is the Recording policy card.

What is captured.

For RDP, SSH, VNC and telnet through the gateway: the gateway records the screen, and the recording is converted to an MP4 per session.
For SSH and telnet, the gateway also keeps a terminal transcript. That transcript is the only place on the platform where what was typed exists. It feeds the replay timeline and Command control. It is written whether or not the screen is being recorded, is governed by the same retention policy, and the transcript file is deleted as soon as it has been read. RDP and VNC have no command stream; for those the video is the whole record.
For database sessions, every statement is on the session timeline.
For browser (https) sessions, the recording is made by the browser extension on the operator's own machine, and only while the recorded tab is on screen. The screen marks these captured on the endpoint because someone who controls that machine can stop the capture. A gateway recording cannot be stopped that way.

Where it is stored. The converted MP4 is uploaded to the object store shortly after the session ends, and the session record keeps the path and size. If no object store is configured, recordings are not uploaded.

Recording policy. Recording is set per resource, and the choice is on the record:

Resource policy	What happens
Always record (the default)	Every session is recorded. A request not to record is refused, recorded as `override_refused`, and written to the audit log as `pam.session.recording_override_refused`.
Let the operator choose	The operator's choice is stored on the session either way.
Never record	Never recorded. The live session page says so to whoever connects.

An unrecognised policy value records. The decision is stored on every session, which is why this screen can say "Not recorded: this resource has recording disabled". Changing a resource's policy needs vault:write and is audited (pam.resource.recording_policy_changed, with previous and new value).

Integrity and retention.

The client cannot switch recording off on an Always record resource. The server decides.
No control on this screen edits or deletes a single recording.
Retention deletes recordings. Keep recordings for is in days; 0 keeps them indefinitely and is the default. Values from 1 to 6 are refused; 7 or more is accepted. Recordings of sessions that ended more than that many days ago are deleted permanently, within the hour, and the session record says "purged under the retention policy". Saving it needs sessions:write. Shortening retention asks for confirmation.

The Recording policy card also holds the Pre-connect notice, shown before a session opens, and Require the operator to accept it before connecting. Watchers joining read-only are not asked.

Command control

Route: /pam/command-rules. Patterns matched against what is typed in a brokered session. Add rule and Remove need sessions:write. A rule has a Pattern (a regular expression matched anywhere in the command line, RE2 syntax: no lookaheads or backreferences, inline flags such as (?i) are allowed), an On match of Raise an alert or End the session, and What it is for, which is quoted back to whoever is cut off. No rules ship by default. The Try it against a command box tests in your browser; the server refuses a pattern it cannot compile.

What is enforced and what is only recorded. This depends on the session type:

Session type	What a rule does
SSH and telnet	Detects; does not prevent. The command is read from the terminal transcript about a second after it runs, so it has already executed. A terminate rule disconnects the session after the match. It does not undo the matched command; it stops what comes next. Every match is written to the audit log either way.
RDP and VNC	Nothing. There is no command stream to read. The screen recording is the whole record.
Database session (`/pam/sql`)	Prevents. The platform is the client, so a statement is evaluated before it is sent. A terminate rule refuses it; the database never receives it.

Recent matches are read from the audit log (pam.session.command_flagged), so you need audit:read to see them. Without it the card says so rather than showing an empty list. If no session commands have ever reached the platform, the screen says no rule has had anything to match: that is silence, not a clean estate.

Data policy

Route: /pam/data-policy. Which columns an operator may not read in a brokered database session. Classify a column, Scan a database and Remove classification need vault:write. A classification names a resource, schema, table and column, and an action:

Refuse the statement: it is never sent to the database.
Redact the value: the statement runs and the column comes back hidden. Only offered where the engine can attribute returned values to columns. On MySQL and MariaDB only refuse is available.

Where it is enforced. Only inside the brokered Database session on /pam/sql, before the statement is sent. The platform asks the database what the statement would return, which sees through select *, views, aliases and subqueries. It covers classified columns in the result, expressions over a classified table that the database could not attribute, writes to a classified table (coarse: the database does not say which columns an UPDATE sets) and filters or joins that name a classified column. Result columns are attributed by the database and are exact; conditions are matched by text against the planner's rendering with string values removed.

Where it is not enforced. Everywhere else. An RDP, SSH or any other session to the same database is not touched by a classification. A person with another route to the database sees everything. Database column privileges remain the floor. Resource types with no session driver are not offered here.

Scan a database reads the target's column catalogue (structure, never data) with a vaulted account that is checked out and straight back in, and proposes a shortlist by column name only. It finds customer_email and misses contact_1. It is a shortlist for you, not a classifier.

Behaviour analytics

Route: /pam/uba. When a privileged session ends, it is scored against that person's baseline. The score is the sum of four fixed deviations, capped at 100:

Deviation	Points
Start hour (UTC) not among the hours the person usually works	25
Source address not among their usual addresses	30
Target resource not among their usual targets	25
Duration more than twice their usual average	20

A score of 50 or more is recorded as an anomaly (type behavioural_deviation) and listed here with Replay. Risk reads medium from 50 and high from 75. The baseline is learned from the person's own sessions in the last 90 days and is formed only after 5 earlier sessions; the session being scored is left out of the baseline it is scored against. Until then there is no score, and an empty list means no session has ended or nobody has a baseline, not that scoring is off.

Scope. This is a fixed four-factor comparison, not machine learning, and it looks at where, when and for how long a person connected. It does not read commands, screen content or what was done in the session. It scores after the session has ended, so it cannot stop anything, and it does not notify anyone by itself. A person who always works from one address at the same hours and targets will not score high however destructive their session was; a normal change of working pattern will. Two deviations are needed to reach the threshold (no single factor reaches 50). Recent anomalies lower that user's Zero-Trust trust score, which a Zero-Trust policy can use to deny a check-out.

Keys, certificates and applications

SSH keys

Route: /pam/ssh-keys. Inventory and lifecycle of SSH keys, and a map of which key each host trusts. All of these controls need vault:write:

Generate key: an ed25519 keypair is created inside the vault. The private half is never returned. You get the public line to install. There is no key-type choice.
Import key: vaults a private key you hold (PEM) and derives the public half. It is not echoed back or kept in the browser.
Scan host: you paste a host's authorized_keys; every key in it is inventoried, and keys nobody vaulted are recorded as orphan keys trusted on that host. One scan records one account's file. The platform records what you paste; it does not log in to read the file on this screen.
Rotate: generates a new key and deploys it to every host that trusts the old one, through those hosts' agents. It refuses the whole rotation if any host that trusts the key has no enrolled agent, so nothing is half-rotated. It is asynchronous: the key rotates when the last host acknowledges. A key trusted nowhere cannot be rotated.
Restrict use of this key: a Forced command (the key can run only that one command; what the client asks for is discarded) and Allowed source hosts. The option line is written into authorized_keys through the host's agent in the same step, and the action is refused if the host has no enrolled agent.
Remove: removing a key does not revoke it. Entries already in authorized_keys files stay where they are.

Certificates

Route: /pam/certificates. TLS certificate tracking, not SSH certificates. Import certificate (vault:write) takes a pasted PEM and the server reads subject, issuer, SANs, validity and fingerprint. It refuses a pasted private key. The table warns amber inside 30 days and red once expired, with an Expiring <= 30 days (and expired) filter.

Renew (vault:write) issues a replacement from the UESP Managed CA with a fresh key held in the vault. It is only for certificates this platform issued: for an imported or discovered certificate the platform does not hold the private key, so the button is disabled and the server refuses. Renewing does not install anything. Download the Managed CA root and install it wherever the new certificate must be trusted.
Deployments (vault:read to view): record where a certificate is said to be in use. A recorded deployment is a claim, not a fact. Check targets connects to each target over TLS and compares the certificate it presents; only then does a claim become deployed.
Retire (vault:write): takes a certificate out of the expiry warnings. It is refused while deployment records exist unless you force it.
Network discovery probes hosts and ports you give it and records the certificates it finds (not already in the inventory is counted).
Certificate requests: generates a CSR (the private key is vaulted) to take to a CA. Once the CA issues it, import the certificate to track expiry.
Certificate authority (ACME): obtains publicly trusted certificates by DNS challenge. This obtains certificates. It does not install them. The platform shows you the DNS record, you publish it, you press Validate. There is no default authority; pick staging first.

Application credentials

Route: /pam/a2a. Application-to-application access is a different threat model from everything above. There is no person, no approval and no session. A program presents an identity and a secret token and gets a password back, and the controls are the registration, the source address and the allowed list. Human-access controls (approval, recording, dual control) do not apply to it.

Register application (vault:write) takes an Application name, an Application identity (what the app presents, exactly as it will send it), Secret paths it may fetch, and an IP allowlist, which is required: a single address, a CIDR range, or * for any source. An empty allowlist denies every fetch, so the form refuses it. The client token is shown once, on the page, until you press I have stored it - hide. Only its hash is stored, so nobody can retrieve it again. If it is lost, revoke the application and register again.

An application fetches by calling POST /api/v1/pam/a2a/fetch with its app_identity, token and the account_id it wants. The caller has no user session. The server checks, in order, the token, the source address, the allowed path and whether that path has been revoked. Anything else is refused, and one answer covers "unknown identity", "wrong token" and "ambiguous match" so the endpoint cannot be used to enumerate registrations. Refusals by a known application are recorded (pam.a2a.secret_refused, with the check that refused); a successful fetch is recorded as pam.a2a.secret_fetched with the application as actor and the account, never the secret.

What to know:

The allowed "path" is an account ID. The server matches an allowed entry against the account_id the application asks for: either exactly, or a prefix ending in /*. Enter account IDs, or an ID prefix with /*.
The "lease" is an audit record, not a short-lived credential. A fetch writes a lease that expires after 5 minutes, but the value returned is the live vaulted password. It does not stop working at lease expiry, and a fetch does not rotate it.
Revoking an application deactivates it and revokes its leases; its token stops working at once. A revoked lease is a standing bar on that path, not one that lapses.
* as the allowlist permits any source on the network to authenticate with the token. The screen warns you; narrow it where you can.
The record panel lists Secret retrievals (leases): what the app has fetched, not merely what it may.

Browser extension

Route: /extension. Pairs a Chrome or Edge extension with this console so vault credentials can be filled into the web pages they belong to without being shown. Pair this browser hands the extension the session this page is already using. It is held in the browser's memory only, not on disk, and is gone when the browser closes. The extension carries no credential of its own.

Install is manual for now (Load unpacked with Developer mode on); the extension is not yet in the Chrome Web Store.

A fill is a check-out. It passes the same checks as taking the password by hand and is audited with the page it was filled into. An account behind an approval workflow is offered as locked, not filled.
The page is matched on the server against the resource's Autofill address (exact host, or one wildcard label). There is no lookalike matching.
HTTPS only. If the platform is unreachable, the extension refuses: nothing is cached.
Autofill is off for a resource until you set its Autofill address.

Once a password is in a login box, that site's own JavaScript can read it. The extension avoids the clipboard and the screen, not that.

Policies, gateways and reports

Policies

Route: /pam/policies. Five tabs (all creation and deletion need vault:write):

Password Policies: minimum length, character classes, History count, Max age (days). The vault generator builds compliant secrets for accounts bound to a policy; a typed secret is checked against it and refused if short.
Access Workflows: Checkout window (min), Required approvals, Exclusive, Auto check-in on timeout, Auto-reset secret on check-in, Require a ticket ID. A workflow does nothing until you bind it to an account on Vault (Set access workflow). Required approvals is enforced as a count of different people on a request for an access-controlled account.
Zero-Trust: a policy names Min user score, Min resource score, an Action below threshold (audit, warn, justify, deny) and Priority. The user score is computed from real signals: MFA enrolled, no anomalies in the last 7 days (each recent anomaly lowers it), account active and not brand new. The resource score uses the resource's risk level, whether rotation is on and how recently it rotated. It gates check-out and session brokering. With no policy, check-outs are allowed unrestricted. If the policies cannot be read, access is refused.
Jump Hosts (landing servers): a bastion the gateway connects through to reach a target, with an optional Secondary host (failover). Bind one to an account on the Vault. When an account has one, the session must go through it.
Schedules: recurring jobs of kind rotation, verify, discovery_scan, cert_renewal and ssh_rotation. A verify schedule with a blank target sweeps every account in the organisation.

Change tickets (on the workflows tab) require an open ticket before access, looked up against your ticketing system. If the lookup cannot be reached, access is refused. You choose whether it applies to opening a session, to checking out the password, or both: they are different acts.

Gateways

Route: /pam/gateways. A gateway reaches machines the platform has no route to: another site, a separate VPN, a segment behind its own firewall. It runs inside that network and calls out to the platform, so no inbound firewall rule is needed. A gateway is a device: it enrols over the same mutual-TLS channel as any agent and takes work from the same command queue. Add a gateway (vault:write) takes a Name, The machine it runs on (any enrolled machine with the agent) and Networks it can reach (one per line; empty means only systems assigned to it by name). The agent on that machine fetches the gateway and starts it.

Health is derived from the device's heartbeat: calling in, starting, not calling in (a quiet gateway means every target behind it is unmanageable), turned off. Turn off, Edit name and networks and Remove gateway need vault:write. Removing a gateway leaves the systems in the vault but loses the platform's only route to them. Routing never guesses: a target no gateway covers is reported as having no route.

Reports

Route: /pam/reports. Ready-made summaries of how privileged access stands now: credential inventory, rotation status, session activity (30 days), discovery posture, certificate posture and SSH-key posture. Below are Canned reports (row-level, export to CSV) and Compliance posture.

Tasks

Require approval for an account

Policies, tab Access Workflows, New workflow. Set Checkout window (min), Required approvals, and the check-boxes you want. Save.
Vault, the account's row menu, Set access workflow, choose it.
The account now shows access-controlled. People see Request instead of a working Connect.
An approver opens Access requests, Pending approvals, Approve. If you asked for 2, a second different person must approve before the window starts.

For tickets, set Change tickets on the same tab.

Give someone temporary admin on a host

Just-in-time, Request access (sessions:request). Pick Linux sudo or Local admin (the only types that are provisioned), the Target host, the OS account to elevate, Duration and Reason.
An approver (vault:write) presses Approve under Pending requests.
Check the Grants table. You want Provisioned: yes. see note means it is queued to the agent or failed; open the row.
It ends at Expires, or press Revoke now.

Reveal a critical password in an incident

Break-glass, Request emergency access. Pick the account, write what the incident is and what you need the credential for, and choose the approvals.
Ask the approvers to press Approve (they need vault:write; you cannot approve your own).
When the stage reads Approved, press Open (reveal secret) and copy the password from the dialog. It is shown once.
When you are done, press Close & rotate. If it errors, the account could not be rotated; fix the route to the host and try again, because until it closes the revealed password is still valid.

Find out why a session has no recording

Session recordings, find the session. The Recording column and the line under it give the reason: Not recorded (the resource's policy is Never record, or the operator declined where policy lets the operator choose), Purged (retention) or Pending (still open, or the upload has not finished, or none was captured).
For Not recorded, open the resource on Resources and read Session recording. The audit log has pam.resource.recording_policy_changed for when it was changed and by whom.
For Purged, read Keep recordings for on the Recording policy card.

Stop a dangerous command

Command control, Add rule. Enter a pattern, type a command in Try it against a command to see if it matches, and choose On match.
On SSH and telnet the command has already run and End the session only stops what follows. For prevention the person must be working in the Database session.
Read matches under Recent matches (audit:read).

Hide a column in database sessions

Data policy, Scan a database (pick a resource and a vaulted account) or Classify a column.
Choose Refuse the statement or Redact the value.
Ask someone to run a statement in Database session that returns it. They will see the statement was not sent. Other routes to the database are unaffected.

Let an application fetch a password

Application credentials, Register application. Enter the name, identity, the account IDs it may fetch and the addresses it may fetch from.
Copy the client token from the page and store it where the application can read it. You cannot see it again.
The application calls POST /api/v1/pam/a2a/fetch with app_identity, token and account_id.
Review Secret retrievals in the application's record, and revoke it if it should not have this access.

Reach machines in another network

Gateways, Add a gateway. Pick an enrolled machine inside that network and list the Networks it can reach.
Wait for calling in. The agent on that machine starts the gateway.
Vault accounts on resources in those ranges as usual. Rotation, verification and discovery for them are done by the gateway.

Limitations

SSH certificate authority signing is not offered as an operator workflow. There is no screen for it.
Vaulted passwords do not expire with a check-out. A check-out is a record with a deadline; the password stays valid until rotated.
An application credential fetch is not short-lived. The lease is an audit record (5 minutes). The password returned is live.
Command rules prevent only on the database session. On SSH and telnet they detect and can end the session after the match; on RDP and VNC they do nothing.
A data policy applies only inside the brokered Database session. Other routes to the same database are unaffected.
Column classification by scan is by name only.
Recordings can be deleted by retention by design, and a recording of a browser session is made on the operator's machine and can be stopped there.
A resource's recording policy can be set to Never record by anyone with vault:write (audited).
Behaviour analytics only scores, after the fact, on four fixed factors. It does not read what was done, alert anyone or block anything.
JIT provisions two of its five access types. AD group, Cloud IAM and Database role grants are marked failed and confer nothing.
Break-glass reveals the vaulted password and bypasses the sharing, workflow, ticket and Zero-Trust checks. Dual approval is the control. Its 60-minute window is recorded, not enforced, and Open is available to any holder of vault:write.
Groups organise; they do not apply a policy or share.
Certificate renewal installs nothing and works only for certificates the platform issued. A Deployments record is a claim until Check targets confirms it.
SSH key removal does not revoke access on hosts, and key rotation and restriction need an enrolled agent on every host that trusts the key.
High availability is not available for this module. A single vault and database serve it.
Personal vault privacy is an application rule, not a cryptographic one against the platform's operators.