Many assume that placing an MCP gateway on‑prem automatically satisfies access reviews.
In reality the gateway merely forwards traffic; it does not record who asked for what, nor does it enforce any policy beyond the static configuration you wrote.
Teams often provision an on‑prem MCP gateway, hand a service account token to an AI agent, and let the agent talk directly to databases, Kubernetes clusters, or internal APIs. The token is long‑lived, shared across multiple jobs, and never rotates. No central log captures the exact commands the agent runs, and no one can prove whether a sensitive field was returned or altered. When auditors ask for evidence, the answer is usually “the gateway was up and the token existed,” which fails any meaningful access‑review process.
The core problem is that access reviews need visibility into each request, but the current setup leaves the request path completely open. Even if you tighten the initial identity, using OIDC or a service account with limited scopes, the request still reaches the target resource directly. There is no checkpoint that can enforce just‑in‑time approval, mask returned data, or block dangerous commands. Consequently, the review team sees only static IAM policies, not the dynamic behavior of each session.
hoop.dev solves this gap by inserting an identity‑aware proxy into the data path of every MCP gateway connection. The gateway becomes a thin forwarder that hands off traffic to hoop.dev, which then inspects the wire‑protocol, applies masking rules, requires just‑in‑time approvals, and records the full session for later replay.
When you register an on‑prem MCP gateway as a connection in hoop.dev, the gateway no longer talks directly to the target. Instead, each client, whether a human operator or an AI‑driven agent, authenticates against an OIDC provider, receives a short‑lived token, and presents that token to hoop.dev. hoop.dev validates the token, checks group membership, and then decides if the request may proceed. If the operation matches a policy that requires review, hoop.dev pauses the request and routes it to an approver before allowing it to continue.
Because hoop.dev sits in the data path, it can enforce every access‑review control you need. It records each session, so reviewers can replay exactly what was typed and what was returned. It masks sensitive fields on the fly, ensuring that downstream logs never contain raw credit‑card numbers or personal identifiers. It blocks commands that are known to be risky, such as dropping a production database, unless a privileged approver explicitly authorizes them. All of these outcomes exist only because hoop.dev is the gatekeeper; the underlying identity setup alone does not provide them.