Many teams assume that assigning an IAM role to the MCP service is enough to keep its actions under control. The reality is that a role alone does not prevent the service from executing any command it can reach, nor does it provide visibility into who initiated each request. Effective IAM for MCP requires a runtime enforcement point that can evaluate intent, enforce policy, and capture evidence for every operation.
Why IAM matters for MCP
MCP (Model‑Centric Programming) servers often run code that interacts with databases, internal APIs, and cloud resources on behalf of users or automated agents. When those interactions are unrestricted, a compromised credential or a buggy model can cause data leakage, unauthorized changes, or lateral movement across the environment. IAM is intended to limit each request to the minimum privileges required for the specific task, and to ensure that every privileged action is traceable back to an identity.
The missing enforcement layer
Setting up OIDC or SAML authentication and granting a scoped IAM role is the essential setup step. It determines who can start a session, but it does not enforce what that session may do once it reaches the target resource. Without a gateway in the data path, the request flows directly from the MCP process to the database or API, bypassing any real‑time checks, approvals, or masking. The result is a blind spot: no command‑level audit, no inline data protection, and no way to intervene on a risky operation.
hoop.dev as the data‑path gateway
hoop.dev fills that missing enforcement layer. It is a Layer 7 gateway that sits between authenticated identities and the infrastructure that MCP accesses. When a user or an automated agent presents an OIDC token, hoop.dev validates the token, extracts group membership, and then proxies the connection to the target service. Because the proxy operates at the protocol level, it can apply just‑in‑time (JIT) access, route suspicious commands to a human approver, mask sensitive response fields, and record the entire session for replay.
How the architecture works for MCP
1. An identity provider issues an OIDC token to the user or AI agent that will invoke the MCP service. 2. hoop.dev, acting as the relying party, verifies the token and determines the caller’s permissions. 3. The request is forwarded to the MCP runtime through a network‑resident agent that holds the target credentials; the caller never sees those secrets. 4. As the MCP process talks to the downstream database or API, hoop.dev inspects each request and response. 5. Based on the IAM policy, hoop.dev may allow the operation, pause it for approval, mask fields such as credit‑card numbers, or block it entirely. 6. Every interaction is recorded, creating an audit trail that ties the action back to the original identity.
Enforcement outcomes delivered by hoop.dev
- hoop.dev grants just‑in‑time access, ensuring that a credential is only usable for the duration of an approved session.
- hoop.dev routes high‑risk commands to an approval workflow, preventing accidental or malicious execution.
- hoop.dev masks sensitive data in real time, reducing exposure of PII or secret keys.
- hoop.dev records each session, providing replay capability and a complete audit log for compliance reporting.
- hoop.dev enforces policy at the gateway, meaning the MCP process itself cannot bypass the controls.
Getting started with IAM for MCP
To put this architecture into practice, begin with the getting‑started guide. The guide walks you through deploying the hoop.dev gateway, configuring OIDC authentication, and registering an MCP connection. Detailed feature explanations are available in the learn section, where you can explore JIT access, approval workflows, and data masking. The entire project is open source under an MIT license; you can review and contribute to the code on GitHub.
FAQ
Does hoop.dev replace existing IAM policies?
No. Existing IAM roles still define who may request access. hoop.dev builds on those roles and adds runtime enforcement, so the two work together.
Can I use hoop.dev with any OIDC provider?
Yes. hoop.dev is an OIDC relying party and works with Okta, Azure AD, Google Workspace, and other compliant providers.
What happens if the gateway goes down?
Because the gateway holds the credentials for the downstream resources, a failure blocks new sessions, which is a safe default. Existing sessions continue until they naturally terminate, and the audit logs remain intact for post‑mortem analysis.
