Putting access controls around Devin: data masking for AI coding agents (on Postgres)

Why data masking matters for AI coding agents

A common misconception is that an AI coding assistant like Devin can safely read any column it queries without any data masking needed. In reality, Devin operates with the same privileges as a human engineer, which means it can pull credit‑card numbers, personal identifiers, or proprietary algorithms straight from a PostgreSQL instance. When the model receives those results, the sensitive payload may be cached, logged, or even exposed in downstream prompts, creating a compliance and privacy nightmare.

Most teams today grant Devin a static service account that mirrors a developer’s role. The team creates the account once, stores it in a secret manager, and hands it to the agent at launch. This approach satisfies the need for quick, programmatic access, but it leaves two critical gaps: the agent can see every column it asks for, and there is no record of what data was returned.

The missing guardrail: direct DB access

Even if you tighten the identity side, by issuing a short‑lived OIDC token for Devin and configuring a just‑in‑time (JIT) approval workflow, the request still travels straight to PostgreSQL. The database sees a perfectly valid connection, executes the query, and streams raw rows back to the agent. Because the gateway sits outside the database, you cannot inspect the result set and redact fields that match a sensitivity policy. Consequently, you cannot realize the enforcement outcomes you expect, such as data masking.

In this state, the setup provides authentication and authorization, but it fails to enforce any runtime policy on the data path. The request reaches the target unfiltered, and the audit trail records only that a connection occurred, not what data was exposed.

Introducing hoop.dev as the data‑path gateway

To close the gap, you need a layer that sits between Devin’s identity token and the PostgreSQL server. hoop.dev acts as a Layer 7 gateway that proxies the connection, inspects the protocol, and applies policies before the database sees the request. Because hoop.dev is positioned on the data path, it can enforce data masking, block disallowed commands, and record every session for replay.

The architecture looks like this: Devin authenticates to an OIDC provider (Okta, Azure AD, etc.). hoop.dev validates the token, extracts group membership, and decides whether the request is allowed. An agent running inside the same network as the database forwards the connection to PostgreSQL. While the query travels, hoop.dev examines the response payload, applies masking rules, and writes a complete audit record.

How hoop.dev enforces data masking for Devin

Once the gateway is in place, you define masking policies that target specific columns or patterns, such as ssn, credit_card_number, or any column marked as sensitive in the schema. When Devin issues a SELECT, hoop.dev intercepts the result set, replaces the matched values with a placeholder like ****, and forwards the sanitized rows back to the agent.

Because the gateway holds the database credentials, the agent never sees the raw secret, and the masking happens in real time, before any data can be cached by the AI model. hoop.dev records each session, giving you a complete forensic trail: who (Devin’s service account), when, which query, and what was masked. This evidence satisfies audit requirements and lets you replay the exact interaction if a data‑leak investigation is needed.

hoop.dev makes inline masking, session recording, and replay possible only because it sits in the data path.

Benefits of using hoop.dev for data masking

By placing enforcement at the gateway, you gain three concrete advantages. First, you eliminate the need to embed masking logic in application code, reducing the risk of bugs and version drift. Second, you create a single source of truth for masking rules that applies to every client, whether human or AI, ensuring consistent protection across the organization. Third, you obtain audit records that can be queried by compliance teams without granting them direct database access.

Next steps

• Review the getting started guide to deploy the gateway and the network‑resident agent.
• Define your masking policies in the feature documentation, targeting the columns that contain PII or proprietary code.
• Configure Devin to use an OIDC token for authentication, ensuring the token is short‑lived and scoped only to the required database.
• Test the end‑to‑end flow with a sample query and verify that sensitive fields are redacted before they reach the model.

FAQ

What happens if Devin queries a column that has no masking rule?

hoop.dev forwards the value unchanged because no policy matches. You can add a default rule that masks any column not explicitly whitelisted, ensuring that unknown sensitive data never leaks.

Can I audit masked queries after the fact?

Yes. hoop.dev stores a session log that records the original query, the applied masking policy, and the redacted result. Auditors can review these logs to confirm that the correct fields were protected without exposing the raw data.

When you’re ready to explore the source code, contribute, or file an issue, explore the open‑source repository on GitHub.