All posts

Audit logging for MCP servers on Entra

How can you guarantee complete audit logging for MCP servers when users authenticate through Entra? Most organizations let engineers obtain an OIDC token from Entra and then point their client directly at an MCP server. The token proves who the caller is, but the request bypasses any central point that could observe what is sent, what responses contain, or whether a command should have been allowed. Logs end up in the server’s local files, in the client’s console, or in a scattered set of cloud

Free White Paper

K8s Audit Logging + Single Sign-On (SSO): The Complete Guide

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

Free. No spam. Unsubscribe anytime.

How can you guarantee complete audit logging for MCP servers when users authenticate through Entra?

Most organizations let engineers obtain an OIDC token from Entra and then point their client directly at an MCP server. The token proves who the caller is, but the request bypasses any central point that could observe what is sent, what responses contain, or whether a command should have been allowed. Logs end up in the server’s local files, in the client’s console, or in a scattered set of cloud‑native observability tools. Correlating those fragments into a single audit trail becomes a manual, error‑prone effort.

Entra’s strength is identity federation. It issues short‑lived tokens, enforces MFA, and can embed group membership. Those tokens decide who may start a session, but they do not enforce what happens after the session begins. The request still reaches the MCP server directly, with no opportunity to record each query, mask sensitive fields, or require a human approval step.

To turn that identity into a verifiable audit trail, you must add an intervening control layer.

Why audit logging matters for MCP servers

MCP servers often host internal APIs, data transformation pipelines, or model‑inference endpoints. A single rogue query can expose proprietary prompts, leak training data, or trigger costly downstream processing. Auditors and incident responders need to see exactly who issued each request, what parameters were supplied, and what response was returned. Without a reliable audit logging mechanism, investigations stall, compliance evidence is incomplete, and the organization bears unnecessary risk.

The missing enforcement layer

The current setup provides three essential pieces: an Entra‑issued identity, a network path to the MCP server, and a server‑side logger. What it lacks is a place where policy can be applied consistently, regardless of client language or operating system. The enforcement layer sits between the identity and the target and inspects, records, and, if needed, alters every byte of traffic before it reaches the server.

Continue reading? Get the full guide.

K8s Audit Logging + Single Sign-On (SSO): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

How hoop.dev provides audit logging

hoop.dev inserts a Layer 7 gateway between Entra identities and the MCP server. The gateway runs an agent inside the same network segment as the server, holds the server’s credential, and terminates the client’s TLS session. When a user presents an Entra token, hoop.dev validates the token, extracts the user’s groups, and then forwards the request to the MCP server through the agent.

Because the request passes through the gateway, hoop.dev can record every command, the exact payload, and the full response. hoop.dev records each session as an audit log that includes the Entra user ID, timestamp, and enrichment such as the originating IP address. The gateway never exposes the server credential to the client, so the agent cannot be coerced into leaking it.

Key enforcement outcomes

  • Full session capture: hoop.dev records each interaction, providing a complete replayable log for forensic analysis.
  • Identity‑bound evidence: every audit entry is tied to the Entra user who initiated it, satisfying the need for non‑repudiation.
  • Real‑time visibility: administrators can stream audit logs to SIEMs or monitoring dashboards as soon as a request is made.
  • Policy hooks: the gateway can be configured to require just‑in‑time approval for high‑risk commands before they are forwarded.

These outcomes appear only because hoop.dev occupies the data path. Without that placement, Entra’s token would remain a proof of identity, but no system would have the authority to log, mask, or block the traffic.

Getting started

Begin by reviewing the getting‑started guide. It walks you through deploying the gateway with Docker Compose, registering an MCP server as a connection, and configuring Entra as the OIDC provider. The learn section contains deeper explanations of audit logging, session replay, and policy configuration.

FAQ

Do I need to change my existing MCP client?

No. The client continues to use its standard protocol (HTTP, gRPC, etc.). The only change is that it points to the hoop.dev endpoint instead of the server’s raw address.

Will audit logs be stored in my cloud provider?

hoop.dev records each session in an audit log that can be exported to the analysis tools or storage solutions you already use.

Can I still use Entra conditional access?

Yes. Entra continues to enforce MFA, device posture, and other conditional rules before the token reaches hoop.dev. The gateway then adds the audit layer on top of those existing controls.

Explore the source code and contribute on GitHub.

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