Many assume that plugging a large language model into a CI pipeline automatically keeps the code safe. In reality the model can emit secrets, run destructive commands, and bypass existing Kubernetes RBAC without anyone noticing.
Without guardrails, the AI agent can unintentionally expose credentials or cause destructive changes, leaving the cluster vulnerable.
Teams often give ChatGPT direct network access from a pod, letting the model call the Kubernetes API, pull images, or write files. The model’s responses are treated as ordinary output, so a stray API key or a command that deletes a namespace can slip through unnoticed. Because the connection is a plain TCP stream, there is no built‑in audit of what the model asked the cluster to do, nor any way to hide sensitive data that the model might return.
That unsanitized state leaves two major gaps. First, the AI agent operates with the same privileges as the service account that launched the pod, which is usually a broad, standing credential. Second, there is no record of the exact commands or API calls the model performed, making post‑mortem analysis or compliance reporting impossible.
The fix starts with a clear precondition: you must require a non‑human identity for the AI agent, enforce least‑privilege scopes, and demand just‑in‑time approval for risky operations. Even with those controls, the request still reaches the Kubernetes API server directly, so the cluster itself sees no guardrails, no masking of returned secrets, and no immutable audit of the session.
hoop.dev provides the missing data‑path layer that turns the precondition into a complete control surface. It sits between the AI coding agent and the Kubernetes control plane, acting as an identity‑aware proxy that inspects every request before it reaches the API server.
When the ChatGPT‑driven agent initiates a connection, it presents an OIDC token that represents a dedicated service account. hoop.dev validates the token, extracts group membership, and then forwards the request through its gateway. Because the gateway is the only point where traffic passes, it can enforce policies that the Kubernetes API itself cannot see.
From that point onward hoop.dev enforces the guardrails you need. It records each session so you have a replayable audit trail. It masks any secret‑like patterns in the model’s responses before they reach the pod, preventing accidental leakage. It blocks commands that match a deny list, such as "kubectl delete namespace" without explicit approval. For operations that cross a risk threshold, hoop.dev triggers a just‑in‑time approval workflow, pausing the request until a human reviewer signs off.
Those enforcement outcomes exist only because hoop.dev occupies the data path. Without it, the Kubernetes API would still execute the request unchecked, and no session data would be captured. By centralising policy enforcement, hoop.dev reduces blast radius, provides evidence for audits, and lets you retain control over AI‑driven automation without sacrificing developer velocity.
Deploying the solution is straightforward. Run the hoop.dev gateway as a deployment in the same cluster where your AI agents execute. An accompanying network‑resident agent runs alongside the Kubernetes API, handling credential storage so the AI never sees the underlying service account keys. Register the Kubernetes connection in the gateway, configure the desired guardrail policies, and point your ChatGPT MCP server to the gateway endpoint. The getting‑started guide walks you through the required manifests, and the learn section explains how to fine‑tune masking and approval workflows.
Ready to see the code? Explore the open‑source repository on GitHub and start securing your AI coding agents today.
FAQ
What kinds of commands can hoop.dev block?
Any command that matches a policy rule can be denied. Typical examples include destructive Kubernetes operations, creation of privileged resources, or any API call that attempts to read secret objects. The block happens before the request reaches the API server.
How does session recording work for an AI agent?
hoop.dev captures the full request and response stream for each interaction, making it possible to replay sessions later for forensic analysis or audit purposes.
Can I still use existing Kubernetes RBAC alongside hoop.dev?
Yes. hoop.dev works in parallel with native RBAC. It adds an additional enforcement layer at the gateway, so even if a role grants broad permissions, the guardrails defined in hoop.dev can still restrict or require approval for high‑risk actions.
