Teams that expose LLMs through MCP gateways on Azure often configure a single service‑account credential that every internal tool uses, creating a high prompt-injection risk because the gateway forwards requests directly to the model without per‑user visibility. The gateway shares that credential across all callers, and no component records which user issued which prompt. In this configuration, there is no per‑user audit, no real‑time masking of responses, and no way to require human approval for risky instructions.
The typical mitigation strategy is to add client‑side checks or static prompt templates, but those rely on every caller to implement the same logic correctly. When multiple services, third‑party plugins, or automated agents use the same endpoint, an attacker who compromises any upstream component can inject a hidden instruction that bypasses superficial validation. The result is the model executing a malicious command or leaking secrets, and the organization has no reliable evidence of who triggered it.
What you need is a single enforcement point that sits in the data path, inspects every request, applies masking, blocks disallowed prompts, and records the full session linked to the authenticated identity. Only a gateway that can enforce policy before the model sees the prompt can guarantee that prompt-injection risk is reduced to an acceptable level.
hoop.dev as the server‑side enforcement layer
hoop.dev fulfills that requirement by acting as an identity‑aware proxy positioned directly in front of the Azure‑hosted LLM. It terminates the client connection, authenticates the caller via OIDC/SAML, and then forwards the request to the model only after applying policy checks. Because hoop.dev sits in the data path, it enforces the following outcomes:
- Session recording: hoop.dev records each prompt and response, linking them to the authenticated identity for a complete audit trail.
- Inline masking: hoop.dev redacts or replaces sensitive tokens in the model’s output before they reach the caller.
- Prompt blocking: hoop.dev evaluates incoming text against configurable patterns and rejects any request that appears to contain a malicious instruction.
- Just‑in‑time approval: for high‑risk operations, hoop.dev routes the request to an approver, pausing execution until explicit consent is recorded.
hoop.dev enforces all of these controls at the gateway, so the LLM never sees a request that has not passed the policy engine, and the caller never receives a response that has not been inspected.
How the architecture fits with MCP gateways on Azure
When an application calls the Azure LLM endpoint, it points its HTTP client at the hoop.dev gateway instead of the raw Azure URL. A lightweight agent runs inside the same virtual network as the LLM, providing a secure path for the proxied traffic. The gateway holds the Azure credential needed to invoke the model, so the calling service never handles a secret. The gateway performs authentication once using the organization’s identity provider; it then uses the resulting identity for policy evaluation.