All posts

Approval workflows for MCP servers on Entra

Many assume that a single OIDC token from Entra is enough to safely launch an MCP server, but without approval workflows the token alone offers no runtime guardrails. Why the current model falls short In most teams, an engineer or an automated service obtains an Entra‑issued token and passes it directly to the MCP server. The token proves identity, but once the connection is established the server trusts every request until the session ends. There is no built‑in checkpoint that asks a human t

Free White Paper

Access Request Workflows + Approval Chains & Escalation: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Many assume that a single OIDC token from Entra is enough to safely launch an MCP server, but without approval workflows the token alone offers no runtime guardrails.

Why the current model falls short

In most teams, an engineer or an automated service obtains an Entra‑issued token and passes it directly to the MCP server. The token proves identity, but once the connection is established the server trusts every request until the session ends. There is no built‑in checkpoint that asks a human to approve a high‑risk operation, no record of who issued which command, and no way to intervene if a request looks suspicious. The result is a wide attack surface: a compromised credential can execute any command, and post‑mortem investigations lack the granular evidence needed for accountability.

The missing piece: a controllable data path

Entra provides the identity token and can enforce static scopes, but it does not sit on the traffic that flows to the MCP server. That gap means the request still reaches the target directly, without any opportunity for just‑in‑time checks, approval routing, or session capture. The identity layer alone is necessary, it tells the system who is asking, but it is not sufficient to guarantee that the request obeys policy before it touches the server.

hoop.dev as the enforcement gateway

hoop.dev inserts a Layer 7 gateway between the Entra token holder and the MCP server. Every request passes through this gateway, where hoop.dev can enforce approval workflows. When a request matches a policy that requires human sign‑off, hoop.dev pauses the operation, forwards the request to an approval queue, and only resumes execution after a designated approver grants permission. Because the gateway records each step, the system also produces an audit trail that ties every command back to the originating identity.

How approval workflows are applied

When a user or an AI‑driven agent initiates a connection, hoop.dev validates the Entra token, extracts group membership, and maps the identity to a policy set. If the policy flags the requested operation as high‑risk, such as deploying a new model, modifying runtime configuration, or accessing privileged data, hoop.dev triggers an approval workflow. The workflow presents a concise summary of the request to an approver, who can approve, deny, or request additional context. Only after approval does hoop.dev forward the command to the MCP server; otherwise the request is blocked and logged.

Continue reading? Get the full guide.

Access Request Workflows + Approval Chains & Escalation: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Benefits beyond the approval step

Because the gateway sits on the data path, hoop.dev can also record the full session for replay, mask sensitive fields in responses, and enforce command‑level blocking for known dangerous patterns. Those capabilities are available automatically once the gateway is in place, meaning the same Entra identity that started the session never sees raw credentials or unfiltered data. Teams gain consistent evidence for audits, reduced blast radius from compromised tokens, and a clear, auditable chain of custody for every privileged operation.

Getting started

To adopt this model, deploy the hoop.dev gateway in the same network segment as your MCP servers. Configure the gateway to trust Entra as the OIDC provider, register the MCP endpoint, and define the approval policies that match your risk appetite. The official getting‑started guide walks you through the Docker‑Compose deployment, the identity integration, and the policy definition workflow. For deeper technical details, consult the learning hub, which explains how to shape approval workflows, set up approver groups, and view recorded sessions.

FAQ

Do I need to change my existing Entra applications?

No. Entra continues to issue tokens as before. hoop.dev simply consumes those tokens and adds a runtime enforcement layer, so existing client configurations remain unchanged.

Can I use the same approval workflow for multiple MCP servers?

Yes. Policies are defined at the gateway level and can reference groups of servers, allowing a single approval workflow to cover any number of targets that share the same risk profile.

What happens if an approver is unavailable?

hoop.dev can be configured with fallback approvers or escalation paths. If no approver responds within the defined timeout, the request is automatically denied and logged, preserving a clear audit record.

Ready to tighten control over your Entra‑backed MCP servers? Explore the open‑source repository for the full codebase, contribution guidelines, and the latest releases.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts