Many teams assume that giving an AI‑driven MCP server a static service‑account token is enough to keep the system safe, but that approach ignores the need for a non-human identity that can be audited. The reality is that a static credential provides no visibility into who or what is driving each request, and it cannot be revoked without a full rollout.
In practice, engineers often create a dedicated service account in Entra, export its client secret, and embed that secret in the MCP server configuration. The server then talks directly to the target resource – a database, a Kubernetes API, or an internal HTTP endpoint – without any gatekeeper in the middle. This approach satisfies the basic requirement of authentication, but it leaves three critical gaps: there is no real‑time audit of each command, no way to mask sensitive response data, and no ability to pause a risky operation for human review.
Why non-human identity alone is not enough
Switching to a non-human identity issued by Entra improves credential management. The MCP server can obtain an OIDC token on demand, and the token carries the service account’s group membership. However, the request still travels straight to the target resource. The data path remains uncontrolled, so the same audit, masking, and approval gaps persist. In other words, the identity layer decides *who* is making the request, but it does not enforce *what* the request may do.
Introducing a data‑path gateway
To close the gap, place a Layer 7 gateway between the non-human identity and the infrastructure. The gateway verifies the Entra token, then proxies the protocol‑level traffic to the target. Because the gateway sits in the data path, it can apply policy checks before any command reaches the backend.
hoop.dev records every session, storing a replayable log that auditors can query later. hoop.dev masks sensitive fields in responses, ensuring that downstream services never expose secrets to the MCP server. hoop.dev enforces just‑in‑time approvals, routing high‑risk commands to an approver before they are executed. hoop.dev blocks dangerous commands outright when a policy dictates that they are prohibited.
Architectural flow
1. Deploy the gateway using the quick‑start Docker Compose or a Kubernetes manifest. The deployment includes an agent that runs inside the same network as the target resource.
2. Register Entra as the OIDC provider in the gateway configuration. The gateway becomes the relying party, validates incoming tokens, and extracts group claims.