A fully governed EKS environment lets autonomous agents run only after a human approves each risky operation, and it provides clear approval workflows for every request. In that state, teams trust that bots do not bypass policy, auditors can trace exactly what was executed, and compliance requirements are met without manual post‑mortem effort.
Today many organizations hand autonomous scripts direct network access to an EKS cluster using a shared IAM role or static kubeconfig. The script can issue kubectl exec, helm install, or raw API calls without any visibility. Engineers often embed the same credentials in CI pipelines, and the cluster sees a single identity performing every action. That creates a blind spot: no per‑request approval, no audit trail, and no way to redact secrets that appear in command output.
Teams need a control plane that sits between the agent and the cluster, intercepts each request, checks it against an approval policy, and logs the interaction. The setup that decides who may start a session, assigning OIDC groups, provisioning a dedicated IAM role for the gateway, and configuring RBAC in the cluster, does not stop a rogue script from executing on its own. Those identity checks only answer who is trying, but they do not enforce what may be done now without a data‑path enforcement point.
Why approval workflows matter for autonomous agents
Autonomous agents can act faster than a human can review logs. A single mistaken command can delete a namespace, expose credentials, or trigger a cascade of resource consumption. Approval workflows introduce a human decision point that pauses the operation until a designated reviewer confirms the intent. This reduces the blast radius of accidental or malicious activity and creates a documented trail of who authorized what.
In addition to the pause, teams need real‑time masking of sensitive fields, such as token values returned by kubectl get secret, so that logs do not become a source of credential leakage. Finally, every session must be recorded so that a replay can be used for forensic analysis or compliance evidence.
How hoop.dev enforces approval workflows on EKS
hoop.dev acts as a Layer 7 gateway that proxies all Kubernetes API traffic. The gateway runs an agent inside the same network as the EKS cluster and assumes a dedicated IAM role that the cluster trusts. When an autonomous process connects, hoop.dev first validates the OIDC token, then checks the request against the configured approval policy. If the operation flags as high‑risk, hoop.dev routes the request to a human approver. Only after the approver records consent does hoop.dev forward the command to the Kubernetes API.
During the forward, hoop.dev records the full command stream, masks any fields that match a sensitive‑data pattern, and stores the session for later replay. Because the gateway sits in the data path, the agent never sees the raw credentials, and no command can bypass the policy without being blocked.
Setup requirements
- Deploy the hoop.dev gateway using the standard Docker‑Compose or Kubernetes manifest. The deployment includes an OIDC client that trusts your identity provider.
- Create a dedicated IAM role that the hoop.dev agent can assume. This role appears in the EKS connection configuration.
- Map the assumed role to a Kubernetes ClusterRoleBinding that grants only the permissions needed for the approved operations.
- Define approval policies in the hoop.dev configuration, marking commands such as delete, scale, or apply as requiring manual sign‑off.
The getting‑started guide and the detailed learn section describe all of these steps. The repository contains the full manifest files and example policy snippets.
Benefits of placing enforcement in the data path
Because hoop.dev sits between the autonomous agent and the EKS API, it becomes the only place that guarantees approval, masking, and recording. The identity system alone cannot block a command after the token has been issued, and the Kubernetes API cannot retroactively hide data that has already been streamed to a log. hoop.dev provides a single, auditable enforcement surface that satisfies both security and compliance goals.
With hoop.dev, teams gain:
- Just‑in‑time approval that stops risky commands until a reviewer signs off.
- Automatic redaction of secrets in command output, preventing credential leakage.
- Full session recordings that can be replayed for incident response or audit purposes.
- Clear evidence that auditors can review without building a separate logging pipeline.
FAQ
Do I need to change my existing CI pipelines?
No. CI jobs simply point their kubectl or API client at the hoop.dev endpoint. The gateway handles authentication, approval, and masking transparently.
Can I bypass the approval step for low‑risk commands?
Yes. Policies can scope by command type, namespace, or user group, allowing routine actions to flow without interruption while still protecting high‑impact operations.
Where are the session recordings stored?
Recordings reside in the storage backend configured for hoop.dev. The location lives in the gateway configuration and stays separate from the Kubernetes cluster, ensuring that logs survive even if the cluster is compromised.
For an overview of all supported connectors, visit the hoop.dev product page. Explore the source code, contribute improvements, and see the full list of supported connectors on GitHub: https://github.com/hoophq/hoop.
