An internal AI coding agent that automatically writes pull requests is given a hard‑coded PostgreSQL user with superuser rights. The bot runs nightly, pulls data, and pushes changes without any human eyes on the queries it issues. The organization wishes to move to just-in-time access, yet the credential remains permanent. When the credential is later compromised, the attacker can read every table, drop data, or exfiltrate PII, and the incident team has no record of which statements were executed. The team has no way to verify the agent’s actions or limit its scope.
Why just-in-time access matters for AI coding agents
AI‑driven automation is valuable, but it also expands the attack surface. A static database account gives the agent unrestricted reach for the lifetime of the secret. If the code that drives the agent is updated, the same credential persists, making it impossible to grant temporary privileges that match the exact workload. Just-in-time access solves that problem by issuing a scoped credential only for the duration of a single execution, then revoking it automatically. This approach reduces the window of exposure, enforces the principle of least privilege, and creates a clear audit boundary for every interaction with the database.
Architectural requirement: a data‑path enforcement point
Identity providers, OIDC tokens, and service‑account roles determine *who* can request a connection. Those components are essential for authentication, but they do not enforce *what* the request may do once it reaches the database. The enforcement point must sit on the data path, between the authenticated identity and the PostgreSQL server, so that every query can be inspected, recorded, and optionally transformed before it touches the backend.
In practice this means placing a gateway that terminates the client’s wire‑protocol connection, applies policy, and then forwards the request to the actual database. The gateway holds the database credential, so the AI agent does not have direct access to the password or IAM token. The gateway also knows the identity that originated the request, because the authentication layer has already validated the OIDC token.
Introducing hoop.dev as the enforcement gateway
hoop.dev fulfills the data‑path requirement by acting as a native wire‑protocol proxy for PostgreSQL. When an AI coding agent initiates a connection, it points its standard client (for example, psql) at the hoop.dev endpoint instead of the database host. hoop.dev validates the agent’s OIDC token, extracts group membership, and then decides whether to grant a temporary, scoped database session.
Because hoop.dev sits in the data path, it can provide the enforcement outcomes that are impossible with a pure identity‑only solution:
- Query‑level audit logging: every SQL statement issued by the agent is recorded with the originating identity, timestamp, and result metadata. This creates a replayable trail for forensic analysis.
- Inline data masking: columns that contain sensitive information (PII, PHI, financial data) are redacted in the response before they reach the agent, ensuring that the AI model never sees raw values.
- Command blocking and guardrails: risky statements such as DROP DATABASE or DELETE FROM users where … can be blocked automatically, preventing accidental or malicious data loss.
- Just‑in‑time approval workflows: for operations that exceed a predefined risk threshold, hoop.dev can pause the request and route it to a human approver, then resume the session once approved.
- Session recording and replay: the entire interaction is captured, allowing teams to replay the exact sequence of commands that the AI agent performed.
All of these capabilities are enforced because hoop.dev is the only component that sees the traffic between the agent and PostgreSQL. Without the gateway, the static credential would remain the sole enforcement mechanism, and none of the above outcomes would be possible.