Putting access controls around Devin: audit trails for AI coding agents (on Azure)

When an AI coding agent such as Devin runs unattended jobs on Azure, the lack of audit trails means a single stray query can expose credentials, write malformed data, or trigger costly cloud spend. The financial impact of an accidental secret leak or a runaway compute bill can quickly dwarf the value the agent provides. Yet many teams hand the same static token to the agent that engineers use, trusting that the code it writes will stay within bounds.

In practice, the token is scoped to a broad set of resources, the agent connects directly to databases, Kubernetes clusters, or storage, and no one sees what commands were issued or what data was returned. The lack of visibility makes post‑mortem analysis a guessing game, and compliance programs struggle to prove who, or what, touched sensitive data.

What is needed is a non‑human identity that can be granted just‑in‑time privileges, but the request still travels straight to the target without any checkpoint, audit, or inline protection. The identity layer alone cannot stop the agent from executing a destructive command, nor can it capture a replayable record of the session.

Audit trails for AI coding agents

Audit trails give teams a reliable, immutable view of every interaction an agent has with critical infrastructure. They enable forensic analysis, support regulatory evidence, and provide early warning when an agent deviates from its intended behavior. For Devin, an audit trail must capture:

• Who (or what) initiated the connection.
• When the session started and ended.
• Each command or query sent to the backend.
• The response payload, with sensitive fields redacted.

Only a gateway that sits on the data path can guarantee that every packet is inspected, logged, and, when required, altered before it reaches the target.

Architectural approach

The solution is built around three pillars: setup, data path, and enforcement outcomes. Each pillar addresses a distinct responsibility and together they create a complete control plane for AI agents.

Setup – defining Devin as a non‑human identity

Devin authenticates via OIDC or SAML, just like a human engineer. The identity provider (Azure AD, Okta, etc.) issues a short‑lived token that encodes the agent’s group membership. This token is the only credential Devin ever presents. The token itself does not grant any access; it merely proves who Devin is to the gateway.

Provisioning the token is performed once, and the token is never stored on the agent’s filesystem. Because the token is short‑lived, any compromise expires quickly, satisfying the principle of least privilege.

The data path – placing hoop.dev as the gateway

hoop.dev is deployed as a Layer 7 gateway inside the Azure virtual network, next to the resources Devin needs to reach. All traffic from Devin to databases, Kubernetes clusters, or other services is forced through this gateway. Because hoop.dev terminates the protocol, it becomes the only place where policy can be enforced.

When Devin initiates a connection, hoop.dev validates the OIDC token, checks the requested operation against the policy, and then proxies the request to the target. The target never sees the original token; it only sees the service‑level credential that hoop.dev holds securely.

Enforcement outcomes – audit trails, masking, and just‑in‑time approval

hoop.dev records each session in a durable log, capturing every command and response. The log is stored outside the agent’s process, ensuring that the evidence remains intact even if Devin is compromised.

For responses that contain secrets, API keys, connection strings, or personal data, hoop.dev applies inline masking so that the agent never receives raw values. This prevents accidental leakage while still allowing the agent to continue its workflow.

When a command matches a high‑risk pattern (for example, a DROP DATABASE or a privileged kubectl exec), hoop.dev can pause the request and route it to a human approver. The approval workflow is just‑in‑time, meaning the request is blocked until an authorized person explicitly allows it.

All of these outcomes, session recording, data masking, and conditional approval, are possible only because hoop.dev sits in the data path. Remove hoop.dev and the same token would flow directly to the backend with no audit or protection.

Getting started with hoop.dev for Devin

To put the architecture into practice, follow the high‑level steps outlined in the official documentation. Deploy the gateway using the Docker Compose quick‑start, configure an Azure‑native OIDC provider, and register the target resources (PostgreSQL, AKS, etc.) in the hoop.dev catalog. The gateway will then handle all of Devin’s traffic, applying the policies described above.

Detailed guidance on deployment, identity integration, and policy authoring is available in the getting‑started guide and the broader learn section. Those pages walk you through the required YAML snippets, the agent installation, and the UI for defining audit‑trail policies.

FAQ

Does hoop.dev store my Azure credentials?

No. hoop.dev holds only the service‑level credential needed to reach the backend. Devin never sees those credentials, and they are never written to disk on the agent.

Can I retroactively view a session that happened yesterday?

Yes. Because hoop.dev records every session centrally, you can query the audit log at any time to retrieve a replay of the commands and masked responses.

What happens if an approval request is not answered?

The request remains pending and is not forwarded to the target. This default‑deny posture ensures that high‑risk actions cannot proceed without explicit human consent.

Take the next step

Explore the open‑source repository, review the code, and contribute improvements: https://github.com/hoophq/hoop.