Audit logging for AI coding agents on Kubernetes

When a newly onboarded AI coding assistant is granted a service account token that can list pods, create deployments, and modify secrets, the team gains speed but loses visibility. The bot can spin up workloads, patch configurations, or leak credentials without anyone seeing who issued the request or what the response contained. Because the connection goes straight from the agent to the Kubernetes API server, there is no central point to observe the command stream, no replay capability, and no immutable record for later review.

Why audit logging matters for AI agents on Kubernetes

AI‑driven code generators are increasingly used in CI pipelines and developer workstations to scaffold services, apply manifests, or remediate drift. Each of those actions translates into API calls that change the cluster state. Without a reliable audit trail, security teams cannot answer critical questions: Which AI run created the privileged service? Which manifest update introduced a vulnerable image? Did an automated fix expose a secret?

The gap in current practice

Most organizations provision a static service account for the bot, assign it a broad RBAC role, and store the token in a secret store. The bot authenticates directly with the Kubernetes API, and the API server logs only the service account name. Those logs lack context about the originating process, cannot be correlated with the AI model that generated the request, and are often rotated or overwritten, making forensic analysis difficult.

What a proper control model looks like

Introducing non‑human identities and least‑privilege RBAC is a necessary first step. The AI agent now authenticates with a token that only permits the actions it truly needs, and the token is short‑lived. However, the request still travels straight to the API server. At that point the system still lacks a gate where policy can be enforced, where commands can be approved, and where a complete record of every interaction can be stored. The missing piece is a data‑path gateway that can observe and act on the traffic before it reaches the cluster.

hoop.dev as the data‑path gateway

hoop.dev provides a Layer 7 gateway that sits between the AI coding agent and the Kubernetes control plane. The agent connects to the gateway using its standard kubectl client or any compatible library; the gateway then forwards the request to the cluster after applying its policies. Because hoop.dev is the only component that sees the full request and response, it can record each session, generate detailed audit logs, and enforce additional safeguards.

How audit logging works through the gateway

When the AI agent issues a kubectl apply or a direct API call, hoop.dev captures the raw request payload, the authenticated identity, and the exact timestamp. It also records the response from the Kubernetes API, including any returned objects or error messages. All of this information is stored in an audit store that can be queried later for compliance reports or incident investigations. The logs are tied to the AI model version and the originating CI job, giving teams a full picture of why a change was made.

Benefits beyond raw logs

• Session replay lets operators watch a step‑by‑step reconstruction of the AI‑driven interaction, useful for debugging and training.
• Inline masking can redact sensitive fields such as secret data from the recorded response, ensuring that logs do not become a new source of leakage.
• Just‑in‑time approval workflows allow a human reviewer to pause a risky operation, like creating a ClusterRole with cluster‑wide permissions, until the request is explicitly approved.
• Because the gateway runs as a separate process from the Kubernetes agents, the AI code never sees the underlying service account token, reducing the blast radius if the AI model is compromised.

Getting started with audit logging for AI agents

Deploy the hoop.dev gateway in your environment using the quick‑start Docker Compose file, then register your Kubernetes cluster as a connection. The gateway will hold the cluster credentials, while the AI agent authenticates via OIDC tokens that you configure in your identity provider. Detailed steps are available in the getting‑started guide, and the full feature set is described in the learn section. For the source code, configuration options, and contribution guidelines, visit the GitHub repository.

FAQ

Does hoop.dev store the AI agent’s credentials?

No. The gateway only stores the Kubernetes cluster credentials. The AI agent authenticates with its own OIDC token, which the gateway validates but never persists.

Can I filter which API calls are logged?

Yes. hoop.dev lets you define policies that target specific verbs or resources. You can choose to log only privileged operations while allowing routine reads to pass without full recording.

How long are audit logs retained?

Retention is configurable in the deployment. The platform stores logs in an audit store that can be integrated with your existing log‑aggregation pipeline for long‑term archival.