When an AI coding agent is given a static Kubernetes token, the organization loses visibility into what code the model actually runs, and any compromise of that token instantly grants unrestricted cluster access. The cost is not just a potential breach; it includes wasted debugging time, regulatory exposure, and the erosion of trust in automated development pipelines. The root of the problem is the lack of a non-human identity that can be verified and audited on each request.
Most teams treat AI agents like ordinary users: they create a long‑lived service account, bind it to a cluster‑wide role, and let the model invoke the Kubernetes API directly. The agent can list pods, modify deployments, or even delete namespaces without any human oversight. Because the request travels straight to the Kubernetes API server, there is no audit trail that ties an operation to a specific model run, and no way to mask sensitive configuration values that might be returned in API responses.
The precondition we need to address is the existence of a non‑human identity that the AI model can assume, while still ensuring that every request passes through a control point that can enforce policies. Even with a dedicated service account, the request still reaches the Kubernetes API directly, leaving the cluster without any real‑time audit, inline masking of secret fields, or just‑in‑time approval workflow.
hoop.dev solves this by inserting a Layer 7 gateway between the AI agent and the Kubernetes control plane. The gateway acts as the data path where all enforcement happens. It validates the model’s OIDC token, maps the token to a scoped Kubernetes service account, and then proxies the request to the API server. Because the request is funneled through hoop.dev, the system can record each command, mask sensitive response data, and require human approval for high‑risk operations before they are sent downstream.
When an AI coding agent presents its identity, hoop.dev checks the token against the configured identity provider, extracts group membership, and dynamically assigns the minimal set of RBAC permissions needed for the specific task. The gateway then forwards the request using its own credential, ensuring the agent never sees the underlying cluster secret. This separation of identity verification from policy enforcement guarantees that the enforcement outcomes exist only because hoop.dev sits in the data path.
hoop.dev records every session, creating a replayable audit log that ties each Kubernetes command to the exact model run that issued it. It masks fields such as service‑account tokens, database passwords, or API keys that might appear in API responses, protecting downstream services from accidental exposure. For actions that could disrupt workloads, such as deleting a namespace or scaling a deployment, hoop.dev can pause the request and route it to a human approver, providing just‑in‑time approval before execution. If a command is deemed unsafe, hoop.dev blocks it outright, preventing accidental or malicious changes.