The hidden risk of AI agents on EKS
When an AI‑powered coding assistant runs commands inside an EKS cluster, any missed or hidden action can become a silent breach that costs both time and reputation. The assistant can issue kubectl exec, apply manifests, or query the API without a human eye watching, and a single stray command can expose secrets, delete workloads, or open a foothold for lateral movement.
Because the agent authenticates with the same IAM role that the cluster expects, the platform treats its traffic as legitimate. Without reliable audit logging, teams cannot prove who ran which command, making incident response costly. Traditional audit pipelines that rely on cloud‑provider logs often capture only high‑level events and omit the exact command line that was executed. This granularity gap makes forensic analysis expensive and hampers compliance reporting.
Why a unified, protocol‑aware gateway is required
To close the gap, the control point must sit where the request is actually transmitted, not after the fact in a log aggregation service. A gateway that understands the Kubernetes wire protocol can inspect each API call or exec request, attach a timestamp, the requesting identity, and the full command payload before the request reaches the cluster control plane.
hoop.dev also enables just‑in‑time access: it verifies the identity, evaluates the request against policy, and can trigger an approval workflow for risky operations. Only after hoop.dev passes these checks does the traffic continue, guaranteeing that every action is both authorized and recorded. By centralising inspection, organisations gain a single source of truth for audit logging, simplifying evidence collection for standards such as SOC 2.
Placing the gateway at the protocol layer also means that any future service added to the cluster, whether a new microservice or a third‑party controller, automatically inherits the same audit coverage without additional configuration. This future‑proofs the security posture and reduces operational overhead.
hoop.dev provides audit logging for AI coding agents on EKS
hoop.dev implements the required gateway as a Layer 7 proxy that runs an agent inside the same network as the EKS cluster. The agent assumes a dedicated IAM role configured for the connection, which maps to a Kubernetes RBAC binding. When an AI coding agent initiates a session, hoop.dev validates the OIDC token, extracts group membership, and then forwards the request through its protocol‑aware data path.
Because the gateway sits in the data path, hoop.dev can record every kubectl command, exec payload, and API call. The recorded session includes the full command line, the user or service account that originated it, and a precise timestamp. hoop.dev stores these records outside the target cluster, so the cluster never sees the raw audit data and tampering is detectable.
In addition to raw command capture, hoop.dev can mask sensitive fields in responses, such as secret values returned by a ConfigMap, so that downstream consumers, including the AI assistant, never receive data they are not authorized to see. The masking happens inline, before the response leaves the gateway, preserving confidentiality without breaking the workflow.
All of these enforcement outcomes, command‑level audit logging, inline masking, just‑in‑time approval, and session replay, are possible only because hoop.dev occupies the only point where traffic can be inspected before it reaches the Kubernetes API server. The gateway also integrates with existing monitoring pipelines, allowing exported audit logs to feed SIEMs or compliance dashboards.
Getting started
Begin by deploying the hoop.dev gateway using the Docker Compose quick‑start, which provisions the agent and configures OIDC authentication out of the box. Register an EKS connection, provide the IAM role ARN that the agent should assume, and map the session name to a Kubernetes ClusterRoleBinding. The quick‑start also shows how to enable high‑availability mode so the gateway remains resilient during node failures. Detailed steps are available in the getting‑started guide and the learn section, where you’ll find best‑practice recommendations for role scoping, RBAC configuration, and policy definition.
When you configure policies, consider starting with a deny‑by‑default rule for any command that writes to the cluster, then add explicit allow rules for approved CI/CD pipelines. This approach reduces the attack surface while still letting developers perform read‑only diagnostics without friction.
Next steps and community
After the gateway is running, you can connect your AI coding agent through the hoop.dev CLI or a standard kubectl client. The agent will automatically benefit from the audit logging and masking policies you define, and you can view recorded sessions in the web UI or export them via the REST endpoint for deeper analysis.
For more advanced use cases, such as custom approval workflows, dynamic masking rules, or integration with ticketing systems, consult the documentation linked above. hoop.dev is open source and welcomes contributions. Explore the code, raise issues, or submit pull requests on GitHub to help shape the future of secure AI‑driven operations on Kubernetes.
FAQ
- Does hoop.dev store the AI agent’s credentials? No. The gateway holds the IAM role credential; the agent never sees it.
- Can I retroactively query logged commands? Yes. Recorded sessions are searchable by identity, time range, or command pattern.
- Is masking optional? Masking can be enabled per‑field or per‑resource; you control which responses are scrubbed.
- How does hoop.dev handle scaling for large clusters? The gateway can be deployed in multiple replicas behind a load balancer, each instance sharing the same IAM role configuration, ensuring consistent audit coverage as the cluster grows.
- What evidence does hoop.dev generate for compliance audits? It produces logs that capture who performed each action, when it occurred, and the exact command issued, supporting SOC 2 and other audit frameworks.
