When a CI pipeline that builds Docker images is decommissioned, the service account it used should disappear instantly. Instead, an over‑scoped token lingers in the secrets store, and a nightly backup job continues to query the production PostgreSQL database with full admin rights. The result is a gap in accountability that violates SOC 2’s Access Control and Monitoring principles.
Non‑human identities, service accounts, CI jobs, automation bots, are essential for modern delivery pipelines, but they also create blind spots. SOC 2 expects organizations to demonstrate who accessed what, when, and why. For machines, that means continuously collecting evidence of credential issuance, request authorization, and actual data movement.
What SOC 2 demands for machine‑driven access
SOC 2’s Trust Services Criteria (TSC) for Security and Availability require:
- Documented policies that enforce least‑privilege for every identity.
- Immutable logs that capture every successful and failed access attempt.
- Evidence that privileged actions are reviewed or approved before execution.
- Controls that prevent sensitive data from leaking during routine queries.
When a service account is created, the organization must be able to prove that the account was granted only the permissions needed for its job, that the account’s usage was monitored, and that any deviation was recorded and could be replayed for an audit.
Why the data path matters
Identity providers (Okta, Azure AD, Google Workspace) can issue short‑lived tokens that identify the caller. That step, the setup, tells the system *who* is making the request and whether the request may start. However, the token alone cannot enforce what the request does once it reaches PostgreSQL. Without a control point on the data path, a compromised token could run arbitrary commands, exfiltrate rows, or alter schema without leaving a trustworthy trail.
Placing enforcement at the gateway ensures that every SQL statement passes through a single, tamper‑resistant layer where policy can be applied. That layer can:
- Validate the request against the least‑privilege policy.
- Require a human approver for risky statements such as DROP DATABASE or DELETE FROM users WHERE role='admin'.
- Mask columns that contain personally identifiable information before they are returned to the client.
- Record the full session for replay during an audit.
hoop.dev as the enforcement point for PostgreSQL
hoop.dev is a Layer 7 gateway that sits between non‑human identities and the PostgreSQL server. It authenticates callers via OIDC, reads group membership, and then proxies the connection. Because the gateway is the only place the traffic flows, hoop.dev can apply the controls described above.
Key enforcement outcomes that hoop.dev delivers:
- Session recording: Every query and response is archived, providing an immutable audit trail that satisfies SOC 2’s logging requirement.
- Inline masking: Sensitive columns are redacted in real time, preventing accidental leakage while still allowing the application to function.
- Just‑in‑time approval: High‑risk statements trigger a workflow that pauses execution until a designated reviewer approves.
- Command blocking: Disallowed statements are rejected before they reach the database, reducing blast radius.
- Scoped credentials: The gateway holds the PostgreSQL password; callers never see it, eliminating credential sprawl.
Because hoop.dev sits in the data path, each of these outcomes is guaranteed to happen for every machine‑initiated session. Removing hoop.dev would eliminate the enforcement layer, and the SOC 2 evidence would disappear.
Mapping enforcement outcomes to SOC 2 criteria
• Access Control (CC6.1) – hoop.dev enforces least‑privilege policies on every request, ensuring that a service account can only run the commands it was authorized for.
• Change Management (CC6.2) – Approvals for schema‑changing statements create a documented change‑control process.
• Monitoring (CC6.3) – Continuous session logs and real‑time alerts give auditors a complete view of machine activity.
• Confidentiality (CC6.4) – Inline masking protects PII at the source, providing evidence that the organization controls data exposure.
Getting started with hoop.dev for PostgreSQL
To build a SOC 2‑ready pipeline, follow these high‑level steps:
- Deploy the hoop.dev gateway using the getting‑started guide. The gateway runs as a Docker container or in Kubernetes, close to the PostgreSQL instance.
- Register the PostgreSQL endpoint in hoop.dev, supplying the host, port, and a service‑level credential that the gateway will manage.
- Configure OIDC authentication so that each automation job receives a short‑lived token that identifies the job’s purpose.
- Define policy rules that map OIDC groups to allowed SQL commands, set up masking rules for columns such as email or ssn, and enable just‑in‑time approval for destructive statements.
- Run your CI jobs, bots, and batch processes through the hoop.dev CLI or standard PostgreSQL client, pointing them at the gateway address instead of the database directly.
All of the operational details, compose files, Helm charts, policy syntax, are covered in the learn section. The repository at github.com/hoophq/hoop contains the full source and example configurations.
FAQ
Does hoop.dev replace existing IAM policies?
No. IAM or cloud‑provider roles still decide which service accounts can obtain OIDC tokens. hoop.dev complements those policies by enforcing what the token can do once it reaches PostgreSQL.
How long are the audit logs retained?
Retention is configurable in the gateway’s storage backend. For SOC 2 compliance, organizations typically keep logs for at least one year.
Can I use hoop.dev with other databases?
Yes. hoop.dev supports MySQL, MSSQL, MongoDB, and many other backends. The same enforcement principles apply, providing SOC 2 evidence across your data stack.
By placing a transparent, policy‑driven gateway between non‑human identities and PostgreSQL, hoop.dev turns fleeting service tokens into a continuous source of SOC 2‑ready evidence.
