Do you wonder whether your MCP runtime can be safely exposed to engineers, AI agents, and automation scripts **with proper guardrails**?
Most teams run the MCP server directly on a VM or container, hand the binary to developers, and let anyone with network access invoke it. The process runs with a static service account, and every request reaches the underlying model without any check. No one sees a log of which prompt was sent, no sensitive fields are redacted, and there is no way to stop a dangerous command before it reaches the model. The result is a blind spot: you have a powerful AI engine, but you lack any evidence that it was used responsibly.
What most organizations try to add is a policy that says “only approved users may call MCP, and every call must be recorded.” They configure OIDC or SAML so that the MCP service knows who is calling, and they create a role that limits which users can invoke the binary. This identity layer decides who may start a request, but the request still travels straight to the MCP process. There is still no audit trail, no inline masking of personally‑identifiable information, and no just‑in‑time approval step. In other words, the guardrails remain missing.
Why guardrails belong in the data path
Guardrails are only effective when they sit on the path that the request travels. If the enforcement point is outside the data flow, it can be bypassed or disabled.
In a typical deployment, an identity provider such as Okta or Azure AD issues an OIDC token.
Inline masking of sensitive fields
Command‑level blocking
Administrators can define patterns that are never allowed – for example, prompts that attempt to execute code, retrieve system files, or exfiltrate data.
Just‑in‑time approvals
Session recording and replay
All of these capabilities are optional and configurable, but they share a single requirement: they must be enforced where the traffic flows.
Getting started with guardrails for MCP
For detailed steps, see the getting‑started guide and the broader learn section that explains each guardrail feature in depth.
FAQ
- Can I apply guardrails to an existing MCP deployment? Yes. hoop.dev sits in front of the existing server, so you can add it without modifying the MCP binary or its configuration.
- Will hoop.dev add latency to my AI responses? The gateway processes traffic at the protocol layer and adds only the time needed for policy checks and optional masking. In most environments the added latency is measured in milliseconds and is outweighed by the security benefits.
- Do I need to change my client code? No. Clients continue to use their usual MCP client libraries or CLI tools; they simply point at the hoop.dev endpoint instead of the raw server address.
Running AI agents against production? hoop.dev is an open-source proxy that sits between agents and your databases and servers. It checks every command at runtime and masks sensitive data before it reaches the agent. Try it free: hoop.dev/start
Explore the open‑source repository to see the code, contribute, or file an issue.
