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

Why data masking matters for AI coding agents

When an internal SaaS like Devin is asked to generate code, it often pulls configuration values, API keys, or database passwords from the same environment that the agent runs in. If the agent’s output is logged, cached, or displayed in a chat window, those secrets can leak to any participant who reads the transcript. The cost is immediate exposure of production credentials, a forced rotation of keys, and a loss of trust in the development pipeline.

The missing control in a direct connection

Most teams give their AI assistants a static service account that has read‑only access to the codebase and write‑back privileges to the deployment environment. The connection goes straight from the agent to Devin’s API over HTTPS. No gate watches the payload, no policy decides which fields are safe to return, and no audit trail captures what the model actually emitted. The result is a blind spot: the organization cannot prove that secrets stayed hidden, nor can it intervene when a response contains a credential.

Introducing a data‑path gateway

To close the gap, the request must pass through a component that can see the traffic, apply rules, and decide whether to allow, mask, or record it. The gateway sits between the AI agent and Devin, acting as an identity‑aware proxy. It validates the caller’s token, consults group membership, and then inspects each response before it reaches the agent. Only the gateway can enforce data masking in real time because it is the sole point where the data flows.

How hoop.dev enforces data masking

hoop.dev is that gateway. It authenticates users and agents via OIDC or SAML, so the Setup layer determines who is making the request. The gateway itself becomes the data path, the only place where enforcement can happen. Once a request reaches hoop.dev, the platform applies masking policies to any field that matches a configured pattern, credit‑card numbers, API tokens, or internal identifiers. hoop.dev replaces those values with placeholder text before the response is handed to the AI agent.

Because hoop.dev sits in the data path, it also records every session. The Enforcement outcomes, masked output, a complete audit log, and optional just‑in‑time approval for risky commands, exist only because hoop.dev intercepts the traffic. If the gateway were removed, the request would travel directly to Devin and none of those safeguards would be present.

Benefits of gateway‑level masking

• Reduces blast radius: a leaked secret never leaves the gateway.
• Provides evidence for compliance audits: logs show who asked for what and what was masked.
• Supports just‑in‑time approvals: high‑risk operations can be routed to a human before execution.
• Keeps the AI agent stateless: the model never sees raw credentials, preventing accidental memorization.

Getting started with hoop.dev

Deploy the gateway using the official getting‑started guide. The quick‑start runs hoop.dev in Docker Compose and wires an OIDC provider for authentication. After the gateway is running, register Devin as a connection in the hoop.dev UI, supplying the endpoint and the service account that the gateway will use. Define a masking policy that targets the fields you consider sensitive, e.g., any JSON key named "api_key" or "password". Enable session recording so every interaction is stored for later review.

When the AI coding agent connects, it authenticates to hoop.dev, which validates the token, applies the masking rules, and streams the sanitized response back. All of this happens without any code changes to the agent or to Devin.

For deeper details on policy syntax, masking configuration, and audit log access, explore the learn section. The repository on GitHub contains the full source and contribution guidelines: Explore hoop.dev on GitHub.

FAQ

Does hoop.dev store the original unmasked data?

No. The gateway only sees the data in transit, applies the mask, and forwards the sanitized version. The original payload is never persisted by hoop.dev, ensuring that secrets are not retained beyond the session.

Can I apply different masking rules per user or team?

Yes. Because authentication is handled in the Setup layer, hoop.dev can evaluate group membership and enforce distinct policies for each identity, allowing fine‑grained control over what each role may see.

What happens if a request is blocked by a policy?

hoop.dev returns a clear denial response to the caller and, if configured, routes the request to an approver. The event is logged, providing a trace of the attempted operation and the reason it was halted.