Approval workflows are essential when autonomous agents act on Kubernetes clusters.
Allowing autonomous agents to run commands inside a Kubernetes cluster without human oversight creates a direct path to production‑breaking changes.
These agents often act on behalf of services, CI pipelines, or AI‑driven bots. They can scale actions faster than a person can review them, and a single mis‑configuration can cascade across dozens of namespaces. The core security question is not whether the agent can authenticate – that is handled by the identity provider – but whether every privileged operation is captured, reviewed, and recorded before it reaches the cluster.
To protect a Kubernetes environment you need three things:
- Intent capture. Record the command, the target namespace, and the identity that triggered the request.
- Human approval. Require an authorized reviewer to explicitly allow risky actions such as pod deletions, role bindings, or cluster‑wide configuration changes.
- Collect audit data for later review. Capture the full request and response so investigators can reconstruct what happened.
Identity providers (Okta, Azure AD, Google Workspace, etc.) issue OIDC or SAML tokens that identify the agent. Those tokens decide who is making the request and whether the request is allowed to start. This setup step is essential, but it does not enforce any policy on the request itself.
Why approval workflows matter for autonomous agents on Kubernetes
Without a control point that sits between the token verification step and the Kubernetes API server, an agent can execute any command its service account permits. The API server will honor the request, and no central log will show why the operation happened. This leaves two dangerous gaps:
- There is no point where a security team can intervene before a destructive command runs.
- Post‑incident investigations rely on scattered audit logs that may be incomplete or tampered with.
Both gaps are solved only when the enforcement logic lives in the data path – the actual network hop that carries the request to the Kubernetes control plane.
hoop.dev as the data‑path gateway
hoop.dev provides a Layer 7 gateway that proxies every Kubernetes client request. The agent runs a lightweight network‑resident process that forwards traffic to the gateway, and the gateway forwards it to the Kubernetes API server. Because the gateway sees the full protocol payload, it can apply the following controls:
- Inline approval. When a request matches a policy that requires human sign‑off – for example, creating a ClusterRoleBinding – hoop.dev pauses the request and routes it to an approval workflow. An authorized reviewer can approve or reject the operation before it reaches the API server.
- Session recording. hoop.dev records the entire request and response stream, creating a replayable session that can be inspected later for forensic purposes.
- Data masking. Sensitive fields returned by the API, such as secret data, are masked in real time, preventing accidental exposure in logs or downstream tools.
All of these enforcement outcomes are possible only because hoop.dev sits in the data path. If you removed hoop.dev but kept the same OIDC setup, the agent would still authenticate, but no approval or recording would occur.
Architecting the approval workflow
Design your policy around the actions that pose the highest risk. Typical candidates include:
- Creating, updating, or deleting ClusterRole or ClusterRoleBinding objects.
- Running exec into privileged pods.
- Modifying etcd configuration or admission controllers.
For each action, define a rule in hoop.dev that marks the request as “requires approval”. When the rule triggers, hoop.dev captures the request details – the user identity, the exact manifest, the target namespace – and sends a notification to the configured approvers. The approvers review the request in a UI or via an integration (Slack, email, etc.) and explicitly grant permission. Once approved, hoop.dev forwards the original request to the Kubernetes API server; if rejected, the request is aborted and a denial audit entry is recorded.
Because the gateway records the full request and response, you also get a complete audit trail without any extra instrumentation on the cluster. This trail can be exported to your SIEM or retained for compliance audits.
Getting started
To try this pattern, deploy the hoop.dev gateway using the official Docker Compose quick‑start, configure a connection for your Kubernetes cluster, and enable the approval guardrail for the high‑risk resources you identified. Detailed steps are in the getting‑started guide, and the feature reference is covered in the learn section. The source code and example configurations are available in the public repository.
Explore the open‑source implementation on GitHub to see how the gateway is built and to contribute.
FAQ
Q: Does hoop.dev replace the Kubernetes RBAC system?
A: No. RBAC still decides which service accounts can issue a request. hoop.dev adds a separate, upstream gate that can require human approval and record the interaction.
Q: Can I use hoop.dev with existing CI pipelines?
A: Yes. Your pipeline can obtain an OIDC token, then direct its kubectl commands through the hoop.dev gateway. The pipeline will be subject to the same approval policies you define.
Q: What happens if the approval service is unavailable?
A: hoop.dev treats the lack of a response as a denial, ensuring that no risky operation proceeds without explicit consent.
By placing a policy‑enforcement gateway in front of Kubernetes, you gain fine‑grained approval workflows, persistent session records, and real‑time data protection for every autonomous agent that touches your clusters.
