Securing Postgres from Non-Human Identities with a Binary Protocol Proxy

The logs showed a connection, but no human was behind it. The request hit your database through the Postgres Binary Protocol. It wasn’t a user—it was a service account, a bot, or another machine identity. Your monitoring didn’t flag it. Your auth layer didn’t challenge it. And yet, it had full access.

Non-human identities are now a primary way systems interact. They run migrations, sync data, and feed analytics pipelines. They’re also a growing vector for security risks. Direct database connections over the Postgres Binary Protocol bypass HTTP layers where most identity tools live. Without visibility into that protocol, you can’t see or control what’s happening.

Proxying the Postgres Binary Protocol fixes this gap. Instead of letting machine identities hit Postgres directly, traffic passes through a proxy that understands the binary protocol. This proxy can enforce authentication, log queries, and associate each action with a specific non-human identity. It works without breaking protocol compliance or adding latency that would choke automated jobs.

Building a Postgres Binary Protocol proxy for non-human identities means handling startup messages, authentication handshakes, and message formats defined by the protocol’s wire spec. You need to parse messages in real time, inspect startup parameters, and inject identity checks before the backend accepts the session. It requires precise control over network sockets and correct re-emission of backend responses.

Security here depends on mapping each service account or bot to a distinct credential set. The proxy can enforce short-lived credentials or dynamic secrets issued by your identity provider. This makes credential rotation trivial and closes the door on long-term key leakage. Even better, you can log every connection by identity, tie queries to specific systems, and limit access to the exact schemas or tables they need.

This approach scales. Multiple Postgres instances can sit behind a single proxy layer with sharded routing. Machine identities authenticate once and the proxy keeps the backend connections alive, multiplexing binary protocol sessions as needed. The result is full observability, precise access control, and reduced risk for one of the most opaque parts of your stack.

Protect your Postgres from silent machine access. Give non-human identities the same level of authentication, authorization, and audit trail as human users. See how simple it is to put a Postgres Binary Protocol proxy in place—visit hoop.dev and watch it run in minutes.