Production access control for AI coding agents on Kubernetes

A senior engineer recently granted an AI‑powered coding assistant unrestricted access to the production Kubernetes cluster. The assistant received a static kubeconfig file that granted cluster‑admin privileges, and it began applying changes on live services without any human review. The result was a cascade of unintended deployments that temporarily degraded the user experience, and the team had no reliable way to trace which command triggered the failure. Without production access control, the AI assistant could cause even greater damage.

This scenario illustrates a broader problem: AI agents that interact with production infrastructure often inherit the same over‑privileged credentials that humans use. When those agents operate without a guardrail, they can execute any kubectl command, read secrets, or delete resources, and the organization loses visibility into what the agent actually did.

Why production access control matters for AI agents on Kubernetes

Production access control is the practice of limiting every request to the minimum set of permissions required for the specific task, while ensuring that each action is auditable and reversible. For AI coding agents, this means:

• Granting just‑in‑time permissions that expire after the operation completes.
• Requiring a human approval step for commands that modify critical resources.
• Masking sensitive fields such as secret values in API responses so the agent never sees raw credentials.
• Recording the entire session for replay and forensic analysis.

Without a dedicated enforcement point, the Kubernetes API server receives the request directly from the agent. The API can enforce role‑based access control (RBAC), but it cannot provide JIT approval workflows, inline masking, or session replay out of the box. The missing piece is a gateway that sits in the data path and applies these controls consistently.

Current state: unrestricted agents and missing audit

Most teams provision AI agents by copying an existing kubeconfig file into the container that runs the model. The file often contains a cluster‑admin role or a service‑account token with broad permissions. The setup satisfies the immediate need, getting the model to talk to the cluster, but it leaves three gaps:

1. No real‑time approval. Any kubectl command runs immediately, even if it would delete a namespace.
2. No data masking. Secrets returned by the API are exposed in plain text to the agent.
3. No immutable audit trail. The Kubernetes audit log records who called the API, but it does not capture the full interactive session, making it hard to reconstruct the exact sequence of commands.

These gaps persist even when the organization has strong identity providers and strict RBAC policies, because the enforcement point is still the Kubernetes API server itself.

How hoop.dev provides the missing data‑path control

hoop.dev is an identity‑aware, layer‑7 gateway that sits between the AI coding agent and the Kubernetes API server. It proxies the connection, inspects the wire‑protocol, and enforces production access control policies before the request reaches the target.

Setup: identity and least‑privilege grants

The gateway trusts tokens issued by an OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.). The engineering team creates a service account that represents the AI agent, assigns it only the permissions needed for the specific task, and configures that account in hoop.dev. The gateway validates the token, extracts group membership, and maps it to a policy that determines whether the request can proceed.

The data path: gateway as the only enforcement point

When the agent initiates a kubectl request, it connects to hoop.dev instead of the Kubernetes API server. hoop.dev forwards the traffic to the cluster after applying its guardrails. Because all traffic passes through the gateway, hoop.dev can:

• Block dangerous commands, for example the phrase delete namespace, before they are executed.
• Route high‑risk operations to a human approver, pausing the request until approval is granted.
• Mask fields that contain secrets, ensuring the AI never sees raw credential material.
• Record the entire interactive session, including each command and response, for later replay.

These capabilities exist only because hoop.dev occupies the data path; the Kubernetes API server alone cannot provide them.

Enforcement outcomes delivered by hoop.dev

Once the request reaches the gateway, hoop.dev enforces the following production access control outcomes:

• Just‑in‑time approval. hoop.dev pauses any command that matches a policy rule and notifies the designated approver. The request proceeds only after explicit consent.
• Inline data masking. hoop.dev scans API responses for secret patterns and replaces them with placeholder values before they are handed to the agent.
• Command‑level audit. hoop.dev logs each command, the identity that issued it, and the result, providing a reliable audit trail.
• Session recording and replay. hoop.dev stores a complete session transcript that can be replayed for forensic investigations or compliance reporting.

Because hoop.dev is the only component that can see both the request and the response, it is uniquely positioned to guarantee these outcomes.

Putting it together: a practical workflow

1. Define a policy. The security team creates a policy that says any AI‑generated apply operation must be approved, and that secret‑type fields must be masked.

2. Provision a service account. The account receives the minimal RBAC role needed to read the namespaces the AI will inspect.

3. Register the Kubernetes cluster in hoop.dev. The gateway stores the cluster URL and a bearer token that it uses to talk to the API server.

4. Run the AI agent. The agent authenticates to hoop.dev with its OIDC token, issues kubectl commands, and receives responses that have been filtered, approved, or blocked according to policy.

5. Review audit records. After the job finishes, the team consults the session logs stored by hoop.dev to verify that no unauthorized changes were made.

This flow satisfies the production access control requirement while keeping the AI agent’s privileges tightly scoped and fully observable.

Getting started

To try this approach in your own environment, follow the getting‑started guide for deploying the gateway and configuring a Kubernetes connection. The learn section provides deeper coverage of policy design, JIT approvals, and masking strategies.

Frequently asked questions

Does hoop.dev replace Kubernetes RBAC?

No. hoop.dev works alongside RBAC. It enforces additional controls, approval, masking, and session recording, at the gateway layer, while RBAC continues to limit what actions an identity can perform inside the cluster.

Can I use hoop.dev with existing CI pipelines?

Yes. CI jobs can obtain an OIDC token from the pipeline’s identity provider, then connect through hoop.dev just as a human would. The same policies apply, ensuring that automated deployments also receive JIT approval when needed.

What happens to secrets returned by the API?

hoop.dev scans the response for known secret patterns and replaces them with masked placeholders before the data reaches the AI agent. The original secret never leaves the gateway.

Take the next step

Explore the source code, contribute improvements, or deploy your own instance by visiting the GitHub repository. The community and documentation are ready to help you secure AI‑driven access to production Kubernetes clusters.