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

Run an audit of everything that can reach your EKS cluster right now and you will find more than you expected: a CI role, two former contractors' bindings, a debugging kubeconfig from last quarter, and now an AI agent with a token that never expires. Every one of those is standing access, and standing access is what attackers and runaway agents both depend on. Just-in-time access removes it. Configuring AI agents access to EKS with just-in-time access means the agent has no cluster permissions until the moment it needs them, and none after.

Standing access is the real liability

A permission that exists at 3am whether or not anyone is using it is a permission an attacker can use at 3am. For AI agents the math is worse, because the agent is always running. If its access is standing, the window of exposure is "always." Just-in-time access collapses that window to the duration of an approved task. The same credential that was a liability for sixteen idle hours a day becomes a grant that exists for the ninety seconds the agent actually needs it.

What just-in-time access requires architecturally

For access to be genuinely just-in-time, the grant has to be issued by something the agent does not control, and it has to expire on its own. If the agent can extend its own access, it is not time-bound, it is self-service standing access with extra steps. So the control point sits in front of the cluster, not inside the agent.

hoop.dev is an open-source Layer 7 access gateway built to sit at that point. Its kubernetes-eks connector proxies kubectl and exec to the cluster through a network-resident agent that assumes a configured IAM role, the EKS_ROLE_ARN, mapped to Kubernetes RBAC. The AI agent does not hold the role; it requests access through the gateway, the gateway grants it for a bounded window, and the grant lapses without anyone remembering to clean it up.

Configuration steps

1. Define the EKS connection in hoop.dev with cluster URL, region, cluster name, and the IAM role ARN mapped to a narrow RBAC role.
2. Set the connection to require just-in-time access rather than a standing grant, so the agent starts with zero permissions on it.
3. Configure the access window and any approval requirement for the agent's identity.
4. Have the agent request access at task time; the gateway issues a time-bound session against the EKS connection.
5. Verify that after the window closes, a kubectl get pods through the gateway is denied without a fresh grant.

# access request, not a standing binding
identity: agent-deploybot
connection: prod-eks
duration: 30m   # session lapses automatically
approval: required

The configuration reads as a request, not a binding, and that framing is the whole point. A binding is a fact about the cluster that persists. A request is an event that the gateway grants, scopes, records, and then forgets when the clock runs out.

Pitfalls

• Do not set the window so long that "just-in-time" becomes "all day." Match it to the task at hand.
• Do not let the agent re-request in a tight loop without approval. Rate limits and approval are part of the control surface, not optional extras.
• Do not confuse session timeout at the cluster with just-in-time access at the gateway. The gateway is what withholds the grant until it is requested in the first place.

The argument for this model

One approach leaves the agent permanently able to reach prod and hopes nothing goes wrong. The other gives access only during an approved, recorded window and takes it back automatically. just-in-time access is the second, and hoop.dev is how you run EKS that way. See the getting started guide and read more on time-bound access models.

FAQ

Does the agent ever have standing access to EKS? No. With just-in-time access the agent starts with no permissions on the connection and only gets a time-bound grant when it requests one.

What expires when the window ends? The session against the EKS connection. The cluster-reaching IAM role stays at the gateway; the agent's grant simply lapses.

Can I combine this with approvals? Yes. Just-in-time access and approval gating compose, so a risky window can require a human to approve before it opens.

hoop.dev is open source and MIT licensed. Get the code at github.com/hoophq/hoop and replace standing EKS access with windows that close on their own.