Session recording for MCP servers on EKS

Many teams assume that running an MCP server inside an EKS cluster automatically gives them a complete audit trail, because the Kubernetes API logs every request. In reality, those logs capture only control‑plane events; they never record the actual data exchanged between a client and the MCP server, nor do they provide replay of interactive sessions. What they lack is session recording, an immutable, per‑interaction log that can be replayed for forensic analysis.

When engineers connect to an MCP server they typically use the native client, authenticate with a shared Kubernetes service account, and issue commands directly against the pod. The connection bypasses any guardrails, and no one can later prove what was typed, what responses were returned, or whether a sensitive value was inadvertently exposed.

Why session recording matters for MCP services on EKS

Session recording does more than satisfy compliance checklists. It gives you concrete evidence that every interaction with the model‑serving endpoint was observed, stored, and can be replayed. This capability is essential for detecting misuse, investigating incidents, and providing auditors with a reliable audit trail of model calls.

Without a dedicated recording layer, you are left with fragmented logs that do not show the full request‑response cycle. You also risk losing context when a pod restarts, because the in‑memory stream disappears. A reliable recording solution must sit on the data path, intercepting traffic before it reaches the MCP server, and persisting a faithful copy of the session.

How hoop.dev inserts a recording layer for MCP on EKS

hoop.dev acts as a Layer 7 gateway that proxies every client connection to the MCP server. The gateway runs an agent inside the same VPC as the EKS cluster. When a user authenticates via OIDC, hoop.dev validates the token, extracts group membership, and then establishes a session on behalf of that identity.

Crucially, the agent assumes a dedicated IAM role that is mapped to a Kubernetes RBAC binding. This binding limits the user’s permissions to the specific namespace and pod that host the MCP server, enforcing just‑in‑time access. Because the connection is forced through the gateway, hoop.dev can apply its native recording controls. Every request, response, and interactive command is captured in a session log that is stored outside the pod, preserving the log even if the workload restarts.

When a session ends, hoop.dev finalises the recording and makes it available for replay through its UI or API. The recorded artifact includes timestamps, the full payload, and the identity of the requester, satisfying audit requirements without exposing the underlying credentials to the user.

Architectural flow

• Developer authenticates with the corporate IdP (Okta, Azure AD, etc.) and receives an OIDC token.
• hoop.dev validates the token and maps the user to a role that can assume the EKS IAM role for the MCP connection.
• The gateway agent assumes the EKS IAM role, which is bound to a Kubernetes ClusterRole that grants access only to the target pod.
• The client’s traffic is proxied through hoop.dev, which records the full request‑response stream.
• After the session, hoop.dev stores the recording in a secure backend, ready for audit or replay.

Getting started

To enable session recording for your MCP servers, follow the standard hoop.dev deployment guide. The quick‑start uses Docker Compose to launch the gateway and the agent, and the documentation walks you through configuring the EKS IAM role, the Kubernetes RBAC binding, and the MCP connection definition.

All of the detailed steps are covered in the getting‑started guide. For deeper insight into how the recording feature works and how to replay sessions, see the learn section of the site.

FAQ

Does hoop.dev store the raw model data?

No. hoop.dev records the traffic that passes through the gateway, which includes request parameters and responses. The underlying model files remain inside the MCP pod and are never exposed to the gateway.

Can I limit who can view recorded sessions?

Yes. Access to recordings is controlled by the same OIDC‑based policies that govern gateway access. Only users with the appropriate group membership can retrieve or replay a session.

What happens if the agent crashes during a session?

hoop.dev writes the recording incrementally to a durable store. If the agent fails, the partial log remains available, and the session is marked as incomplete in the audit UI.

Next steps

Explore the source code, contribute improvements, or spin up your own instance by visiting the repository on GitHub: hoop.dev GitHub repo.