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

Many assume that an on‑prem AI coding agent can be trusted to log its own activity without any external oversight. In reality, without a dedicated gateway, those logs can be incomplete, tampered with, or simply never generated.

Devin, a code‑generation assistant that runs inside a corporate network, receives prompts from developers and issues commands to databases, shells, or container runtimes. Each interaction may read or write sensitive source files, expose credentials, or modify production data. When something goes wrong, the only evidence often lives inside Devin’s process memory, which is difficult to retrieve after the fact, making reliable session recording impossible without an external gateway.

Regulators and internal audit teams expect a reliable, immutable record of who asked the agent to perform a particular action and what the system returned. Security engineers need the ability to replay a session to verify that no unexpected command slipped through. Developers benefit from a clear trail that proves the agent behaved as intended, reducing blame‑shifting.

Why session recording matters for AI coding agents

Session recording provides a single source of truth for every request and response that passes through the agent. It captures the exact prompt, the generated code, the downstream command, and the response from the target system. This level of detail enables forensic analysis, supports compliance reporting, and gives teams confidence that the AI assistant cannot act silently.

Without a recording layer, organizations resort to ad‑hoc log aggregation or rely on the agent’s internal debug output. Those approaches are optional, can be disabled by a malicious insider, and rarely include the full payload returned by the backend service. The gap leaves a blind spot that attackers can exploit to exfiltrate data or to hide destructive actions.

The missing piece in typical deployments

In most on‑prem setups, Devin is launched as a container that authenticates directly to the target using a static service account. Identity providers such as Okta or Azure AD issue a token that the agent presents, and the connection is established end‑to‑end. The gateway that could enforce policies does not exist, so there is no place to intercept commands, no just‑in‑time approval workflow, and no enforced masking of sensitive fields.

The result is broad standing access, no centralized audit, and no way to block dangerous operations before they reach the database or the shell. Engineers may grant Devin a privileged role once and never revisit it, assuming the agent will behave. In practice, that assumption breaks when the model generates an unexpected destructive command or when a compromised developer account issues a malicious prompt.

How hoop.dev captures every Devin interaction

hoop.dev inserts a Layer 7 gateway between the identity layer and the target resource. The gateway receives the OIDC token, validates the user’s group membership, and then proxies the request to the on‑prem agent. Because all traffic flows through the gateway, hoop.dev can inspect the protocol, apply inline masking, require just‑in‑time approvals, and record the full session before the command reaches the backend.

hoop.dev records each session in an audit log that includes the original developer prompt, the generated code, the exact command sent to the database or shell, and the response. The recording is performed by the gateway itself, so the agent never sees the credential or the log data. Teams can replay the session in a sandbox, verify that no unauthorized query was executed, and satisfy audit requirements.

Setup – identity and provisioning

The first step is to configure an OIDC or SAML identity provider that issues short‑lived tokens for developers. hoop.dev acts as the relying party, mapping token claims to access policies. When a developer initiates a Devin request, the gateway checks the token, determines the allowed scope, and creates a temporary session that expires when the interaction ends.

Data path – the enforced boundary

The gateway is the only point where enforcement can occur. It sits in the network close to the target, intercepts every request, and can block commands that match a deny list, route them for manual approval, or redact fields such as passwords in the response. Because the enforcement lives outside the agent process, a compromised agent cannot bypass the controls.

Enforcement outcomes – session recording and replay

hoop.dev guarantees that every Devin interaction is captured, stored, and searchable. The recorded session can be replayed verbatim, allowing investigators to see the exact state of the system at each step. The audit log also supports alerting on suspicious patterns, such as repeated attempts to drop tables or extract large data sets, giving security teams early warning.

Because hoop.dev generates a complete log of every Devin request, organizations can produce the evidence required for standards such as SOC 2. The audit records show who initiated a request, the exact data accessed, and any masking that was applied, simplifying the path to compliance without building a separate logging pipeline.

Deploying hoop.dev on‑prem keeps all data within the corporate firewall, satisfying data‑residency requirements. The gateway runs as a Docker container or a Kubernetes pod, and the nearby agent uses the gateway’s credential store, so no secret ever leaves the protected network. This model scales to dozens of AI assistants and hundreds of backend services without sacrificing control.

To get started, follow the Getting started guide. The guide walks you through deploying the gateway, registering Devin as a connection, and configuring the required OIDC provider. Detailed information about masking policies, approval workflows, and replay tools is available in the learn section.

Explore the open‑source code on GitHub.

FAQ

Can I use hoop.dev with other AI agents besides Devin?

Yes, the gateway is protocol‑agnostic and can proxy any LLM‑driven tool that communicates over supported connectors such as SSH, HTTP, or database protocols.

Does session recording add noticeable latency?

The gateway processes traffic at the wire‑protocol level, adding only minimal overhead compared with a direct connection, and the trade‑off is justified by the audit and security guarantees.