The common misconception is that a service account or API token behaves like a regular user credential – that its impact is limited to the single query it runs. In reality the blast radius of a compromised non‑human identity can span an entire database cluster, especially when that identity has broad privileges.
When a service account is granted read‑write access to many schemas, a single stolen token can enumerate tables, exfiltrate data, or even drop critical objects. The damage is not confined to the initial request; downstream jobs, scheduled tasks, and replication pipelines may all inherit the malicious changes. Understanding how non‑human identities amplify blast radius is the first step toward containment.
Why non‑human identities expand blast radius
Non‑human identities are typically created for automation: CI/CD pipelines, backup agents, or monitoring tools. Because they are meant to run unattended, they are often given long‑lived credentials and wide‑ranging permissions. This convenience translates into risk. If an attacker extracts the credential from a compromised build server, they inherit every permission the service account holds. Unlike a human user who might be prompted for MFA or have session limits, a service account can issue hundreds of queries in a short window, giving the attacker time to locate valuable data before detection.
PostgreSQL’s role inheritance model can unintentionally broaden that reach. A role that is a member of multiple higher‑level roles inherits all their privileges. A single compromised token can therefore act as a super‑user within the scope of the inherited roles, touching tables, functions, and extensions across multiple databases. The blast radius is thus a function of both the credential’s lifetime and the privilege hierarchy it participates in.
Where enforcement must happen: the data‑path gateway
Setup steps such as assigning least‑privilege roles, rotating secrets, and using OIDC tokens decide who may start a connection. Those steps are necessary but not sufficient to stop a compromised token from wreaking havoc. The only place to enforce fine‑grained controls is in the data path – the point where the request actually reaches PostgreSQL.
When a request passes through a Layer 7 gateway, the gateway can inspect each SQL statement, apply inline masking to sensitive columns, and block commands that match a risky pattern. It can also require a human approval step before executing DDL statements or mass‑delete operations. Because the gateway sits between the identity and the database, it can record every session, replay it for audit, and enforce just‑in‑time access limits that are impossible to achieve with static role assignments alone.
How hoop.dev provides the required data‑path controls
hoop.dev is designed to sit in that critical data‑path position. It proxies PostgreSQL connections, validates the user’s OIDC token, and then applies policy checks before forwarding the query. hoop.dev records each session, masks columns that contain personally identifiable information, and can reject commands that exceed a predefined risk profile. By operating at the protocol layer, hoop.dev ensures that even a perfectly valid service account cannot bypass the guardrails.
Because hoop.dev holds the database credential internally, the service account never sees the actual password or IAM role used to connect. This eliminates credential leakage from the client side. The gateway also supports just‑in‑time approval workflows, so a backup job that normally runs without supervision can be required to obtain a short‑lived approval before performing a destructive operation. The result is a dramatically reduced blast radius: the attacker can still issue queries, but each high‑impact action is either masked, logged, or blocked.
Practical steps for teams using Postgres
- Audit all service accounts and map the privilege inheritance tree. Identify any role that grants super‑user or wide‑schema access.
- Replace long‑lived static passwords with short‑lived tokens managed by an identity provider. Use OIDC to let hoop.dev verify the token.
- Deploy hoop.dev as the sole entry point for PostgreSQL traffic. Configure policies that mask credit‑card columns and block DROP/ALTER statements unless an explicit approval is recorded.
- Enable session recording in hoop.dev so that every query can be replayed during incident response.
- Integrate the gateway’s approval workflow with your CI/CD pipeline so that automated jobs request just‑in‑time access before executing privileged commands.
These actions move the enforcement boundary from the database itself to a controllable, observable gateway, turning a single compromised token from a catastrophic blast radius into a contained, auditable event.
Getting started
To see the gateway in action, follow the getting‑started guide and explore the feature documentation on the learn page. The open‑source repository contains the full implementation and example configurations.
Explore the source code and contribute on GitHub.
