Putting access controls around Claude: production access for AI coding agents (on Kubernetes)

Giving an AI coding agent unrestricted production access into a live cluster is a recipe for accidental data loss or supply‑chain compromise.

Most teams start by embedding Claude’s API key or a static service‑account token into the CI pipeline. The token is checked into source control, shared across environments, and granted broad permissions on the Kubernetes API. Engineers push a change, the agent runs, and any command it issues is executed with the same level of privilege that a human operator would have. There is no record of which request triggered which mutation, no way to hide secret values that the model might emit, and no gate that forces a human to approve a risky operation.

Why production access needs a dedicated gateway

Production access for AI agents must satisfy three independent requirements:

• Least‑privilege, just‑in‑time credentials. The agent should only receive a token for the exact namespace or resource it needs, and only for the duration of the request.
• Real‑time guardrails. Commands that could delete deployments, modify RBAC rules, or expose secrets must be blocked or sent for manual approval.
• Immutable audit evidence. Every session, every query, and every response that contains sensitive data must be recorded for later replay.

Only a layer that sits between the identity provider and the Kubernetes API can enforce all three at once. Identity providers (Okta, Azure AD, Google Workspace) can tell the system who is calling, but they cannot inspect the actual Kubernetes request payloads. Likewise, a static service‑account can be scoped, but it cannot provide per‑request approval or inline masking.

How hoop.dev provides production access controls for Claude

hoop.dev acts as a Layer 7 gateway that proxies every Kubernetes API call. The flow looks like this:

1. Engineers configure an OIDC identity source. When Claude’s runtime asks for a token, it receives a short‑lived JWT that identifies the agent and its group membership.
2. hoop.dev validates the JWT, extracts the groups, and decides whether the request may proceed. If the request matches a policy that requires human approval, such as a request to delete a deployment, hoop.dev forwards the request to an approval workflow before it reaches the cluster.
3. For read‑only queries that return secret fields, hoop.dev masks those fields in the response so the model never sees raw secret values.
4. Every request and response pair is streamed to a secure audit store. The session can be replayed later, giving auditors a complete picture of what the AI did in production.
5. Because the gateway holds the Kubernetes credentials, the Claude runtime never sees the actual service‑account token. The agent only ever talks to hoop.dev, which then talks to the cluster on its behalf.

In this architecture the enforcement outcomes, just‑in‑time approval, inline masking, and session recording, are all provided by hoop.dev. The identity system merely tells hoop.dev who is calling; it does not block or mask anything on its own.

Common mistakes and how to avoid them

1. Storing the Claude API key in plain text. If the key is checked into a repository, any compromise of the repo gives an attacker full production access. Instead, let the key live in a secret manager and have the CI runner inject it at runtime. hoop.dev will then exchange the injected secret for a short‑lived credential that is never persisted.

2. Granting cluster‑wide admin rights to the service account. Broad admin scopes defeat the purpose of production access controls. Define a role that only allows read operations on the namespaces the agent needs, and let hoop.dev enforce additional checks for write operations.

3. Assuming audit logs from the Kubernetes API are sufficient. Native audit logs do not capture the AI’s decision‑making context, nor do they hide secrets that the model might have echoed. hoop.dev records the full request/response cycle and can redact sensitive fields before they are stored.

4. Bypassing the gateway for speed. Some teams create a back‑door path that talks directly to the cluster to avoid latency. This instantly nullifies all production access guarantees. All traffic, even internal service‑to‑service calls that involve Claude, should be forced through hoop.dev.

Getting started with hoop.dev for Claude on Kubernetes

Begin by deploying the hoop.dev gateway in the same network segment as your Kubernetes control plane. The quick‑start guide walks you through a Docker Compose deployment that includes OIDC verification, default masking rules, and an example approval workflow. Once the gateway is running, register your Kubernetes cluster as a connection and point Claude’s client library at the hoop.dev endpoint instead of the raw API server.

From there you can define policies that require approval for any apply that touches production namespaces, mask fields like data.password in ConfigMaps, and enable session replay for post‑mortem analysis. The documentation also shows how to integrate the built‑in MCP server so that Claude can request production access without any code changes.

FAQ

Q: Does hoop.dev replace my existing RBAC configuration?
A: No. hoop.dev works alongside Kubernetes RBAC. It adds a second enforcement layer that inspects the request payload before the API server evaluates RBAC.

Q: Can I use hoop.dev with multiple AI agents?
A: Yes. Each agent authenticates with its own OIDC identity, and hoop.dev applies the appropriate policy based on group membership.

Q: How long are the temporary credentials that hoop.dev issues?
A: The gateway issues short‑lived tokens that expire after a configurable window, typically a few minutes, ensuring that a compromised token cannot be reused.

For a step‑by‑step walkthrough, see the getting‑started guide. The full feature set is described in the learn section. When you’re ready to explore the code or contribute, visit the repository on GitHub: https://github.com/hoophq/hoop.