Configuring AI agents access to EKS with session recording

A pod gets deleted in production at 2am. By morning you know it happened but not what ran, in what order, or under whose authority. If the actor was an AI agent, you have logs from the agent's own process, which is exactly the thing you cannot trust after an incident. Session recording fixes the gap by capturing what crossed the boundary, not what the agent says it did. Configuring AI agents access to EKS with session recording puts that record where the agent cannot edit it.

Why session recording has to live outside the agent

An agent that can write its own audit log can also omit from it. The same is true of an agent that can reach the cluster directly: there is no independent witness to the commands it issued. The architectural requirement is that the record of what reached EKS accumulates somewhere the agent does not control. That is the difference between a log and evidence. A log is a story the actor tells. Evidence is what an independent observer saw.

Where hoop.dev records

hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector proxies kubectl and exec traffic to the cluster through a network-resident agent, and it records each session at the command level as the traffic passes through. The agent reaches the cluster by assuming a configured IAM role, the EKS_ROLE_ARN, that maps to Kubernetes RBAC, while the AI agent's identity is attributed to every recorded command.

Because the recording happens at the gateway, on the wire, the AI agent has no path to alter it. You get an ordered, attributed transcript of every command and its output, independent of whatever the agent's own process believes it did.

Configuration steps

1. Configure the EKS connection with cluster URL, region, cluster name, and the role ARN mapped to a scoped RBAC role.
2. Enable session recording on the connection so kubectl and exec sessions are captured natively.
3. Bind the AI agent's identity to the connection so its commands are attributed in the recording.
4. Route recordings to your retention store and set a retention period that matches your review and audit needs.
5. Verify by running kubectl delete pod test through the gateway and confirming the command, actor, and output appear in the session record.

# every command through the gateway is captured
session: 0c9f...  actor: agent-deploybot
12:02:11  kubectl get pods -n payments
12:02:19  kubectl exec checkout-7b9 -- sh
12:02:31  kubectl delete pod checkout-7b9 -n payments

That transcript is what turns "a pod was deleted" into "agent-deploybot ran these three commands in this order, and here is the output it saw." The difference between those two sentences is the difference between guessing and knowing during an incident review.

It also changes how you reason about an agent before an incident ever happens. When you know every command will be captured at the gateway with the agent's identity attached, you can let the agent operate with a smaller margin of fear, because the worst case is bounded and observable. Recording does not prevent a bad command on its own, but it removes the blind spot that makes teams either over-restrict an agent into uselessness or let it run with no accountability at all. A recorded boundary is what makes the middle path defensible.

Pitfalls

• Do not rely on the agent's own activity log as your audit trail. It is the suspect, not the witness.
• Do not record without retention. A transcript you discard before the next audit is no transcript at all.
• Do not assume recording implies blocking. Recording captures what happened; pair it with approvals if you also need to gate it before it runs.

The model this builds to

One design trusts the agent to tell you what it did. The other captures every command at the boundary it crosses. session recording is the second, and hoop.dev is built so the record lives outside the agent's reach. Start with the getting started guide, and see how command-level audit composes with other controls.

FAQ

What does session recording capture for EKS? The kubectl and exec commands that pass through the gateway, with the issuing identity and the output, in order.

Can the AI agent tamper with the recording? No. Recording happens at the gateway as traffic passes through, outside the agent process.

Does recording slow the agent down? Recording runs inline on the connection; it captures the session as it streams rather than gating each command.

hoop.dev is open source. Clone it from github.com/hoophq/hoop and give your EKS access a record an agent cannot rewrite.