A frequent misconception is that audit logs for MCP servers can be collected directly from the Kubernetes node without any intermediary. In reality, the MCP runtime writes to standard output, and the only logs you see are those the pod or container chooses to emit. That approach leaves you without a reliable record of who issued which command, what data was returned, or whether a response contained sensitive fields.
Audit logging matters because MCP servers often process proprietary code, confidential prompts, or regulated data. When a developer or an automated agent talks to an MCP endpoint, the conversation can include API keys, customer PII, or intellectual property. If an incident occurs, teams need a complete replay of the session to understand the scope, prove compliance, and remediate safely. Without a central, protocol‑aware recorder, you end up stitching together container logs, side‑car traces, and ad‑hoc script outputs, none of which guarantee completeness or integrity.
Most organizations today deploy MCP servers inside a Kubernetes cluster and rely on the cluster’s built‑in RBAC to limit who can exec into a pod. The typical workflow looks like this: a user authenticates to the identity provider, receives a JWT, and then uses kubectl exec to open a shell or run a one‑off command inside the MCP container. The Kubernetes API server checks the user’s group membership, grants a bearer token for the pod, and the request is forwarded directly to the container’s process. The pod’s process sees the command, executes it, and streams the response back. No component in that chain inspects the payload, masks secrets, or writes a definitive audit record. The result is a "standing access" model where the user’s token can be reused for the duration of the session, and the only evidence of what happened lives in the pod’s stdout or a transient log file.
This model fixes authentication and basic authorization, but it leaves three critical gaps:
- The request travels straight from the user to the MCP process, so there is no place to enforce inline masking of secrets that might appear in responses.
- There is no mandatory approval step for risky commands; a privileged user can run destructive operations without oversight.
- Audit logging is optional and scattered; if the pod crashes or the node is compromised, the logs disappear.
To close those gaps, the enforcement point must sit on the data path, the exact moment traffic crosses the network boundary between the identity‑aware client and the MCP server. By inserting a Layer 7 gateway that understands the MCP protocol, you gain a single control surface that can:
- Record every request and response, preserving a replayable session for forensic analysis.
- Apply real‑time masking rules to redact secrets before they reach the client.
- Require a just‑in‑time approval workflow for commands that match a high‑risk policy.
That is precisely what hoop.dev provides. hoop.dev deploys a gateway container alongside your Kubernetes cluster. An agent runs inside the same network segment as the MCP service, and the gateway proxies all client connections. When a user presents an OIDC token, hoop.dev validates the token, extracts group membership, and then forwards the request to the MCP server only after applying the configured guardrails. Because the gateway sits in the data path, every enforcement outcome, especially audit logging, originates from hoop.dev.