How can you trust that every command sent to an MCP server on Kubernetes is captured for later review with session recording?
Most teams treat an MCP server like any other in‑cluster service: they deploy the container, expose it via a Service, and let developers reach it with kubectl exec or a custom client. The credential set used by the client is often a long‑lived service account token stored in a shared secret or baked into CI pipelines. Because the connection goes straight from the pod or developer workstation to the server, there is no independent record of who ran what, when, or what data was returned. If a bug or a malicious command slips through, the only evidence is the server’s own logs, which may be incomplete, rotated, or already tampered with.
This reality creates a blind spot. Even when an organization mandates that every interaction with an MCP server be auditable, the existing setup supplies only the identity check performed by Kubernetes RBAC. The request still travels directly to the server, bypassing any checkpoint that could enforce recording, mask sensitive fields, or require a human approval step. In other words, the “setup” – the OIDC‑backed service account, the RBAC role, the network policy – decides who may start a session, but it does not guarantee that the session is captured.
The missing piece is a data‑path component that sits between the caller and the MCP server and can enforce session recording as a mandatory guardrail. The component must be able to see the full protocol exchange, store a replayable stream, and tie each record to the authenticated identity that originated the request. Only when that component is present can an organization claim that every command is recorded, that the recordings are preserved for later review, and that they can be replayed for forensic analysis.
Why session recording matters for MCP servers
MCP servers often handle code generation, prompt engineering, or model‑in‑the‑loop workflows. A single stray DELETE or a malformed prompt can corrupt downstream data pipelines. Session recording provides three concrete benefits:
- Forensic traceability: When an incident occurs, the exact sequence of inputs and outputs can be reconstructed, eliminating guesswork.
- Compliance evidence: Regulations that require proof of who accessed a system and what they did can be satisfied by reliable logs.
- Operational learning: Teams can replay successful sessions to extract best‑practice patterns or to train new engineers.
These outcomes are only possible if the recording happens outside the MCP server’s own process. If the server itself is compromised, any logs it writes could be altered. The enforcement must therefore live in a separate, hardened gateway.
How hoop.dev captures every interaction
hoop.dev implements a Layer 7 gateway that proxies traffic to the MCP server. The gateway runs an agent inside the same Kubernetes cluster, close to the target pod, so network latency is minimal. When a user authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and creates a short‑lived session token that represents the user’s intent.
Because the gateway is the only point where the protocol passes, hoop.dev can record the full request‑response stream before it reaches the MCP server. Each session is stored as a replayable artifact that includes the authenticated identity, timestamp, and the raw payload. hoop.dev stores the recording so the original data is retained for later review; the gateway only forwards traffic after the recording has started.