Devin, an internal AI coding assistant, has been granted a service account that talks directly to the production PostgreSQL cluster. The account uses a static password stored in a CI secret store, and any developer can invoke Devin from a notebook or a CI job. Because the connection bypasses any broker, the team has no visibility into which SQL statements Devin actually runs, whether it ever reads or writes sensitive customer data, or if a buggy prompt causes an unintended data dump.
Without session recording, the team cannot see which queries Devin executes, making it impossible to answer whether the agent ever accessed credit‑card numbers or other regulated fields. When a data‑driven model generates code, the resulting queries can be complex, contain joins across regulated tables, and may even exfiltrate personally identifiable information. Without a reliable audit trail, a compliance reviewer cannot answer the question, “Did Devin ever see credit‑card numbers?” The lack of an immutable log also makes forensic analysis after a breach extremely difficult. This is why session recording is a non‑negotiable control for any AI‑assisted data access.
Why session recording matters for AI coding agents on PostgreSQL
AI agents like Devin are non‑human identities that execute code on behalf of users. Their behavior is driven by prompts, which can be ambiguous or maliciously crafted. A single unexpected SELECT or COPY TO can expose large data sets. Session recording captures the exact request and response stream, preserving a replayable artifact that shows who invoked the agent, what prompt was supplied, and which rows were returned. This evidence satisfies internal governance, supports external audits, and provides a safety net for incident response.
The missing control in typical pipelines
Most teams rely on three pieces that, taken together, still leave a blind spot. First, they create a service account in the identity provider and grant it read‑write rights on the database. Second, they embed the credential in CI pipelines or notebook environments, trusting that the secret manager is the only gate. Third, they enable logging at the database level, which records statements but not the surrounding context such as the originating AI prompt or the user who triggered the agent. This setup satisfies identity verification (the setup layer), but the actual enforcement – preventing a risky query or capturing the full interaction – never happens in the data path.
Because the request travels straight from the CI runner to PostgreSQL, the architecture lacks a point where approval workflows, inline masking, or session recording can be applied, leaving a gap.
hoop.dev as the data‑path gateway for session recording
hoop.dev solves the gap by inserting a Layer 7 gateway between the AI agent and the PostgreSQL endpoint. The gateway runs a network‑resident agent inside the same VPC as the database and proxies every client connection. Identity is still handled by the existing OIDC or SAML provider, so the setup layer remains unchanged. What changes is where enforcement occurs: all traffic now passes through the gateway, which is the only place where policy can be applied.
When Devin initiates a connection, hoop.dev validates the OIDC token, extracts group membership, and creates a short‑lived session context. From that point forward, hoop.dev records each request and response pair, producing a replayable log that includes the original prompt, the generated SQL, and the result rows. Because hoop.dev is the active component in the data path, it is the entity that records every session, ensuring that the audit trail cannot be bypassed.
In addition to session recording, hoop.dev can mask sensitive columns before they leave the database, block statements that match a deny list, and route high‑risk queries to a human approver. All of these enforcement outcomes exist only because the gateway sits in the data path; the underlying service account credential never sees the database directly.