MCP gateways: what they mean for your audit trail (on Kubernetes)

Many believe that an MCP gateway automatically logs every AI‑generated request, but the gateway alone does not create a reliable audit trail.

In practice, teams often deploy MCP gateways on Kubernetes so that large language models can call internal services without changing application code. The gateway forwards the request, the model receives a response, and the interaction disappears into the cluster’s network traffic. No central log captures who asked what, when, or what data was returned. That blind spot makes it hard to prove compliance, investigate misuse, or even understand the impact of a faulty prompt.

The typical deployment looks like this: a service account or AI runner authenticates to the Kubernetes API, the MCP gateway runs as a sidecar, and the model talks directly to a database or HTTP endpoint. The request reaches the target, the response is sent back, and the only evidence lives in scattered application logs that may be rotated or overwritten. The setup decides who the caller is, but it provides no enforcement on the path the request travels.

Why audit trails matter for MCP gateways

An audit trail is a chronological record that can be trusted to answer three questions: who initiated the call, what operation was performed, and what data was returned. For AI‑driven workloads, those questions are critical because a single prompt can trigger a cascade of privileged actions. Without a verifiable trail, organizations cannot demonstrate that access was limited, cannot detect malicious prompting, and cannot satisfy auditors who expect per‑request evidence.

The missing piece in current deployments

Even when identity providers enforce least‑privilege tokens, the request still travels straight to the backend service. No component in the data path inspects the payload, masks sensitive fields, or requires a human to approve a risky command. The result is a system where the setup is correct, tokens are scoped, roles are minimal, but the enforcement outcomes that constitute a true audit trail are absent.

Putting the gateway in the data path with hoop.dev

hoop.dev solves the problem by becoming the sole point of egress for every MCP request. When the model sends a request, it first passes through hoop.dev’s Layer 7 gateway running on the same Kubernetes node as the MCP sidecar. Because hoop.dev sits in the data path, it can record each session, capture the exact request and response, and store the log in a durable location.

hoop.dev also applies inline masking to any fields marked as sensitive, ensuring that logs never expose credentials or personal data. If a request matches a policy that requires human approval, such as a write to a production database, hoop.dev routes the operation to an approval workflow before it reaches the target. All of these enforcement outcomes exist only because hoop.dev is positioned between the caller and the backend.

How the enforcement outcomes are achieved

• hoop.dev records each session, creating a reliable audit trail that can be replayed for forensic analysis.
• hoop.dev masks sensitive response fields in real time, preventing secret leakage in logs.
• hoop.dev blocks disallowed commands, reducing the blast radius of a malicious prompt.
• hoop.dev routes high‑risk operations to a just‑in‑time approval step, adding a human decision point.

These capabilities are independent of the identity configuration. The setup, OIDC tokens, service accounts, and role bindings, still decides who may initiate a request, but only hoop.dev can enforce the policies that turn that request into a trustworthy audit trail.

Getting started

To add hoop.dev to your MCP workflow, deploy the gateway using the standard Docker Compose or Helm chart, configure the MCP connection in the hoop.dev UI, and point your model’s endpoint to the gateway address. Detailed steps are available in the getting‑started guide and the broader learn section. Because hoop.dev is open source, you can review the code, extend policies, or contribute improvements via the repository.

FAQ

Does hoop.dev replace the identity provider?

No. hoop.dev relies on your existing OIDC or SAML provider to authenticate callers. It only adds enforcement once the identity has been verified.

Can I still use existing monitoring tools?

Yes. hoop.dev emits logs in standard formats that can be forwarded to your SIEM, while also maintaining a separate session record for audit purposes.

Is the audit trail tamper‑detectable?

hoop.dev signs each log entry, allowing you to detect any alteration after the fact.

Ready to see how hoop.dev can give you a real audit trail for your MCP gateways? Explore the code and contribute at github.com/hoophq/hoop.