How can you be sure that every request passing through an MCP gateway on Azure is captured and verifiable?
An audit trail gives you the visibility you need to answer who, when, and what was sent to the model.
Many organizations adopt MCP gateways to expose large language model (LLM) services to internal applications. The gateway abstracts the model behind a simple HTTP endpoint, letting developers call it as if it were a regular API. In practice, the gateway runs inside a virtual network, forwards traffic to a managed model host, and returns responses to callers.
When the gateway is the only piece that sees the traffic, audit data ends up in three places at best: the Azure Application Gateway logs, the LLM provider’s own request logs, and occasional custom telemetry added by developers. Those sources are inconsistent, lack uniform timestamps, and often omit the exact request payload. The result is a fragmented audit trail that makes it difficult to answer questions such as “who queried the model with this prompt?” or “what data was returned to a particular service?” Without a single, reliable source, compliance teams struggle to demonstrate control, and incident responders waste time stitching logs together.
Even when teams add custom logging inside their services, they still face two gaps. First, developers could bypass the gateway by obtaining the underlying model endpoint directly, creating a blind spot. Second, the logs usually contain raw payloads, exposing sensitive information that should never be stored in plain text. A solid audit trail must therefore sit at the point where the request leaves the network, enforce consistent capture, and apply safeguards such as masking before any data is persisted.
Why audit trail matters for MCP gateways
An audit trail is more than a collection of log lines. It is a record that links the caller’s identity, a precise timestamp, the full request, and the model’s response, making the interaction reviewable later. For MCP gateways, a solid audit trail enables:
- Accountability: each prompt is linked to the caller’s Azure AD identity.
- Forensic analysis: security teams can replay a session to see how a model was used.
- Data protection: sensitive fields can be redacted before storage, reducing exposure risk.
- Compliance evidence: auditors receive a single, consistent source that satisfies regulatory expectations for access monitoring.
Where the enforcement must happen
Identity providers such as Azure AD determine who can request a token, but that alone does not enforce what happens to the request once the token is presented. The enforcement point must be the data path – the component that actually proxies the traffic between the caller and the model host. Only a gateway positioned in that path can see the full request and response, apply policies, and record the interaction.
How hoop.dev provides the missing audit trail
hoop.dev sits in the data path for MCP gateways on Azure. It authenticates callers via OIDC tokens issued by Azure AD, validates group membership, and then proxies the request to the model host. Because hoop.dev is the only system that sees the traffic, it creates the following outcomes:
- Session recording: hoop.dev records each request and response pair, attaching the caller’s identity and a precise timestamp.
- Inline masking: before persisting the logs, hoop.dev masks fields that match configured patterns, ensuring that sensitive data never appears in clear text.
- Just‑in‑time approval: for high‑risk prompts, hoop.dev can pause the request and require a human approver, adding an extra control layer.
- Command blocking: if a request contains disallowed content, hoop.dev can terminate the flow before it reaches the model.
All of these enforcement outcomes exist because hoop.dev sits in the gateway’s data path. If the same Azure AD setup were used without hoop.dev, the request would travel directly to the model host, bypassing recording, masking, and approval.
Getting started on Azure
Deploying hoop.dev for an MCP gateway follows the same pattern as any other supported connector. You provision the hoop.dev container in the same virtual network as the model host, configure an Azure AD OIDC client, and register the model endpoint as a connection. The detailed steps are covered in the getting started guide. Once the gateway is running, you can define masking rules and approval policies in the learn section of the documentation.
FAQ
What if I already have custom logging in my application?
Custom logs can complement the audit trail, but they cannot replace the guarantees provided by hoop.dev. Because hoop.dev records the request at the gateway, it ensures that every call – even those that bypass your application code – is captured.
Does hoop.dev store the raw model responses?
No. hoop.dev applies inline masking before any data is written to storage, so only sanitized content is retained.
Can I use hoop.dev with other cloud providers?
Yes. hoop.dev is cloud‑agnostic; the same architecture works on Azure, AWS, or GCP, as long as the gateway can reach the target resource.
Ready to see the code in action? Contribute or view the source on GitHub.
