An offboarded contractor’s CI pipeline still contains a step that calls an internal LLM through an MCP gateway. The build succeeds, but no one can tell which prompt was sent or what answer was returned. In both cases the organization believes the gateway is the only point of control, yet the raw traffic passes straight through without any record of who invoked it or what data was exchanged. Because there is no audit trail, the team cannot answer basic forensic questions about those interactions.
The same pattern shows up in a nightly batch job that streams logs to a model for anomaly detection. The organization’s confidence is misplaced. By default, an MCP gateway is a thin proxy that forwards protocol‑level traffic to the target model. It authenticates the caller via OIDC or a service token, but after the handshake the request flows directly to the LLM backend. No session is persisted, no response fields are inspected, and no human ever sees a summary of the interaction. The result is a blind spot in the organization’s audit trail.
Why the default MCP setup leaves the audit trail incomplete
The initial premise of an on‑prem MCP gateway is to give developers a convenient endpoint for LLM calls. The gateway validates the caller’s identity, enforces rate limits, and may inject a few headers. However, the gateway does not sit in the data path where enforcement decisions are made. It does not capture request payloads, it does not redact sensitive fields from responses, and it does not store a replayable log of each exchange. Consequently, the organization’s audit trail – the chronological record required for forensic analysis, compliance reporting, and internal accountability – remains empty.
Even when the identity provider is tightly configured, the missing piece is the ability to observe and act on the content of the LLM conversation. Without a dedicated audit layer, a compromised token or a rogue automation script can issue unlimited prompts, exfiltrate proprietary data, or generate disallowed content, all without leaving a trace.
How hoop.dev closes the gap
Enter hoop.dev. It is a Layer 7 gateway that sits directly between the caller’s identity and the MCP target. By positioning itself in the data path, hoop.dev can inspect every request and response, enforce policies, and record an immutable audit trail for each session. The gateway holds the credential used to reach the LLM, so the caller never sees it, and it can apply just‑in‑time approvals before a risky prompt is sent.
When a user or an automated agent initiates a request, hoop.dev validates the OIDC token, checks group membership, and then forwards the traffic to the MCP gateway. Before the request leaves the gateway, hoop.dev logs the full payload, applies any configured inline masking rules (for example, redacting credit‑card numbers or internal project identifiers), and, if required, routes the request to a human approver. After the LLM returns a response, hoop.dev records the answer, applies the same masking policies, and records the complete exchange in an immutable audit trail that can be inspected later.
What the audit trail looks like with hoop.dev
- Every session is timestamped and tied to the original identity.
- Request payloads and responses are stored with field‑level masking applied according to policy.
- Approval events are captured, showing who granted or denied a request.
- All audit trails are immutable and can be exported for external audit or compliance reporting.
Because hoop.dev controls the flow, the organization gains a definitive record of each actor’s actions, even when the underlying LLM service itself provides no native logging.
Key considerations when deploying hoop.dev for MCP gateways
- Deploy the hoop.dev agent on the same network segment as the MCP gateway to avoid additional latency.
- Configure OIDC or SAML integration so that identity verification happens before any request reaches the LLM.
- Define masking rules that match the data sensitivity of your organization – e.g., regexes for PII, token patterns, or custom business identifiers.
- Enable just‑in‑time approval for high‑risk prompts, such as those that request code generation or data extraction.
- Regularly review the stored audit trail to detect anomalous usage patterns.
These steps ensure that hoop.dev becomes the authoritative audit point for all LLM interactions, turning a blind spot into a verifiable record.
FAQ
Does hoop.dev replace the MCP gateway?
No. hoop.dev sits in front of the existing MCP gateway. It forwards traffic after applying its own policies, so the underlying LLM integration continues to work unchanged.
Can existing CI pipelines use hoop.dev without code changes?
Yes. Because hoop.dev works at the protocol level, pipelines can point their LLM endpoint to the hoop.dev address instead of the raw MCP gateway. No application‑level modifications are required.
What happens to sensitive data in responses?
Inline masking rules defined in hoop.dev redact or hash configured fields before the data is written to the audit store, ensuring that logs never expose raw secrets.
To explore the implementation details, start with the getting‑started guide and the broader learn section. The full source code and contribution guide are available on GitHub.
