Human-in-the-loop approval is the only reliable way to stop an AI agent from turning a Kubernetes cluster into a disaster.
The current reality: AI agents with unfettered Kubernetes access
Most teams let an agent run with a static service account token that grants cluster‑wide privileges. The token is baked into the container image or stored in a secret that the pod reads at launch. From that point the agent talks straight to the API server, runs kubectl commands, and creates or deletes resources without any intermediate check. The result is a fast feedback loop for developers, but it also means that a compromised model or a buggy prompt can issue destructive commands before anyone notices.
Human-in-the-loop approval – what it changes and what it leaves open
Introducing a human‑in‑the‑loop approval step forces an engineer to sign off on each high‑risk operation. The workflow typically intercepts a request, presents the command to a reviewer, and only proceeds after explicit consent. This approach blocks accidental or malicious actions that lack manual validation, and it gives a clear audit point where a person can verify intent.
However, the request still travels directly from the agent to the Kubernetes API server after approval. The path itself provides no built‑in logging, no inline masking of sensitive fields, and no guarantee that the approved command matches the original intent if the agent modifies it later. In other words, human‑in‑the‑loop approval solves the decision problem but leaves the enforcement surface exposed.
Automated guardrails – what they fix and where they fall short
Automated guardrails embed policy checks inside the agent or as an admission controller in the cluster. They can block commands that match a blacklist, enforce naming conventions, or prevent creation of privileged pods. Guardrails act instantly, scale to thousands of requests, and remove the latency of waiting for a reviewer.
Yet guardrails operate in isolation from a central audit trail. When a rule blocks a command, the system often only records a generic denial without the full context of who initiated the request or why. Moreover, guardrails cannot intervene when a policy gap exists; a new type of risky operation will slip through until a rule is added. Automated guardrails therefore provide speed but lack comprehensive visibility and flexible approval pathways.
Why a single data‑path gateway is required
Both approaches need a place where every request can be inspected, recorded, and optionally transformed before it reaches the Kubernetes API. That place is the data‑path gateway, and hoop.dev fulfills that role.
hoop.dev sits between the identity provider and the cluster. It verifies OIDC or SAML tokens, determines the caller’s groups, and then forwards the request through a secure agent that lives inside the network. Because hoop.dev controls the traffic, it can enforce any of the following outcomes:
- Record each session for replay and audit, so investigators can see exactly what commands were run and what responses were returned.
- Mask sensitive fields in API responses, preventing secrets from leaking into logs or downstream tools.
- Require just‑in‑time human‑in‑the‑loop approval for commands that match a risk policy, pausing execution until a reviewer signs off.
- Apply automated guardrails that block or rewrite disallowed operations before they reach the API server.
- Enforce role‑based scopes so that a service account can only act on a predefined namespace or resource type.
Because hoop.dev is the only point where traffic passes, the enforcement outcomes exist solely because hoop.dev sits in the data path. Without that gateway, the identity check would still happen, but the subsequent audit, masking, approval, and blocking would be impossible to guarantee.
In practice, teams can combine both strategies inside hoop.dev. A policy can declare that any kubectl delete pod command triggers a human‑in‑the‑loop approval, while all kubectl exec commands are automatically scanned against a guardrail rule set. The gateway records the decision, masks any retrieved secrets, and stores a replay‑ready session log. This unified control surface eliminates the gaps left by using either approach alone.
Getting started with hoop.dev involves deploying the gateway (Docker Compose for a quick test, or Kubernetes for production), connecting it to your OIDC provider, and registering the Kubernetes cluster as a connection. The detailed steps live in the getting‑started guide and the broader feature documentation at hoop.dev learn. The source code is open‑source on GitHub, so you can inspect or extend the enforcement logic as needed.
FAQ
Does human‑in‑the‑loop approval add latency? Yes, any request that requires manual consent pauses until a reviewer approves. The delay is intentional to ensure deliberate action for high‑risk operations.
Can automated guardrails be bypassed? Guardrails run inside hoop.dev’s data path, so they apply to every request that passes through the gateway. Bypassing would require a direct connection to the API server, which hoop.dev blocks by default.
Do I still need to manage Kubernetes RBAC? Yes. hoop.dev respects the underlying RBAC model, but it adds an extra layer of verification and logging on top of it.
For the full implementation details, explore the repository at github.com/hoophq/hoop.
