Test MCP Trust
A package update can finish while the identity decision remains untested. Check the running client, not just the dependency inventory.
The destination is part of the repair
The Python SDK advisory, published 28 September, covers HTTP MCP clients using OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or deprecated RFC7523OAuthClientProvider, with legitimate credentials and untrusted server connections. That MCP server could redirect them. SDK-built servers, stdio clients and self-supplied tokens/headers are excluded.
Affected ranges: >=1.9.1, <1.30.0 and >=2.0.0a1, <2.2.0. First fixes: 1.30.0 and 2.2.0.
ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider also need the expected issuer=; replace the deprecated provider. Clear issuer-less registrations, or bind self-inserted records to their intended issuer. Possible untrusted-server contact warrants secret rotation and token revocation. Until upgraded, connect only to trusted MCP servers. No CVE or exploitation evidence is supplied.
Prove what the running application will do
The important distinction is between installing a dependency and accepting a deployed application. A new entry in a lockfile cannot demonstrate the destination selected by an already-running process. Give the application owner and identity owner a shared acceptance record, then make the operations handover usable by the next shift.
That record should connect the deployed build to its configuration and to a test result. In an authorised controlled test, show that an unexpected identity is rejected before a credential leaves the client, while the legitimate workflow still works. Keep the result specific to the tested process and environment. A generic scanner pass cannot answer that operating question.
Do not hide migration work inside the package-upgrade ticket. Show what happened to retained client information and whether unattended jobs resumed successfully. If an exposure assessment requires a separate credential response, record its owner and completion evidence separately from the installation result. Finishing the maintenance window is not proof that both jobs are complete.
These are BlackTree’s proposed acceptance checks, not a vendor-certified test plan. They call for evidence, not an unapproved test against someone else’s service.
Our earlier Argo CD MCP report concerns a separate server-side token boundary. Its fix does not repair this Python client issue. The useful comparison is the decision about which side of a connection is allowed to choose where authority flows.
