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.
