An offboarded contractor’s CI pipeline still holds a service account that can run psql against your production database. The token never expires, the job still fires nightly, and the queries it issues appear in the same audit logs as those from human engineers. When you sit down for your quarterly access review, the presence of that non‑human identity blurs the line between legitimate automation and forgotten privilege.
Non‑human identities, such as service accounts, CI tokens, bots, and API keys, are essential for modern pipelines. Yet they also introduce a blind spot in traditional access reviews. Human‑focused processes tend to ask, “Who is this user? What role do they have?” but they rarely ask, “What automated process owns this credential? How often does it run? Which data does it touch?” The result is a growing inventory of credentials that sit idle, over‑scoped, or simply escape notice until a breach surfaces.
Why non‑human identities complicate access reviews
Human reviewers rely on visible signals: login timestamps, MFA prompts, and personal identifiers. Non‑human identities lack those cues. A token can be issued once and used indefinitely, and its activity may be indistinguishable from a developer’s interactive session. This makes it hard to answer three core questions during an access review:
- Ownership: Who created the credential and who is responsible for its lifecycle?
- Scope: Does the permission set match the actual needs of the automation?
- Usage patterns: Is the credential still in active use, or has it become stale?
Without clear answers, reviewers may either over‑grant permissions to stay safe, or inadvertently leave dangerous credentials active. Both outcomes increase risk – the former expands the blast radius, the latter creates a foothold for attackers.
What to look for in PostgreSQL access reviews
PostgreSQL itself provides role‑based access control, but it does not differentiate between a human session and an automated client. When you audit PostgreSQL permissions, focus on these observable traits:
- Connection source: Identify the IP ranges or hostnames that initiate connections. A narrow set of internal CI runners suggests a legitimate automation path.
- Application name: PostgreSQL clients can set an application_name parameter. Enforcing a naming convention, such as ci‑pipeline‑job‑123, helps surface non‑human sessions in logs.
- Query patterns: Automated jobs often run a predictable set of statements – schema migrations, health checks, or data imports. Spotting repetitive, time‑bound queries can reveal a service account’s purpose.
- Privilege level: Verify that the role assigned to the service account does not exceed the minimum required. The principle of least privilege applies equally to bots.
Even with diligent logging, the raw audit trail does not enforce any guardrails. It merely records what happened. To turn that record into a control surface, you need a point in the data path where policy can be applied before the request reaches PostgreSQL.
How a gateway can bring visibility and control
Placing a Layer 7 gateway between identities and PostgreSQL creates a single enforcement surface. The gateway sits in the data path, intercepts every protocol message, and can apply the controls you need for effective access reviews.
Setup. Identity is still managed by your existing OIDC or SAML provider. The gateway validates the token, extracts group membership, and decides whether the request may start. This step determines who the request is, but it does not enforce any fine‑grained policy on its own.
The data path. The gateway becomes the only place where enforcement can happen. It sees each SQL statement before it reaches PostgreSQL, and it can apply masking, command approval, or outright blocking based on the identity and the policy attached to that identity.
Enforcement outcomes. Because the gateway sits in the data path, it can:
- Record every session for replay, giving auditors a complete timeline of who ran what and when.
- Mask sensitive columns in query results, ensuring that even a privileged service account never sees raw credit‑card numbers or personal identifiers.
- Require just‑in‑time approval for risky commands, such as DROP DATABASE or bulk deletes, routing them to a human reviewer before execution.
- Block disallowed statements automatically, preventing runaway scripts from causing damage.
All of these outcomes exist only because the gateway, hoop.dev, sits in the data path. Without that layer, the PostgreSQL server itself cannot distinguish a bot from a user, nor can it enforce per‑command policies without custom extensions.
Deploying hoop.dev is straightforward. The quick‑start guide walks you through launching the gateway with Docker Compose, registering a PostgreSQL target, and wiring your OIDC provider. Once in place, you can define policies that tie non‑human identities to the exact set of statements they may execute, and you gain a replayable audit log that satisfies even the most stringent compliance programs. For step‑by‑step instructions, see the getting‑started guide.
Practical steps to tighten access reviews
- Catalog every service account that connects to PostgreSQL. Use the learn portal to understand how hoop.dev discovers and classifies connections.
- Map each account to a minimal role in PostgreSQL. Reduce privileges until the account can only run the required queries.
- Configure hoop.dev to enforce just‑in‑time approvals for any DDL or bulk DML operations. This adds a human checkpoint without slowing down routine reads.
- Enable session recording in hoop.dev. The recorded logs become the evidence you need for quarterly access reviews and audit inquiries.
- Regularly review the gateway’s audit reports. Look for stale tokens, unexpected application names, or connections from unknown hosts.
FAQ
Q: Do I need to replace my existing PostgreSQL authentication?
A: No. hoop.dev acts as a proxy that validates the same OIDC token you already use. It does not replace the database’s native authentication.
Q: Will hoop.dev add latency to my queries?
A: The gateway operates at the protocol layer and adds only minimal overhead. For most workloads the impact is negligible compared to the security benefits.
Q: Can I still use native PostgreSQL tools like psql?
A: Yes. Users and automation point their client at the gateway endpoint. The client experience remains unchanged.
By treating non‑human identities as first‑class citizens in your access review process and by inserting a gateway that enforces policy at the data path, you close the visibility gap that bots and service accounts create. hoop.dev provides the enforcement surface you need to turn raw logs into actionable controls.
Explore the source code on GitHub to see how you can extend the gateway for your own compliance requirements.
