Configuring MCP servers access to Entra with non-human identity

A common misconception is that a service can simply present a static client secret to Entra and automatically inherit the same level of security as a human user. In reality, using a non-human identity without proper controls leaves the connection wide open, exposing credentials to anyone who can read the code or the environment. Teams often embed the secret directly into deployment scripts, give the service perpetual rights, and never record what the service actually does once it talks to Entra.

That pattern creates three hidden risks. First, the credential becomes a single point of failure; if an attacker extracts it, they gain unrestricted access. Second, the service runs with standing privileges, meaning it can perform any operation at any time, even after the business need has passed. Third, there is no audit trail that shows which service performed which action, making compliance and forensics impossible.

Organizations recognize that a non-human identity should be scoped, temporary, and observable. The ideal workflow is to issue a token that represents the service, let the token be validated at the moment of access, and then enforce policies such as just‑in‑time approval, command‑level masking, and session recording. Unfortunately, Entra alone does not provide a place to insert those runtime checks. The request still travels straight from the MCP server to Entra, bypassing any gate that could enforce the needed controls.

Why a non-human identity needs a gateway

Even with OIDC or SAML tokens issued by Entra, the enforcement point must sit on the data path between the token‑bearing service and the Entra endpoint. Without that middle layer, the token is merely an authentication artifact; it does not trigger any additional safeguards. The service can still call Entra APIs with full privileges, and the organization loses visibility into the exact operations performed.

Placing a gateway in the path solves the problem. The gateway validates the token, checks group membership, and then applies policy before the request reaches Entra. Because the gateway sits in the data path, it can block disallowed commands, require a human approver for risky actions, mask sensitive fields in responses, and capture a complete session log for later replay.

How hoop.dev enforces control for Entra

hoop.dev acts as an OIDC relying party. When an MCP server presents its non‑human identity token, hoop.dev verifies the token against Entra, extracts the identity claims, and decides whether the request may proceed. The gateway then proxies the connection to Entra, inserting guardrails at the protocol level. Every request is subject to the same set of policies, regardless of which service initiated it.

Because hoop.dev holds the credential used to talk to Entra, the service never sees the secret. The gateway can issue just‑in‑time access: a short‑lived session is created only when the service actually needs to talk to Entra, and the session expires automatically when the work is done. If a request matches a high‑risk pattern, hoop.dev routes it to an approval workflow, pausing execution until an authorized human approves.

All traffic that passes through hoop.dev is recorded. The recorded session includes the exact commands sent, the responses received, and any masking that was applied. This audit trail satisfies internal security reviews and provides evidence for external audits. Because the recording happens outside the MCP server’s process, the server cannot tamper with the log.

Inline data masking is another key outcome. If a response from Entra contains personally identifiable information, hoop.dev can replace those fields with placeholder values before the data reaches the service. The service never sees the raw sensitive data, reducing the blast radius of a compromised service.

All of these enforcement outcomes, just‑in‑time access, approval gating, command blocking, masking, and session recording, are possible only because hoop.dev occupies the data path. The identity verification performed by Entra is necessary, but without hoop.dev the organization would still lack runtime enforcement.

Getting started

To implement this architecture, start with the official getting‑started guide. Deploy the hoop.dev gateway in the same network segment as your Entra‑protected resources. Register an Entra connection in the gateway configuration, supplying the service’s client ID and any required scopes. Then configure your MCP server to obtain an OIDC token from Entra and point its client library at the hoop.dev endpoint instead of directly at Entra.

The learn section provides deeper coverage of policy definition, approval workflows, and masking rules. Those pages show how to express the exact controls you need without writing any code in the MCP server itself.

FAQ

• Do I need to change my MCP server code? No. The server continues to use its standard client libraries; the only change is the endpoint it talks to, which becomes the hoop.dev gateway.
• Can I still use existing Entra client IDs? Yes. hoop.dev validates the token against Entra, so any client ID issued by Entra can be used as long as the token contains the required claims.
• What happens if the gateway is unavailable? Without the gateway the request cannot be authorized, so the service will receive an authentication error. This fail‑closed behavior protects the resource.

Explore the source code and contribute on GitHub.