Devin, the AI‑powered coding assistant, has been granted a service‑account token that lets it run kubectl commands directly against a production cluster. The token was created once, never rotated, and carries broad permissions across namespaces. When Devin applies a manifest that deletes a critical Deployment, there is no record of who triggered the change or what exact resources were altered.
This lack of visibility is the core of the audit trails problem for AI agents. Without a reliable, immutable log of every request, teams cannot answer questions like “Did Devin delete this Service?” or “Which version of a ConfigMap was applied during a rollout?” The answer is critical for post‑mortem analysis, compliance reporting, and limiting the blast radius of accidental or malicious actions.
Why audit trails matter for AI‑driven Kubernetes access
Audit trails are more than a simple list of API calls. They must capture the identity that initiated the request, the exact payload sent to the Kubernetes API server, timestamps, and the outcome of each operation. For a human operator, these details are often recorded by the API server’s built‑in audit log. An AI coding agent, however, typically runs as a background process with a static credential, bypassing the normal human‑in‑the‑loop checks that generate rich context. The result is a blind spot where destructive changes can happen unnoticed.
Even if you tighten the setup, by issuing short‑lived OIDC tokens or assigning the agent to a narrowly scoped role, those measures only answer the question “who may act?” They do not provide a place to observe “what actually happened.” The request still travels straight from Devin to the Kubernetes API server, and no central component can reliably capture the full transaction.
Introducing hoop.dev as the data‑path gateway
This is where hoop.dev enters the architecture. hoop.dev is a Layer 7 gateway that sits between any identity (including AI agents like Devin) and the target infrastructure. By proxying the connection, hoop.dev becomes the sole point where enforcement can occur. It records every Kubernetes request, stores the full request and response payload, and makes the session replayable for later analysis. In other words, hoop.dev generates audit trails for every operation that passes through it.
Because hoop.dev holds the credential used to talk to the cluster, the AI agent never sees the secret. The agent authenticates to hoop.dev with an OIDC token, hoop.dev validates the token, extracts group membership, and then forwards the request to the Kubernetes API server. While forwarding, hoop.dev logs the request, applies any configured masking or command‑blocking policies, and writes the audit record to its backend store.
How the architecture works at a high level
- Deploy the gateway: Run hoop.dev as a container or Kubernetes pod in the same network as the target cluster. The gateway runs an agent that can reach the Kubernetes API server directly.
- Register the Kubernetes connection: Provide the cluster endpoint and the service account that hoop.dev will use. The credential is stored inside hoop.dev; the AI agent never accesses it.
- Identity handling: Configure OIDC (Okta, Azure AD, Google Workspace, etc.) so that Devin can obtain a short‑lived token. hoop.dev validates the token on each request.
- Proxy the traffic: When Devin issues a kubectl command, it connects to hoop.dev instead of the API server. hoop.dev forwards the request, logs the full payload, and returns the response.
- Audit trail storage: Each session is persisted in a secure store that can be queried for compliance reports or incident investigations.
With this design, the only place that can enforce policies, such as denying a delete on a protected namespace or requiring a human approval for a Helm upgrade, is the hoop.dev gateway. The enforcement outcomes (audit trails, command blocking, just‑in‑time approvals) exist because hoop.dev sits in the data path.
Benefits of using hoop.dev for AI‑driven Kubernetes access
- Full audit visibility: Every API call made by Devin is recorded with identity, payload, and result.
- Just‑in‑time access: Tokens are short‑lived, and hoop.dev can require an approval workflow before high‑risk actions are allowed.
- Command‑level blocking: Dangerous commands, such as delete namespace, can be automatically rejected.
- Replay capability: Sessions can be replayed in a sandbox for forensic analysis.
- Zero credential exposure: The AI agent never sees the Kubernetes service‑account secret.
Getting started
To add audit trails for Devin, start by following the getting‑started guide. The documentation walks you through deploying the gateway, registering a Kubernetes connection, and configuring OIDC authentication. All of the detailed steps are available in the open‑source repository on GitHub. For deeper insight into masking, approvals, and session replay, explore the learn section of the site.
FAQ
- Do I need to modify Devin’s code? No. Devin continues to use its standard kubectl client; the only change is the endpoint it connects to (the hoop.dev gateway).
- Where are the audit logs stored? hoop.dev writes logs to a configurable backend store that can be integrated with existing SIEM or log‑analysis pipelines. The store is managed by hoop.dev, not by the AI agent.
- Can I retroactively view a session? Yes. All recorded sessions are searchable and replayable, allowing you to reconstruct exactly what Devin did during any time window.
