Least-privilege access for MCP servers on Entra

How can you make sure an MCP server that authenticates with Entra only receives the permissions it truly needs, achieving least-privilege access?

Today many organizations let a service identity inherit a broad set of Azure AD or Entra groups. The token presented to the MCP server often contains claims for dozens of applications, storage accounts, and internal APIs. From a compliance perspective that violates the principle of least‑privilege, and from an operational standpoint it expands the blast radius of a compromised server. Engineers typically rely on Entra to decide who may start a connection, but the request then travels straight to the MCP endpoint without any additional guardrails. The result is a blind spot: no real‑time audit of what the server does, no way to hide sensitive response fields, and no opportunity to pause a dangerous command for human review.

Why least-privilege access matters for Entra‑backed MCP servers

Entra excels at issuing tokens that prove an identity’s membership in groups. However, the token itself does not enforce fine‑grained access to the resources the server will touch. When a server connects to an MCP endpoint, it can issue queries, run code, or retrieve logs that contain personally identifiable information or proprietary secrets. If the server is compromised, an attacker inherits every permission encoded in the token. Organizations that aim to meet regulatory expectations or simply reduce risk need a mechanism that trims those permissions down to the exact operations required for a given task.

Least‑privilege access means that the server’s effective rights are scoped to the minimum set needed for the current job. It also implies that any deviation, such as a request to delete a database or export a large data set, should be visible, controllable, and, when appropriate, require explicit approval. Achieving that level of control cannot be done by identity alone; it requires an enforcement point that sits between the token‑bearing identity and the MCP service.

The missing enforcement layer

The current setup provides a solid foundation: Entra issues a signed OIDC token, and the MCP server trusts that token to start a session. That is the setup phase, where identity, group membership, and non‑human service accounts are defined. What remains missing is a data‑path where policies can be evaluated for each request. Without that gateway, the request reaches the MCP server directly, meaning:

• No audit trail that ties a specific command to the originating identity.
• No inline masking of sensitive fields in responses.
• No just‑in‑time approval workflow for high‑risk operations.
• No ability to block dangerous commands before they execute.

Those enforcement outcomes are essential for true least‑privilege, yet they cannot be guaranteed by Entra alone. The enforcement must happen where the traffic flows, not merely at the token verification step.

Introducing hoop.dev as the data‑path gateway

hoop.dev sits between the Entra‑authenticated identity and the MCP server, acting as a Layer 7 gateway that inspects every protocol message. Because hoop.dev is positioned in the data‑path, it can enforce policies that the setup cannot.

hoop.dev records each session, creating a replayable audit log that links every command back to the originating Entra identity. hoop.dev masks sensitive fields in real time, ensuring that downstream logs or displays never expose secrets. hoop.dev enforces just‑in‑time approvals, pausing high‑risk operations until an authorized reviewer grants permission. hoop.dev blocks dangerous commands before they reach the MCP server, preventing accidental or malicious misuse.

All of these outcomes exist only because hoop.dev occupies the data‑path. The Entra token still decides who may start a connection, but hoop.dev decides what that connection is allowed to do.

How the flow works

When an MCP server initiates a connection, it presents an OIDC token issued by Entra. hoop.dev validates the token, extracts group claims, and matches them against a policy that specifies which MCP commands are permissible for that identity. If the request is within the allowed set, hoop.dev proxies the traffic to the MCP endpoint. If the request involves a privileged operation, hoop.dev routes it to an approval workflow; the operation proceeds only after an authorized reviewer approves. Throughout the session, hoop.dev records each request and response, applying inline masking to any fields marked as sensitive in the policy.

This architecture satisfies the three required categories:

• Setup: Entra provides the identity and initial authentication.
• Data‑path: hoop.dev is the only place where policy enforcement occurs.
• Enforcement outcomes: session recording, inline masking, just‑in‑time approval, and command blocking are all delivered by hoop.dev.

By separating who can start a connection from what the connection may actually do, you achieve true least‑privilege access for MCP servers.

Getting started

To try this pattern in your environment, follow the getting‑started guide for deploying the gateway and registering an MCP target. The learn section provides deeper explanations of policy definition, approval workflows, and masking rules.

FAQ

Do I need to change my Entra application registration?

No. hoop.dev consumes the existing OIDC token, so you can keep your current Entra app registration. The gateway only adds a policy enforcement layer.

Will hoop.dev add latency to MCP calls?

Because hoop.dev operates at the protocol layer, the added latency is minimal and comparable to a typical reverse‑proxy, the security benefits usually outweigh the small performance cost.

Can I audit the recorded sessions for compliance?

Yes. hoop.dev stores a replayable log for every session, which can be exported and correlated with your compliance tooling.

Ready to see the code in action? Explore the open‑source repository on GitHub and start building a least‑privilege enforcement layer for your Entra‑backed MCP servers.