Devin, an AI coding assistant deployed inside the corporate network, needs to run queries against the on‑premises customer database in order to generate code snippets. Without proper database access controls, Devin can issue any query unchecked. The engineering team grants Devin a static database user name and password, stores the secret in a shared vault, and lets the agent connect directly with any client that can speak the database protocol. There is no per‑request audit, no way to see which query was issued, and the secret can be reused by any process that discovers it. In practice, the AI agent can read or write any row it wants, and a compromised container could exfiltrate the entire data set without anyone noticing.
Recognizing the risk, the organization adopts a non‑human identity for Devin and creates a least‑privilege role that only allows read‑only access to the tables required for code generation. The role is attached to a short‑lived token that the AI runtime fetches at start‑up. This step eliminates the permanent secret, but the request still travels straight to the database server. The gateway that could enforce policy, record the session, or mask sensitive columns is missing, so the organization still lacks visibility, approval workflow, or real‑time data protection.
Why database access needs a dedicated enforcement point
When an automated agent talks directly to a database, the only place to inspect traffic is the client itself. That model makes it impossible to enforce fine‑grained rules such as:
- Require a human approver before a DELETE or UPDATE runs.
- Mask credit‑card numbers or personal identifiers in query results.
- Record every statement for replay during an investigation.
- Terminate a session that attempts to run a disallowed command.
All of those controls must sit on the data path, between the identity that initiated the request and the database that fulfills it. Without a gateway, the organization can only rely on static permissions, which do not provide the dynamic guardrails needed for AI‑driven workloads.
hoop.dev as the identity‑aware database gateway
hoop.dev provides the missing layer. It runs a network‑resident agent inside the same segment as the database and proxies every connection that originates from Devin. Because hoop.dev is the only component that sees the raw wire protocol, it can enforce policies in real time.
When Devin initiates a session, hoop.dev authenticates the short‑lived token, verifies the associated group membership, and then routes the request to the target database. At that point, hoop.dev applies the following enforcement outcomes:
- Session recording: hoop.dev records each statement and its result, storing a replayable audit trail that can be examined later.
- Inline masking: hoop.dev inspects result sets and redacts columns that contain sensitive data, ensuring that the AI agent never sees raw PII.
- Just‑in‑time approval: for write‑heavy commands such as UPDATE or DELETE, hoop.dev pauses the request and forwards it to an approver. Only after explicit consent does the statement reach the database.
- Command blocking: dangerous commands like DROP DATABASE are intercepted and rejected before they can affect the system.
All of these actions happen without Devin ever handling the underlying database credentials. The gateway holds the credential, presents a short‑lived service identity to the database, and revokes it when the session ends.
Architectural steps to protect AI‑driven database access
Implementing a secure model for Devin involves three layers:
- Setup identity and least‑privilege role: define a non‑human OIDC client for Devin, bind it to a read‑only role that limits table access, and configure token expiration to a few minutes.
- Insert hoop.dev on the data path: deploy the gateway in the same network segment as the database, register the target connection in hoop.dev, and point Devin’s client to the proxy address instead of the database host.
- Define enforcement policies: use hoop.dev’s policy engine to require approvals for write operations, specify which columns to mask, and enable session recording for every request.
Once these layers are in place, the organization gains continuous visibility into every query that Devin issues, can stop accidental data loss before it happens, and can demonstrate compliance with internal audit requirements.
Getting started
For a step‑by‑step walkthrough, follow the getting started guide. The documentation explains how to provision the gateway, register a PostgreSQL connection, and configure a non‑human OIDC client for an AI agent. All configuration details are available in the public repository, which you can clone from GitHub.
Additional feature details, such as how to write masking rules or set up approval workflows, are covered in the learn section of the site.
FAQ
Can hoop.dev protect other database engines besides PostgreSQL?
Yes. hoop.dev supports MySQL, MSSQL, MongoDB, Oracle, and several other engines. The same gateway pattern applies: the agent proxies the wire protocol, and hoop.dev enforces policies on that traffic.
Does hoop.dev store the database credentials?
hoop.dev holds the credential only for the duration of the proxied session. The AI agent never receives the secret, and the credential is never written to disk by the agent.
How does session replay work for an AI‑driven workload?
Every statement and its response are captured by hoop.dev. The recorded data can be replayed in a sandboxed environment, allowing investigators to see exactly what the AI agent queried and what data it received.
