When autonomous agents run unchecked against an EKS cluster, you lose audit logging for every command, leaving you blind to what was executed.
In many organizations the simplest way to give a CI pipeline, a scheduled job, or an AI‑driven assistant access to a Kubernetes cluster is to drop a long‑lived IAM credential into the pipeline configuration. The agent then invokes kubectl or the Kubernetes API directly, using that static secret. No central service sees the request, no per‑command record is kept, and any accidental or malicious operation blends indistinguishably with legitimate traffic. The result is a massive blind spot: security teams cannot answer “who ran this pod” or “what kubectl command created that service” after the fact.
Moving to short‑lived IAM roles and OIDC‑based identities is a necessary first step. By issuing a token per agent, the cloud provider can identify which service account initiated the request, and Kubernetes RBAC can enforce namespace‑level permissions. However, the request still travels straight from the agent to the EKS control plane. The control plane itself does not emit a granular audit trail for every command, and there is no single point where an organization can enforce additional guardrails such as command blocking or real‑time masking. The identity layer alone does not solve the audit problem.
Enter hoop.dev, an open‑source Layer 7 gateway that sits between the identity layer and the EKS API. hoop.dev is the only place where enforcement can happen because it becomes the data path for every request. When an autonomous agent presents an OIDC token, hoop.dev validates the token, maps the identity to the configured IAM role, and then proxies the traffic to the cluster. While the traffic flows through the gateway, hoop.dev records each Kubernetes command, captures the full request and response payload, and stores a replay‑able session log. In other words, hoop.dev creates audit logging for every interaction, turning an invisible stream into a searchable evidence trail.
Why audit logging matters for autonomous agents
Autonomous agents operate without human oversight. They can be triggered by a schedule, a webhook, or an AI model that decides to scale a workload. Without audit logging, a single rogue command can create privileged service accounts, expose secrets, or delete critical resources before anyone notices. Audit logs give security analysts the ability to:
- Identify the exact command that caused a change.
- Correlate activity across multiple agents to detect coordinated attacks.
- Provide evidence for compliance reviews that require per‑user or per‑process traces.
- Replay a session to understand the context of a failure.
Because the logs are generated at the gateway, they are immutable to the agent itself – the agent never sees the log storage, and it cannot tamper with the recorded data.
How hoop.dev inserts a data‑path gateway for EKS
The architecture consists of three logical layers:
- Setup layer: Identity is provisioned via OIDC/SAML (Okta, Azure AD, Google Workspace, etc.). The agent running inside the network is granted permission to assume a dedicated IAM role that is configured on the EKS connection. This role maps to a Kubernetes ClusterRoleBinding so that the session name appears as a Kubernetes subject.
- Data‑path layer: hoop.dev’s gateway runs as a network‑resident service alongside the agent. Every kubectl or API request from the agent is forced through this gateway. The gateway inspects the wire‑protocol, applies any configured guardrails, and writes a detailed audit record before forwarding the request to the EKS control plane.
- Enforcement outcomes: Because the gateway is the only place the traffic passes, hoop.dev can provide audit logging, command‑level replay, and optional inline masking of sensitive fields. The logs are stored outside the agent’s process, guaranteeing that the agent never sees or modifies the evidence.
In practice this means that an autonomous build job that runs kubectl apply -f deployment.yaml will generate an audit entry that includes the identity of the job, the exact manifest applied, and the response from the cluster. If a policy requires human approval for privileged namespace changes, hoop.dev can pause the request, route it to an approver, and only forward it once approved, while still keeping a complete log of the interaction.
Getting started
To add audit logging for your EKS workloads, start with the official getting‑started guide, which walks you through deploying the gateway, configuring the IAM role, and registering the EKS connection. The repository on GitHub contains the Docker Compose quick‑start and Kubernetes manifests you can adapt to your environment.
- Read the step‑by‑step onboarding material at Getting started.
- Explore the feature documentation for masking, guardrails, and session replay at Learn.
- Clone the open‑source code and review the deployment examples at the project’s GitHub repository.
All configuration is driven by declarative YAML files, and the gateway automatically picks up new connections without restarting your agents.
FAQ
How does hoop.dev capture audit logs for kubectl exec sessions?
When an exec request is proxied through the gateway, hoop.dev records the command string, the target pod, the user identity, and the full output stream. The session is stored as a replayable artifact that can be inspected later.
Will routing traffic through hoop.dev add noticeable latency?
The gateway operates at Layer 7 and adds only the processing time required for inspection and logging. In most environments the added latency is measured in milliseconds and is outweighed by the security benefits of having a complete audit trail.
Can I filter audit logs per autonomous agent or per namespace?
Because each request is associated with the OIDC token and the Kubernetes RBAC subject, logs can be queried by identity, namespace, or command type. The built‑in query interface lets you slice the data exactly as needed for investigations or compliance reporting.
With hoop.dev in place, every autonomous action against your EKS clusters is visible, verifiable, and controllable – turning a blind spot into a source of confidence.
