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

Imagine a development pipeline where every AI‑driven coding assistant can touch live services, yet each request is logged, approved, and scrubbed of secrets before it ever reaches the database, achieving production access without exposing credentials. In that world, a mis‑generated query is caught before it runs, a credential leak is impossible, and auditors can replay any session to prove compliance.

In many organizations today, AI agents like Devin are given the same static API keys or database passwords that engineers use. Those secrets are stored in configuration files, checked into version control, or handed out to the agent at launch. The agent then connects directly to the target service, enjoying the same unrestricted, standing access that a human would have. There is no visibility into which commands the agent issued, no way to block a dangerous operation, and no mechanism to hide sensitive columns in query results.

Why production access matters for AI coding agents

Devin needs to read schemas, suggest migrations, and even apply patches in a production environment. That capability is powerful, but it also expands the blast radius of a bug in the model or a prompt injection attack. The core security requirement is production access: the ability to let the agent act on live resources only when a legitimate request is made, and only for the exact operation needed.

Enforcing production access starts with identity. By issuing a non‑human OIDC token for Devin, you can verify that the request originates from the expected AI service. You can also attach group membership that limits Devin to a specific set of resources. However, identity alone does not stop the agent from sending a destructive command once the connection is open. Without a gateway in the data path, the request still travels straight to the database, bypassing any real‑time guardrails, audit logging, or data masking.

Common mistakes to avoid

• Giving Devin a long‑lived static credential that never rotates. Static secrets are a single point of failure and cannot be revoked without disrupting the agent.
• Relying on the agent’s own logging. The agent can be compromised, and its logs are not immutable.
• Skipping approval workflows. An AI model can hallucinate a command that deletes a table; without a human checkpoint the damage is immediate.
• Forgetting to mask sensitive fields. Query results that contain PII or API keys can be streamed back to the model and inadvertently stored in training data.
• Deploying the gateway but still letting the agent connect directly to the target. If the gateway is not in the data path, none of the enforcement features are exercised.

How hoop.dev enforces production access

hoop.dev is a Layer 7 gateway that sits between Devin’s identity token and the downstream SaaS service. By placing the gateway in the data path, hoop.dev becomes the sole point where traffic can be inspected and controlled.

When a request arrives, hoop.dev validates the OIDC token, checks Devin’s group membership, and then applies a policy that may require a just‑in‑time approval before the command is forwarded. If the command matches a blocklist, such as a DROP or DELETE that targets a critical table, hoop.dev stops it outright. For queries that return rows containing sensitive columns, hoop.dev masks those fields in real time, ensuring the model never sees raw secrets.

Every interaction is recorded. hoop.dev stores a replay‑able session log that captures the exact request, the policy decision, and the response after masking. Those logs provide evidence for auditors and enable post‑mortem analysis of any unexpected behavior.

Getting started with hoop.dev

Deploy the gateway using the provided Docker Compose quick‑start or a Kubernetes manifest, depending on your environment. Register the target SaaS endpoint in hoop.dev’s configuration and associate it with a credential that the gateway alone knows. Create an OIDC client for Devin, assign it to a group that maps to the specific resources it may access, and define policies that require approval for any write‑heavy operation.

For detailed steps, follow the getting‑started guide and explore the policy examples on the learn page. The documentation walks you through setting up the gateway, configuring non‑human identities, and tailoring guardrails to your risk tolerance.

FAQ

• Can hoop.dev block a command after it has been sent? Yes. Because hoop.dev inspects traffic at the protocol layer, it can reject a command before the downstream service executes it.
• Does hoop.dev store the original data before masking? No. The gateway masks sensitive fields in the response stream, and only the masked version is forwarded to the AI agent.
• How are approvals handled? When a policy requires human sign‑off, hoop.dev routes the request to an approval workflow (e.g., Slack or email). The request proceeds only after an authorized reviewer approves it.

By moving production access control into the data path, hoop.dev gives you the confidence that AI coding agents like Devin can operate in live environments without exposing your organization to uncontrolled risk.

Explore the open‑source repository on GitHub to see the code, contribute, or fork the project for your own deployment.