SCRAM for Agent Credentials: Stop Sending Passwords Over the Wire
When a client authenticates to Postgres with a password, there is a choice about how the password is presented. The simplest method sends the password itself, protected only by the encrypted channel. SCRAM is the better one: it proves the client knows the password without ever sending the password.
PgBeam supports SCRAM-SHA-256 for credentials. For an agent's credential, this is the auth method you want.
What SCRAM does
SCRAM (Salted Challenge Response Authentication Mechanism) is a challenge-response protocol. Instead of transmitting the secret, the client and server exchange proofs derived from it:
- The client sends a nonce and a username.
- The server responds with a salt and an iteration count.
- The client computes a proof from the password, salt, and nonces, and sends only the proof.
- The server verifies the proof against what it has stored, and sends its own proof back so the client knows it is talking to the real server.
The password never crosses the wire. Not in plaintext, not in a reversible form. An attacker who captured the entire exchange would have a proof tied to specific nonces, not a reusable credential.
"But TLS already encrypts it"
True, and TLS is non-negotiable; PgBeam terminates it for every connection. But "the channel is encrypted" and "the password is never sent" are different guarantees, and you want both.
Encryption protects the password in transit against someone on the network. It does nothing about the password existing, in usable form, at the moment it is presented. SCRAM removes that moment entirely. The secret is never in a packet to be captured if the TLS layer is misconfigured, downgraded, terminated somewhere you did not expect, or logged by something that sees decrypted traffic. Defense in depth means not relying on a single layer to protect a reusable secret. SCRAM is the layer that makes the secret non-reusable even if everything around it fails.
Why it matters more for agents
An agent's credential gets handled by more software than a human's does. It is stored in a config, passed to a framework, sometimes echoed into a log during debugging, sometimes pasted into a tool. Every one of those is a place a transmitted password could leak.
SCRAM shrinks that exposure. The stored credential authenticates by computing a proof, not by handing the password to each layer that needs to connect. The fewer places a reusable secret appears in transmittable form, the fewer places it can leak from. For a credential that may be held by an autonomous process you are deliberately keeping at arm's length, that reduction is exactly the point.
How to use it
Configure the credential to authenticate via SCRAM. Standard Postgres drivers already support SCRAM-SHA-256, so most clients negotiate it automatically once it is enabled, with no application change. The agent connects the same way it always did. The handshake underneath is just stronger.
This pairs with the rest of the credential's policy. SCRAM hardens how the credential proves itself; scoping, read-only enforcement, allowlists, and budgets decide what it can do once it has. Strong auth on a tightly scoped credential is the combination you want before you let an agent near production. It is one piece of least-privilege database access for agents: minimize the grant, and minimize the ways the grant can leak.
Try PgBeam or see the full feature set.