Secure access to EDB Agent Governance and protect the credentials and data it holds. The viewer reads AI agent telemetry from Postgres databases running the aidb extension and, on the legacy path, Postgres query logs from Hybrid Manager (HM) or a standalone Loki instance. Both can contain sensitive data, and the viewer holds credentials for every upstream source 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 the source database, HM, or Loki? | A read-only Postgres role for aidb databases; machine user API keys for HM and Loki |
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 Configuring.
Authenticating upstream sources
Connect the backend to an aidb database as a dedicated login role that can only read the telemetry tables, over TLS with CA verification (sslmode=verify-ca or verify-full), optionally with a client certificate. The role should have no write privileges and no aidb administration rights; see Creating the viewer role. The connection string and certificates are encrypted at rest and never returned to the browser.
For the legacy HM and Loki sources, the backend authenticates 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
Review the two credential stores the backend maintains in its Postgres databases:
- The viewer's database holds instance credentials —
aidbconnection strings and certificates, and HM and Loki 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
Review the network-level protections the viewer enforces.
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 HM and Loki 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.
Source databases running aidb usually live on private addresses, so this guard is off for them by default. To turn it on, set the chart value bff.aidbBlockPrivate to true.
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 what data the viewer reads. For an aidb database, the viewer reads the spans and log records aidb stored: the SQL text agents executed, tool calls, agent and purpose attributes, governance decisions, and timing. Reads never write to the source database. For HM and Loki sources, the viewer reads Postgres query logs that include the SQL text agents executed, along with execution metadata such as the target database, Postgres role, and duration.