Update security_best_practices.mdx

Author: localden

docs/specification/draft/basic/security_best_practices.mdx

@@ -124,15 +124,15 @@ registered client before forwarding to third-party authorization servers (which
 Token passthrough is explicitly forbidden in the [authorization specification](/specification/draft/basic/authorization) as it introduces a number of security risks, that include:
 
 - **Security Control Circumvention**
-  - The MCP Server or downstream APIs might implement important security controls like rate limiting, request validation, or traffic monitoring, that depend on the token audience or other credential constraints. If clients can obtain and use tokens directly with the downstream APIs without the MCP server validating them properly or ensuring that the tokens are issued for the right service, they bypass these controls. Service-specific tokens may be accepted by unintended services because no proper validation was performed.
-  - If the MCP Server passes tokens without validating their claims (e.g., roles, privileges, or audience) or other metadata, a malicious or compromised user can craft a token with elevated privileges and use the server as a proxy for data exfiltration.
-  - If the token is accepted by multiple services without proper validation, an attacker compromising one service can use the token to access other connected services.
+  - The MCP Server or downstream APIs might implement important security controls like rate limiting, request validation, or traffic monitoring, that depend on the token audience or other credential constraints. If clients can obtain and use tokens directly with the downstream APIs without the MCP server validating them properly or ensuring that the tokens are issued for the right service, they bypass these controls.
 - **Accountability and Audit Trail Issues**
   - The MCP Server will be unable to identify or distinguish between MCP Clients when clients are calling with an upstream-issued access token which may be opaque to the MCP Server.
-  - The downstream Resource Server's logs will show requests coming from client IDs that might not match the actual identity of the MCP server that is proxying the tokens.
+  - The downstream Resource Server’s logs may show requests that appear to come from a different source with a different identity, rather than the MCP server that is actually forwarding the tokens.
   - Both factors make incident investigation, controls, and auditing more difficult.
+  - If the MCP Server passes tokens without validating their claims (e.g., roles, privileges, or audience) or other metadata, a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration.
 - **Trust Boundary Issues**
   - The downstream Resource Server grants trust to specific entities. This trust might include assumptions about origin or client behavior patterns. Breaking this trust boundary could lead to unexpected issues.
+  - If the token is accepted by multiple services without proper validation, an attacker compromising one service can use the token to access other connected services.
 - **Future Compatibility Risk**
   - Even if an MCP Server starts as a "pure proxy" today, it might need to add security controls later. Starting with proper token audience separation makes it easier to evolve the security model.