When your internal SaaS AI services answer queries without ever leaking privileged prompts, you can trust the output and focus on delivering value. Reducing prompt-injection risk becomes a non‑negotiable baseline for any internal SaaS that exposes LLMs to users or automated agents.
Most teams start by wiring their own LLM containers directly to the application code. The model runs behind a simple HTTP endpoint, the service authenticates callers with a static API key, and every request passes straight through to the model. In that configuration the model sees the raw prompt, any malicious user can prepend instructions, and there is no visibility into which prompts succeeded or failed. The result is a flood of unintended actions, data exfiltration, or policy violations that surface only after damage is done.
Introducing an MCP (Model Control Plane) gateway changes the first part of the flow. The gateway authenticates callers via OIDC or SAML, extracts group membership, and forwards the request to the model. This step eliminates the need to embed static keys in application code and gives a single point where you can enforce least‑privilege access. However, the request still reaches the model unmediated: the gateway does not inspect the payload, does not mask sensitive fields, and does not keep a record of what was asked. In short, the gateway fixes credential sprawl but leaves prompt-injection risk untouched.
Understanding prompt-injection risk with MCP gateways
Prompt-injection risk is the possibility that an attacker injects hidden instructions into a user‑supplied prompt, causing the model to behave contrary to policy. Because LLMs treat the prompt as code, a single crafted phrase can bypass business rules, retrieve confidential data, or trigger external actions. The risk is amplified when the model is exposed to a large number of users, automated bots, or downstream services that generate prompts on the fly.
Mitigating this risk requires three things:
- Visibility: Every prompt and response must be logged in a persistent audit log, so auditors can reconstruct what the model saw.
- Inspection: The gateway must be able to parse the protocol, detect suspicious patterns, and block or quarantine dangerous commands before they reach the model.
- Control: Sensitive fields, such as API keys, PII, or internal identifiers, should be masked or redacted in the model’s response, preventing accidental leakage.
Only a component that sits in the data path can provide all three guarantees simultaneously.
Why hoop.dev is the only data‑path solution for MCP gateways
hoop.dev is a Layer 7 gateway that sits between identities and the model control plane. It receives authenticated requests, inspects the LLM protocol, and then forwards the traffic to the target model. Because hoop.dev is the only point that sees the full request and response, it can enforce the three mitigation pillars directly:
- Session recording: hoop.dev records each prompt and response, storing the audit trail outside the model process. This evidence is available for replay, forensic analysis, and compliance reporting.
- Inline masking: Sensitive fields identified in the response are redacted in real time, ensuring that downstream consumers never see raw secrets.
- Just‑in‑time approval: If a prompt matches a high‑risk pattern, hoop.dev can pause the request and route it to a human approver before the model processes it.
All of these outcomes exist because hoop.dev occupies the data path; the surrounding identity setup (OIDC tokens, service accounts) merely decides who may start a request. Without hoop.dev, the MCP gateway would still forward the raw prompt, and no enforcement could be applied.
How to integrate hoop.dev with your existing MCP gateway
Start by deploying the hoop.dev gateway in the same network segment as your model containers. The quick‑start guide walks you through a Docker‑Compose deployment that includes built‑in OIDC verification, masking policies, and session logging. Once the gateway is running, register your model as a connection in hoop.dev, supplying the host, port, and any static credentials the model needs. The gateway stores those credentials; callers never see them.
From the application side, replace the direct HTTP endpoint with the hoop.dev client or standard HTTP libraries pointed at the gateway URL. Authentication is performed by presenting an OIDC token; hoop.dev validates the token, extracts groups, and applies the appropriate policy before forwarding the request.
All configuration details, policy syntax, masking rules, approval workflow setup, are covered in the getting‑started documentation and the broader learn section. Those resources show how to define high‑risk patterns, configure replay storage, and tune the balance between security and latency.
FAQ
What if my model uses a custom protocol instead of HTTP?
hoop.dev supports a wide range of Layer 7 protocols, including gRPC and raw TCP streams. The gateway can be extended with protocol adapters, allowing you to inspect and enforce policies on virtually any LLM‑compatible transport.
Does hoop.dev add noticeable latency to model responses?
The additional hop introduces minimal overhead, typically a few milliseconds, because inspection happens at the protocol layer without decrypting payloads. For high‑throughput workloads you can scale the gateway horizontally; the open‑source design lets you add instances behind a load balancer.
Can I retain the audit logs for compliance without storing raw prompts?
Yes. hoop.dev records metadata about each session (who, when, which policy applied) and can optionally redact the raw prompt before persisting it. This lets you meet audit requirements while still protecting sensitive content.
By placing hoop.dev in the data path of your MCP gateway, you turn a simple pass‑through into a fully governed control plane that actively reduces prompt-injection risk.
Explore the open‑source repository on GitHub to get started.
