When a contract software vendor finishes their engagement, the engineering team often leaves a service account with broad permissions that still points at the internal MCP endpoint. The account can issue queries, trigger pipelines, or even spawn new AI agents, all without any recent human sign‑off. Weeks later, a security analyst discovers that the same token was used to extract customer data during a routine audit. The root cause is not a broken firewall; it is the absence of a systematic access reviews process for the MCP environment.
Access reviews are periodic examinations of who can reach a system, what actions they may perform, and whether those privileges remain justified. In the context of MCP, the review must answer questions such as: which identities can invoke the built‑in LLM server, which service accounts can query the control plane, and whether any of those permissions exceed the principle of least privilege. Without a disciplined review cadence, stale tokens linger, over‑scoped roles accumulate, and the organization loses visibility into who touched which data.
Why access reviews matter for MCP
MCP acts as a central hub for AI‑driven workloads. It receives requests from human engineers, CI pipelines, and autonomous agents. Each request travels through the same network path, but the platform itself does not retain a native ledger of who asked for what. When an access review is performed manually, teams must cross‑reference IAM policies, service‑account keys, and audit logs that live in disparate locations. The effort is error‑prone and often incomplete, leaving blind spots that attackers can exploit.
What a typical setup looks like today
Most organizations rely on OIDC or SAML providers to authenticate users and service accounts. The identity provider supplies a token that the client presents directly to the MCP server. The server validates the token, extracts group membership, and then grants access based on static role bindings. This arrangement satisfies the setup requirement: it tells the system who the request is and whether it may start. However, the request still reaches the MCP target without any intermediate enforcement point. Consequently, there is no built‑in capability to record each command, mask sensitive fields in responses, or pause a request for human approval.
The missing enforcement layer
The gap is the data path. Without a gateway that sits between the identity layer and the MCP endpoint, the platform cannot enforce runtime policies such as:
- Recording every session for replay and forensic analysis.
- Applying inline masking to hide personally identifiable information in query results.
- Requiring just‑in‑time approval before executing high‑risk operations.
- Blocking commands that match known dangerous patterns.
These enforcement outcomes exist only when a dedicated proxy intercepts traffic. The proxy must be transparent to existing clients, support the same wire‑protocols, and enforce policies based on the identity information supplied by the IdP.