Connecting an assistant to an MCP server introduces an access path between the assistant, the server, and any business systems behind it. Authentication at one point in that path does not automatically establish authorization at every other point. The server has to know which identity is calling, what the credential was issued for, and which operation is permitted.
Model Context Protocol standardizes how clients discover and use capabilities. A security review still needs to examine the particular server, its tools, and the identity flow used by that deployment.
Audience is part of credential validation
An access token can be correctly signed and unexpired while being intended for a different service. Accepting it without checking its intended resource can break the boundary between services. The MCP security guidance addresses token passthrough and requires appropriate token validation rather than treating an upstream token as universally usable. The protocol's security practices describe these risks.
In an illustrative document connector, the assistant authenticates to an MCP server that then calls a storage provider. These are distinct relationships. The server's authority to serve the assistant and its delegated authority to read a storage account need explicit handling, even if the interface presents them as one connection.
Tool discovery also needs an ownership model
Record who operates the server, where it runs, and who can change its tool definitions. A tool description tells the assistant how to use an operation; it is not a security policy that the downstream service can rely on. A renamed or newly expanded tool may expose different business capabilities.
For local servers, installation permissions and process access are relevant. For remote servers, credential storage, tenant separation, and outbound requests are relevant. The assessment scope can identify these differences without assuming that every MCP integration uses the same hosting or authentication design.
Test wrong-resource and wrong-user cases
In a controlled environment, exercise a token intended for another resource, an expired credential, and a credential belonging to another test user. Confirm that rejection happens before any business data is returned or modified. Avoid putting complete tokens in the report; retain non-secret identifiers and sanitized validation results.
Next, connect two test customer accounts and request a resource from the other account. A server that validates token format correctly may still select the wrong stored downstream credential. This is a tenant-binding problem, and it requires a different fix from signature or expiration validation.
Evidence for a connector review
The review can produce an identity-flow diagram, a list of tool capabilities, the accepted token issuers and audiences, and results for denied requests. Also document disconnect behavior: which grants are revoked, which credentials are removed, and whether existing sessions continue.
These records help a business distinguish a protocol-compatible connection from an integration whose access boundaries have been verified. The result is specific to the tested server version and configuration, so material changes to its tools or identity flow require renewed review.
Sources
OWASP: MCP Security. The document connector is illustrative; deployment-specific requirements depend on the protocol version and transport in use.
