Putting access controls around Devin: guardrails for AI coding agents (on on-prem)

Devin, an on‑prem AI coding assistant, has become the go‑to tool for automatically generating snippets, fixing bugs, and even scaffolding entire services. The team granted Devin a service‑account token that can read every production database, push container images, and execute commands inside every Kubernetes pod. Because the token is static and broadly scoped, any stray request, whether a malformed prompt, a malicious prompt injection, or a careless developer, can cause Devin to exfiltrate credentials, overwrite configuration, or run destructive commands. The organization added OIDC‑based identity verification, but without guardrails the request still lands directly on the target systems. No command is inspected, no response is filtered, and no record exists of what Devin actually did.

Because the token is static and broadly scoped, any stray request, whether a malformed prompt, a malicious prompt injection, or a careless developer, can cause Devin to exfiltrate credentials, overwrite configuration, or run destructive commands. The organization added OIDC‑based identity verification, but without guardrails the request still lands directly on the target systems. No command is inspected, no response is filtered, and no record exists of what Devin actually did.

Why guardrails are essential for AI coding agents

Guardrails are the set of runtime controls that turn a powerful, unrestricted AI assistant into a safe, auditable collaborator. They address three core gaps:

• Intent verification: ensuring that a request to modify infrastructure or read sensitive data is explicitly approved.
• Data protection: preventing accidental leakage of secrets, passwords, or personally identifiable information in AI‑generated output.
• Accountability: creating a tamper‑proof trail that shows who asked what, what the agent responded with, and which commands were actually executed.

Without a dedicated enforcement point, these guarantees cannot be reliably delivered. The identity layer can tell you who started Devin, but it cannot block a dangerous command once the request reaches the database or the cluster.

Placing the enforcement point in the data path

The only place to enforce guardrails is on the actual traffic between the AI agent and the infrastructure it talks to. By inserting a Layer 7 gateway that proxies every protocol, PostgreSQL, MySQL, Kubernetes exec, SSH, HTTP APIs, policy can be applied in real time, regardless of the underlying service.

hoop.dev serves exactly this role. It sits between the identity system and the target resource, acting as an identity‑aware proxy that can inspect, transform, and record each request. Because the gateway is the sole conduit, it can:

• Require just‑in‑time approval for any operation that touches privileged objects.
• Mask or redact sensitive fields in query results before they reach Devin.
• Block commands that match a deny list, such as destructive DDL statements or container deletions.
• Record the full session, including the prompt, the AI‑generated response, and the resulting command execution, for replay and audit.

All of these outcomes are enforced by hoop.dev, not by the token, the OIDC provider, or the target system. If hoop.dev were removed, the guardrails would disappear, leaving the original unrestricted access model.

How the guardrail workflow looks for Devin

1. Identity verification. A developer authenticates with the organization’s OIDC provider. hoop.dev validates the token, extracts group membership, and maps the user to a scoped policy.

2. Just‑in‑time request. When Devin generates a request to read a production table, the request is intercepted by hoop.dev. The policy says that any read of production data requires an explicit approval step. hoop.dev routes the request to an approver UI where a senior engineer can grant or deny the operation.

3. Inline masking. If the request is approved, the database response passes back through hoop.dev. The gateway applies field‑level masking rules, redacting passwords, API keys, and credit‑card numbers, before the data is handed to Devin.

4. Command blocking. Should Devin attempt a destructive command, such as dropping a table or restarting a pod, hoop.dev matches the command against a deny list and aborts it, returning an error to the agent.

5. Session recording. Every interaction, from the original prompt to the final response, is logged by hoop.dev. The logs are retained and can be replayed for forensic analysis or compliance reporting.

Benefits of the hoop.dev approach

Because hoop.dev is the sole data‑path component, the organization gains a single source of truth for all AI‑driven actions. The guardrails are consistent across every protocol, eliminating gaps that would otherwise appear when switching from a database to a Kubernetes cluster. The model also scales: new resources are added by registering them with the gateway, and the same policy engine automatically applies to them.

In addition, hoop.dev is open source and MIT‑licensed, so teams can run the gateway on‑premises, keep audit logs within their own environment, and extend the policy engine to meet unique regulatory requirements.

Getting started

To protect Devin with guardrails, start by deploying the hoop.dev gateway in the same network segment as your databases and clusters. Follow the getting started guide to configure OIDC authentication, register your resources, and define masking and approval policies. The learn section provides deeper examples of guardrail rules for databases, Kubernetes, and SSH.

All configuration details, including how to define just‑in‑time approval workflows and field‑level masking, are documented in the repository. Explore the source code and contribute on GitHub: https://github.com/hoophq/hoop.

FAQ

What if an attacker compromises the AI agent?

hoop.dev still controls every request. Even with a compromised agent, the gateway will enforce approval, masking, and command blocking before any operation reaches the target.

Can I use hoop.dev with existing CI pipelines?

Yes. The gateway can be invoked from any standard client, SQL client, kubectl, or curl, so CI jobs simply point to the hoop.dev endpoint instead of the raw service endpoint.

Do the audit logs satisfy compliance requirements?

hoop.dev records each session and retains the audit trail for later review, which can be exported for SOC 2, ISO 27001, or other audit frameworks. The logs include user identity, request details, approvals, and the final outcome.