Imagine a CI pipeline that spins up an autonomous coding agent to generate and apply database migrations on every pull request. The agent runs under a service account, never a human user, and it needs to connect to PostgreSQL without embedding static passwords in source code or build scripts. At the same time, security teams demand full visibility of every statement the agent runs, the ability to block dangerous commands, and automatic redaction of any personally‑identifiable columns that might be returned.
Why non-human identity matters for AI agents
Non‑human identities eliminate the credential sprawl that comes from sharing static secrets among bots, scripts, and contractors. When an AI‑driven agent authenticates with an OIDC token, the token proves who (or what) is making the request without exposing a password. However, a token alone does not enforce policy. The request still travels straight to the database, potentially leaking data, executing unintended DDL, or bypassing audit requirements. Without a control point in the data path, the organization cannot guarantee that every query is recorded, that sensitive fields are masked, or that risky statements are reviewed before execution.
Putting the gateway in the data path
The missing piece is a Layer 7 gateway that sits between the identity provider and PostgreSQL. This gateway becomes the sole place where enforcement can happen. It validates the OIDC token, extracts group membership, and then decides whether the request may proceed. Because the gateway proxies the native PostgreSQL wire protocol, the client sees no difference in its workflow – it still uses psql or any standard driver – but the connection never reaches the database without first passing through the gateway.
How hoop.dev enforces policies on Postgres
hoop.dev fulfills the gateway role. It receives the AI agent’s OIDC token, confirms the token against the configured IdP, and maps the token to a scoped identity that is allowed to run only the migration‑related statements required for that CI run. The gateway holds the actual PostgreSQL credentials, so the agent never has direct access to the password. Once the request is authorized, hoop.dev forwards it to the database over TLS, records every SQL statement at command level, and applies inline data masking to any columns marked as sensitive. If a statement matches a guardrail rule – for example, a DROP DATABASE – hoop.dev blocks it and can route the request to a human approver before allowing it to continue. All of these outcomes – audit logging, masking, guardrails, just‑in‑time approval, and session recording – exist only because hoop.dev sits in the data path.
Key enforcement outcomes
- Command‑level audit: Each query the AI agent issues is captured in an immutable log that can be replayed for compliance reviews.
- Inline masking: Sensitive columns such as SSN or credit‑card numbers are redacted before the result reaches the agent, protecting downstream services from accidental exposure.
- Just‑in‑time access: The token grants the minimum scope needed for the specific CI job, and the grant expires as soon as the pipeline finishes.
- Guardrails and approvals: Potentially destructive statements are either blocked outright or sent to an approver for manual sign‑off.
- Credential offload: The database password lives only in the gateway, eliminating secret leakage in CI configuration files.
Because hoop.dev is the only component that can see the raw SQL traffic, it is the authoritative enforcement point. Removing hoop.dev would return the request to a direct connection, losing all of the above guarantees.