Giving an AI coding assistant unrestricted access to a production database is a recipe for data leaks and compliance failures. Without guardrails, a single errant query can expose sensitive records or corrupt critical tables.
In many early deployments, agents like Devin are granted a static PostgreSQL credential that lives in the CI/CD pipeline or in a long-lived secret store. The agent can issue any SELECT, INSERT, UPDATE, or DELETE without any visibility into who invoked the request, what data was returned, or whether the operation complied with privacy policies. Because the traffic flows directly from the agent to the database, there is no record of the exact query, no way to block destructive commands, and no protection against accidental exposure of personally identifiable information.
Organizations that rely on AI‑generated code soon discover that they need more than just a credential. Guardrails such as real‑time data masking, just‑in‑time approval for risky statements, and session logs become essential to keep the blast radius small and to satisfy auditors. Those controls must be applied at the point where the request traverses the network, not inside the agent’s runtime, otherwise the agent can simply bypass or tamper with them.
The logical place to enforce guardrails is the data path itself – the layer that sits between the identity that initiates the request and the PostgreSQL server that executes it. By interposing a transparent gateway, every query can be inspected, transformed, or halted before it reaches the database, while the original client remains unaware of the extra security layer.
hoop.dev sits in that data path. It acts as a Layer 7 gateway that proxies PostgreSQL connections, inspects the wire‑protocol, and applies policy decisions in real time. The gateway authenticates the caller via OIDC or SAML, reads group membership, and then enforces guardrails based on the identity and the requested operation.
When Devin initiates a connection, the request first reaches hoop.dev. The gateway holds the database credential, keeping the password and IAM key hidden from the AI agent. hoop.dev then evaluates the incoming SQL statement against a set of rules. If the query attempts to read a column marked as sensitive, hoop.dev masks the value in the response before it is returned to Devin. If the statement is a DDL change or a bulk delete, hoop.dev can pause execution and route the request to a human approver, enforcing just‑in‑time approval. Regardless of the outcome, hoop.dev records the full session – the authenticated user, the exact query, the masked result, and the approval decision – and stores it for replay and audit.
This architecture respects the three attribution categories. The OIDC setup decides who Devin is and whether the request is allowed to start; that is the **Setup** layer. The gateway itself is the **Data Path** where enforcement occurs. Finally, the masking, approval routing, and session recording are **Enforcement Outcomes**, and each of those outcomes is produced by hoop.dev because it sits in the data path.
Because hoop.dev operates at the protocol level, it works with any PostgreSQL client – psql, an ORM, or a custom script used by the AI agent – without requiring code changes. The agent continues to think it is talking directly to the database, while hoop.dev silently provides the guardrails that keep data safe.
Deploying the solution starts with the standard quick‑start: run the Docker Compose file that launches the gateway and its network‑resident agent. Register the PostgreSQL target in the hoop.dev UI, attach the service credential, and configure the masking and approval policies. The identity provider configuration is handled through the OIDC relying‑party settings, which are documented in the getting‑started guide. Detailed policy examples and best‑practice recommendations are available in the learn section.
Why guardrails matter for AI coding agents
AI agents generate code on the fly, often based on ambiguous prompts. Without guardrails, a single mis‑interpreted request can cause the agent to dump an entire customer table, alter schema, or delete logs that are required for forensic analysis. Guardrails provide three critical safety nets:
- Inline masking ensures that any sensitive column – such as SSN, credit‑card number, or health record – is redacted before the agent can see it, preventing accidental learning or exfiltration.
- Just‑in‑time approval forces a human to review high‑impact statements, turning a potentially destructive automated action into a controlled workflow.
- Session recording creates an audit trail that can be replayed during incident response or compliance reviews.
All three outcomes are only possible because hoop.dev sits in the data path and actively mediates each request.
Implementing guardrails without code changes
The deployment model is intentionally simple. After the gateway is running, an administrator adds a new connection for the PostgreSQL instance, selects the credential type (static secret or IAM role), and defines the masking rules for columns that contain regulated data. Approval policies can be scoped to specific roles or groups, so only privileged engineers can bypass them, while all other requests are automatically held for review.
Because hoop.dev records every session, auditors can later query the logs to verify that no unmasked sensitive data left the database and that every destructive command was either approved or blocked. The logs are stored outside the agent’s environment, satisfying the requirement that evidence be independent of the process that performed the operation.
FAQ
Can I use hoop.dev with an existing PostgreSQL deployment?
Yes. hoop.dev acts as a transparent proxy, so you keep your existing database unchanged. You only need to point your client – including the AI agent – at the hoop.dev endpoint.
What happens if the AI agent tries to bypass hoop.dev?
Since hoop.dev holds the credential and terminates the TLS session, the agent cannot connect directly to the database without the correct secret, which it never receives. Any attempt to connect elsewhere will fail authentication.
Do I need to modify my application code to get session recordings?
No. The recordings are captured by hoop.dev at the protocol level, so the application or AI agent continues to operate as usual while the gateway logs the full interaction.
Next steps
Start by cloning the repository and following the quick‑start instructions. The open‑source project lives at github.com/hoophq/hoop. From there you can explore the configuration options for masking, approval workflows, and session storage, and begin protecting your AI‑driven PostgreSQL workloads with effective guardrails.
