When an AI coding agent is given a static AWS IAM role, representing a non‑human identity, to reach an EKS cluster, the organization pays the price of unchecked privilege escalation, unexpected cost spikes, and audit gaps. The agent can run any kubectl command, launch pods, or modify network policies without a human ever seeing what it did. Teams often accept this risk because it is easier than building a dedicated service account for each automated workload.
Using a non-human identity for the agent is the first step toward secure automation.
Adopting a non‑human identity solves the most obvious problem: the credential is no longer tied to an individual engineer. By assigning a purpose‑built IAM role to the agent, the secret can be rotated centrally and the role can be scoped to the minimum set of API actions required for the workload. However, the request still travels straight from the agent to the EKS control plane. There is no gate that can enforce just‑in‑time approvals, mask sensitive response fields, or record each command for later review. In other words, the core security controls remain missing.
Why non‑human identity matters for EKS
Non‑human identity provides a clear ownership boundary for automated processes. It allows the organization to treat the AI agent like any other service account: the role can be granted only the permissions needed for the specific CI/CD pipeline or code‑generation task. This reduces the blast radius of a compromised secret and makes credential rotation a routine operation rather than a painful manual process.
Even with tightly scoped IAM permissions, the agent can still issue commands that affect production workloads, read secret data from ConfigMaps, or expose internal service endpoints. Without a central enforcement point, there is no way to verify that each command aligns with policy, to require a human approver for high‑risk actions, or to automatically hide fields such as passwords that appear in pod logs. These gaps become especially problematic when AI agents generate code that interacts with the cluster in unpredictable ways.
Introducing hoop.dev as the data‑path gateway
hoop.dev fills the missing enforcement layer by sitting in the data path between the non‑human identity and the EKS cluster. The gateway runs an agent inside the same network as the cluster and assumes the IAM role that the AI agent is allowed to use. Every kubectl or Kubernetes API request passes through hoop.dev, where it can be inspected, approved, masked, and recorded before it reaches the control plane.
Because hoop.dev operates at Layer 7, it can understand the Kubernetes protocol and apply fine‑grained guardrails. It can block commands that attempt to create privileged pods, trigger a just‑in‑time approval workflow for operations that modify network policies, and replace secret values in API responses with masked placeholders. Each session is captured in an immutable audit trail that can be replayed for forensic analysis or compliance reporting.
The gateway also enforces just‑in‑time access. When the AI agent initiates a connection, hoop.dev checks the request against policy, grants a short‑lived session token, and revokes it automatically when the work is done. This ensures that the non‑human identity never holds a long‑lived credential that could be misused.
All of these capabilities are configured through hoop.dev’s declarative policies, which reference the IAM role, the target EKS cluster, and the specific Kubernetes RBAC bindings that map the session to a ClusterRole. The result is a single, auditable control surface that turns a raw non‑human identity into a secure, governed access point.
To get started, follow the getting‑started guide for deploying the gateway and registering an EKS connection. The documentation walks through creating the dedicated IAM role, configuring the ClusterRoleBinding, and enabling masking and approval policies. For deeper insight into how hoop.dev’s features work together, explore the learn section of the site.
Operational considerations
When you place hoop.dev in front of EKS, you gain visibility into every API call, but you also introduce a single point of failure for the data path. Deploy the gateway in a highly available mode, use health checks, and monitor its own metrics. Because the agent runs inside the same VPC as the cluster, network latency is minimal, and the gateway can enforce policies without adding noticeable delay to developer workflows.
Auditing is simplified. hoop.dev stores session logs outside the agent process, making them tamper‑evident and readily searchable. Teams can build dashboards that surface anomalous command patterns, such as repeated pod deletions or attempts to access privileged namespaces. These signals feed into automated response playbooks that can suspend the non‑human identity pending investigation.
FAQ
- Can hoop.dev enforce policies on a per‑command basis? Yes. Because the gateway inspects each Kubernetes API call, it can apply rules that target specific verbs such as create or delete, and require approval only for the high‑risk ones.
- What happens to sensitive data returned by the API? hoop.dev can mask fields that match configured patterns, ensuring that secret values never leave the gateway in clear text.
- Is the audit log tamper‑proof? The session recordings are stored outside the agent process, providing an immutable record that auditors can verify.
Explore the open‑source implementation on GitHub to see how the gateway is built and to contribute your own extensions.
