An offboarded contractor still has a token that can reach the company's MCP gateway, and a nightly CI job runs with a role that grants full access to every internal service. When the contractor’s laptop is repurposed, the token remains valid for weeks, and the CI job continues to push changes without any human review.
In many organizations the IAM layer is the first line of defense. Engineers grant permissions, create service accounts, and attach roles that often outlive the original need. Over‑scoped policies, static secrets, and long‑lived tokens create a blind spot: the identity system knows who can ask for access, but nothing watches what actually happens once the request leaves the IAM check.
IAM considerations for MCP gateways
Good IAM practice starts with least‑privilege definitions, short‑lived credentials, and automatic revocation when a user leaves or a job finishes. Role‑based access control should be granular enough that a token can only invoke the specific MCP functions required for a task. Conditional policies, such as time‑bound or IP‑restricted rules, add another layer of safety.
Even with perfect IAM policies, the request still travels directly to the MCP gateway. The path from the identity check to the actual service is uncontrolled, which means there is no real‑time guardrail, no command‑level audit, and no way to mask sensitive data that might be returned by the gateway.
Why a data‑path gateway is required
This is where a Layer 7 access gateway becomes essential. hoop.dev sits between the authenticated identity and the MCP gateway, inspecting every wire‑protocol message. It validates the IAM token, maps group membership to fine‑grained policies, and then decides whether to allow, block, or route the request for approval.
Because the gateway is the only place the traffic is examined, all enforcement outcomes originate from hoop.dev. It records each session for replay, applies just‑in‑time approval workflows for risky commands, masks sensitive fields in responses, and can stop a dangerous operation before it reaches the MCP service.
How the enforcement works
- Session recording: Every interaction through the gateway is captured, providing a complete audit record that can be reviewed later.
- Inline data masking: Responses that contain secrets or personally identifiable information are redacted in real time, reducing exposure risk.
- Just‑in‑time approval: High‑risk actions trigger an approval request to a designated reviewer, preventing accidental or malicious changes.
- Command blocking: Patterns that match known destructive commands are rejected before they reach the MCP gateway.
All of these capabilities depend on the gateway being in the data path; they cannot be achieved by IAM alone.
Deploying the solution
Start by deploying the gateway in the same network segment as the MCP service. The Getting started guide walks through a Docker Compose deployment, which includes OIDC integration for token verification. Register the MCP endpoint as a connection and configure the gateway to hold the service credentials, so that users and agents never see them directly.
Next, align your IAM policies with the gateway’s policy model. Map groups or roles to the actions that the gateway will allow, and define approval workflows for any operation that exceeds a risk threshold. The Learn section provides deeper examples of policy composition and masking rules.
What to watch for
- Ensure that IAM tokens are short‑lived; the gateway will reject expired tokens, but long‑lived tokens re‑introduce the same blind spot you are trying to eliminate.
- Do not store service credentials in the IAM system; let the gateway manage them securely and keep them out of the application code.
- Validate that approval workflows are reachable and that reviewers have the necessary context to make informed decisions.
FAQ
How does hoop.dev handle token expiration? The gateway checks the token’s expiry on every request. Expired tokens are denied before any traffic reaches the MCP service.
Does hoop.dev store credentials for the MCP gateway? Yes, it holds the credentials internally so that clients never see them. The storage follows best‑practice encryption and is never exposed to the user.
Can existing IAM policies be reused? The gateway reads the identity token and can map existing group claims to its own policy rules, so you can use your current IAM structure while adding the data‑path controls.
Explore the source code and contribute on GitHub.
