Configuring autonomous agents access to EKS with just-in-time access

Giving a bot unrestricted, long‑lived credentials to an EKS cluster is a recipe for a massive breach.

Most teams hand a service account a static IAM role, bake that role into CI/CD pipelines, and let the agent run kubectl commands whenever it likes. The credential never expires, the role is often bound to cluster‑admin permissions, and there is no systematic record of which command was run, by which automation, and when. If the token is leaked or the pipeline is compromised, an attacker inherits full control over every namespace, every pod, and every node.

Just-in-time access promises to hand out privileges only for the moment they are needed, then revoke them automatically. In practice, teams often implement a time‑boxed token or a short‑lived IAM role, but the request still travels straight to the EKS API server. The gateway that could enforce approvals, mask sensitive responses, or record the exact kubectl sequence never sees the traffic, so no additional guardrails are applied.

Enter hoop.dev as the Layer 7 gateway that sits between the autonomous agent and the Kubernetes control plane. The gateway receives the user’s OIDC token, validates identity, and then assumes a dedicated IAM role that is mapped to a Kubernetes RBAC binding. Because the gateway is the only point that can forward traffic to the cluster, it becomes the place where just-in-time policies are enforced.

Setup: identity and credential provisioning

The first step is to configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) that issues tokens for your automation identities. hoop.dev acts as the relying party, reading group membership from the token to decide whether a request may start. A separate IAM role is created for the hoop.dev agent; the role is granted permission to assume the EKS‑specific role that the gateway will use for each session. This separation ensures that the automation identity never sees the cluster credential directly.

The data path: hoop.dev as the enforcement boundary

When an autonomous agent initiates a kubectl command, the request is routed to hoop.dev instead of the EKS endpoint. hoop.dev forwards the traffic to the cluster after applying the configured policy checks. Because the gateway sits in the data path, it can block dangerous commands, require a human approver for privileged operations, and mask fields such as secret keys that appear in API responses.

Enforcement outcomes delivered by hoop.dev

hoop.dev records every command and its result, creating a session log that can be replayed for audit or forensic analysis. It masks sensitive data in real time, so even a compromised agent never sees raw secrets. For operations that exceed the agent’s baseline role, hoop.dev routes the request to an approval workflow; the command only proceeds after a designated reviewer grants permission. All of these outcomes exist because the gateway controls the traffic, not because the identity provider or IAM role alone can enforce them.

Why just-in-time access matters for autonomous agents

• Reduced blast radius – a short‑lived role limits exposure if a token is stolen.
• Full visibility – session logs show exactly what automation did, satisfying audit requirements.
• Dynamic risk mitigation – risky commands can be blocked or sent for approval without changing the underlying IAM policy.
• Compliance readiness – the recorded evidence can be used to demonstrate compliance with standards that require per‑action logging.

All of these benefits rely on the gateway being in the data path; without hoop.dev, the autonomous agent would talk directly to the EKS API and none of the guardrails would be applied.

Getting started

To try this pattern, follow the getting‑started guide that walks you through deploying the hoop.dev gateway, configuring the OIDC connection, and defining the EKS role mapping. The learn section contains deeper explanations of just‑in‑time policies, approval workflows, and session replay.

FAQ

Is the agent still required to have direct cluster credentials?

No. The agent only needs permission to contact the hoop.dev gateway. The gateway holds the EKS credential and presents it to the cluster on behalf of the session.

Can I still use existing CI/CD pipelines?

Yes. Replace the direct kubectl endpoint with the hoop.dev endpoint and let the pipeline obtain an OIDC token for its service account. The rest of the pipeline remains unchanged.

What happens if an approval is not granted?

hoop.dev aborts the command and returns an error to the caller. The session is still recorded, so you have evidence of the attempted operation.

Ready to secure your autonomous agents on EKS? Visit the GitHub repository to clone the project, explore the code, and contribute.