Audit AI agents operating on Postgres clusters managed by Hybrid Manager (HM) or monitored through a standalone Loki instance. The audit log viewer reads Postgres query logs that may contain sensitive data and holds credentials for the upstream sources it audits. There are two distinct authentication layers, and all credentials live server-side — none are exposed to the browser.
| Layer | Question it answers | Mechanism |
|---|---|---|
| User authentication | Who may sign in to the viewer? | Identity federation through Dex (OIDC) |
| Upstream authentication | How does the backend reach HM or Loki? | Machine user API keys |
Authenticating users
Sign in through Dex, which federates to your upstream identity providers:
- The backend is an OIDC client of Dex. Dex brokers login to the configured connector — OIDC, SAML, or LDAP — and reports which identity provider authenticated the user.
- On success, the backend mints a server-side session: a signed cookie, with refresh and ID tokens encrypted at rest. Tokens never reach the browser.
- A bootstrap admin exists before any identity provider is configured. Use it for first login, then add a federated identity provider and switch day-to-day login to it.
- Admin gating — a user is an administrator if their email is in the admin allowlist, or if their
groupsclaim includesgovernance-admin. Admin-only surfaces, such as identity provider management, are gated on this.
For configuring identity providers, see Deploying and configuring.
Authenticating upstream sources
Authenticate to upstream sources using machine user API keys — shared credentials that grant access to an entire HM dataplane or Loki instance. These keys are:
- Created in the HM admin portal (for HM instances) or configured externally (for Loki).
- Stored in the backend's Postgres database.
- Injected server-side on every proxied request.
- Never included in responses to the browser — they're cleared on the server and omitted.
The backend adds the appropriate header based on the instance type:
| Instance type | Header | Format |
|---|---|---|
| HM | x-access-key | The raw key value, for example hmak_abc123... |
| Loki | Authorization | The full header value, for example Bearer token123... |
Storing credentials at rest
The backend maintains two credential stores in its Postgres databases:
- The viewer's database holds instance access keys and user sessions.
- The Dex database holds identity provider connector secrets, such as OIDC client secrets and LDAP bind passwords, in cleartext.
Keep the underlying storage volume on encrypted-at-rest storage — LUKS or dm-crypt, cloud disk encryption, or an equivalent. The Dex connector credentials in particular have no application-layer encryption, so volume-level encryption is the protection that matters.
Protecting the network
The viewer enforces several network-level protections.
TLS verification. OIDC TLS verification — for discovery, JWKS, and token exchange — is always on and can't be disabled. To trust a self-signed or private-CA issuer, supply a CA bundle, which is added to the system trust pool rather than bypassing verification.
Upstream egress controls. By default, the backend blocks instance egress to private network ranges so that a registered instance can't be used to probe your internal network. Cloud metadata, loopback, and link-local addresses stay blocked regardless. Allow private ranges only for on-premises deployments whose HM or Loki upstreams legitimately live on private IPs.
Cross-origin requests. The viewer and its backend are served from a single origin in normal operation, so cross-origin access to the backend API is restricted to the origins you explicitly allow.
Handling data
Review Postgres query logs that include the SQL text agents executed, along with execution metadata such as the target database, Postgres role, and duration.