Just-in-time access is essential because an autonomous agent with perpetual EKS credentials can silently expand its privileges across a whole cluster, giving attackers a foothold that persists long after the original job finishes.
Most teams grant service accounts or CI‑CD pipelines static IAM roles that are baked into the agent’s runtime. Those roles are often wide‑scoped, allowing any pod that can reach the agent to execute arbitrary kubectl commands, read secrets, or create new workloads. The result is a “standing access” model where the request travels straight from the agent to the Kubernetes API server, leaving no trace of who issued which command or what data was returned.
Switching to a non‑human identity model, issuing short‑lived tokens or assuming a dedicated IAM role for each job, removes the permanent credential, but it does not close the audit gap. The request still reaches the EKS control plane directly; the API server sees a valid, authorized call and executes it without any intermediate check, approval step, or data‑masking layer. In other words, the core problem, visibility, control, and risk mitigation, remains unsolved.
Why just-in-time access matters for autonomous agents on EKS
Just-in-time access limits the window during which a credential can be used. By granting the minimum set of permissions for the exact operation a job needs, the blast radius of a compromised agent shrinks dramatically. The approach also forces teams to think in terms of intent: each request must be justified before it is allowed to touch the cluster.
Even with intent‑based policies, the enforcement point matters. If the policy engine sits outside the data path, a malicious actor could bypass it by calling the API directly. The enforcement must therefore be placed where every request flows, after identity verification but before the request touches the Kubernetes API server.
How hoop.dev enforces just-in-time access on EKS
hoop.dev acts as a Layer 7 gateway that intercepts every Kubernetes request. The gateway runs an agent inside the same network as the EKS cluster. When an autonomous agent wants to run kubectl or invoke the Kubernetes API, it connects to hoop.dev instead of contacting the cluster directly.
Authentication is still handled by the organization’s OIDC or SAML provider. hoop.dev validates the token, extracts group membership, and maps the request to a dedicated IAM role that the gateway’s agent assumes (the EKS role ARN configured for the connection). This role is tied to a Kubernetes RBAC binding that grants only the permissions required for that specific job.
Because the request now passes through hoop.dev, the gateway can apply several enforcement outcomes:
- Just-in-time approval: If a command exceeds a predefined risk threshold, hoop.dev routes the request to a human approver before forwarding it.
- Inline data masking: Sensitive fields in API responses, such as secret values or credential objects, are stripped or redacted in real time, preventing downstream agents from seeing data they should not.
- Command‑level audit: Every kubectl sub‑command, its arguments, and the resulting API payload are recorded. The audit log is tied to the original identity, providing a clear record of who performed each action.
- Session recording and replay: The entire interaction, including interactive exec sessions inside pods, is captured. Teams can replay a session to investigate anomalies.
- Guardrails: Known dangerous patterns, like creating cluster‑admin RoleBindings or exposing privileged ports, are blocked automatically.
All of these controls exist because hoop.dev sits in the data path. Remove hoop.dev and the request would travel directly from the autonomous agent to the EKS API server, bypassing approvals, masking, and audit. The setup of IAM roles, OIDC tokens, and RBAC bindings is still required to identify the requester, but without the gateway those pieces alone cannot enforce the policy outcomes.
Capturing the evidence you need
The recorded sessions and audit entries become the source of truth for compliance and incident response. Because hoop.dev writes each event with the original identity and timestamps, auditors can trace the exact sequence of actions that led to a change in the cluster. The same logs also feed into automated alerting pipelines, enabling rapid detection of suspicious activity.
Getting started
To try this pattern, deploy the hoop.dev gateway using the official Docker Compose quick‑start. Register an EKS connection, specify the IAM role that the gateway should assume, and configure the OIDC provider that your organization uses. The documentation walks through each step without exposing any credential to the end user.
For a complete walkthrough, see the getting‑started guide. The learn section provides deeper coverage of masking, approval workflows, and session replay. All configuration details and the source code are available in the public repository.
Explore the hoop.dev repository on GitHub to contribute, raise issues, or adapt the gateway to your own security policies.
