An employee asks an assistant for a project document. The assistant connects to an MCP server, which queries a document service. There are several identities in that short path. The document service’s answer depends on which one it sees, not on the employee’s expectation of what “my access” means.
Map the identities in each request
In a hypothetical document search, identify the employee, the client application, the MCP server and the identity used for the downstream query. Does that query carry delegated user authority, or does a server account perform it? If it is a server account, where is the employee’s document access enforced?
A shared account may be appropriate for a deliberately limited public collection. It needs a different design for private project material. Make that decision explicit before indexing documents or enabling search. Otherwise, a successful integration test can hide the fact that every user is receiving the same broad view.
Check access after sign-in
The MCP project’s enterprise-managed authorization work addresses organizational control over access to MCP services. Use its current specification and provider support to assess the sign-in path. Admission to a server and permission to read a particular document are still different decisions.
For the fictional search service, record which component enforces project membership and how it receives the necessary identity. The design should explain both an allowed document result and a denied one without relying on the model to infer permissions.
Validate tokens for the intended service
MCP’s security guidance warns against token passthrough and requires attention to the intended audience of credentials. A server should not accept an unrelated token and forward it as though that established a valid authorization chain. Follow the documented flow for each participating service.
Keep credential values out of traces used to debug that flow. An operation identifier, the selected authorization path and a denial category can often explain the failure without retaining the token itself.
Apply access changes to saved results
Use two synthetic project collections with different memberships. Verify search results, source snippets and cached answers under each test identity. Then remove one identity’s access and repeat the request. A correct downstream denial is incomplete if an earlier cached answer still reveals the document.
The integration is ready for a broader trial when an engineer can explain whose authority reaches each hop, where a denial occurs and what happens when access changes. The protocol connection is one part of that explanation.