Production access control for AI agents on EKS

Production is the namespace where a mistake costs money and a breach costs more. The instinct, when an AI agent needs to operate there, is to bolt on controls one at a time: an IAM policy here, a recording tool there, an approval step somewhere else. The result is a checklist of parts the agent can slip between. Production access control works only when those parts are one boundary the agent has to pass through, not a set of fences it can walk around.

Production access control for AI agents on EKS is the synthesis of the other controls: identity, scope, timing, approval, and record, enforced at a single point so they reinforce rather than merely coexist.

Why a single boundary, not a checklist

Each control is weak alone. Recording without scoping tells you about damage you could not prevent. Scoping without recording prevents some damage and tells you nothing. just-in-time access without approval opens windows nobody reviewed. The controls reinforce each other only when they sit on the same path, so the agent's every command meets all of them at once. That single path is the architectural requirement, and it is the thing a checklist of separate tools cannot give you.

The production access control boundary hoop.dev provides

hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector is the only route the AI agent has to the cluster. The network-resident agent reaches EKS by assuming a configured IAM role, the EKS_ROLE_ARN, mapped to Kubernetes RBAC. On that single path, hoop.dev applies the full set:

• Identity. The agent authenticates as its own non-human identity; the cluster credential stays on the connection.
• Scope. The connection maps to a narrow RBAC role, so the agent's ceiling is fixed.
• Timing. just-in-time access grants a bounded window instead of standing permission.
• Approval. Risky operations pause for a human before they reach the cluster.
• Record. Every command is recorded at the gateway, attributed to the agent.

Standing it up

1. Create a scoped RBAC role and map it to the connection's IAM role.
2. Define the EKS connection with cluster URL, region, cluster name, and the role ARN.
3. Register the agent as a non-human identity and grant it the connection with just-in-time access.
4. Set approval rules for destructive operations and enable session recording.
5. Verify the full path: the agent requests access, gets a bounded window, runs an allowed command that is recorded, and is blocked on a destructive one until approved.

path: agent -> hoop.dev gateway -> EKS connection (role ARN -> RBAC)
controls on this path: identity, scope, JIT, approval, recording
agent's only route to the cluster: this one

The verification step is the one that proves you have a boundary rather than a pile of features. If the agent can reach the cluster by any route that skips even one of those controls, you do not have production access control, you have most of it, and most of it is what attackers and accidents both look for.

Pitfalls

• Do not leave a side door. If the agent also holds a direct kubeconfig, the boundary is decorative.
• Do not enable recording and call it production access control. Recording is one of five controls, not the whole.
• Do not scope once and forget. Production access control is reviewed as the agent's job changes.

The argument this builds to

A checklist of separate tools leaves seams an agent can exploit. One boundary that carries identity, scope, timing, approval, and recording together has no seams to exploit. production access control is that boundary, and hoop.dev is built to be it for EKS. Start with the getting started guide and read how the controls compose on one path.

FAQ

What does production access control include for EKS? Scoped identity, least-privilege RBAC, just-in-time grants, approvals on risky operations, and command-level recording, on one gateway path.

Why not assemble these from separate tools? Separate tools leave gaps between them. A single boundary applies every control to every command.

Does hoop.dev replace the EKS or Kubernetes control plane? No. It governs the connection to the cluster. The AWS and Kubernetes control planes stay where they are.

hoop.dev is open source and MIT licensed. Clone it at github.com/hoophq/hoop and make one boundary your production access control for agents on EKS.