Record Per-Client MCP Consent

Consent to one MCP client is not consent to every client that can reach the same server. A user may approve a desktop assistant to read project status but not a hosted agent to export files. Record the client identity and approved scopes as an authorization decision that the server can enforce.

The MCP security guidance discusses a confused-deputy pattern in authorization flows. The practical question for an operator is whether the consent screen names the actual client, the exact resource, and the requested permissions. A generic "connect" button can hide a wider grant than the user intended.

Consent record

Do not take a client name from the model prompt as proof of identity. Bind consent to the authorization server's registered client information. Show the user the same client and scopes the server will later see. If the client changes its callback, requested scope, or owner, treat that as a reason to review consent again, not as a silent update.

Exercise changed-client cases

In an owned authorization lab, approve a read-only client and call a permitted tool. Then use a different client identity with the same user, and require a new decision or denial. Increase the scope request to a write permission and confirm that the old read consent does not authorize it. Revoke the grant and verify new tool calls fail after the stated propagation interval.

Keep consent records separate from tokens. The audit trail needs client ID, user, scope, decision, and time, not the raw bearer value. Test the visible consent text as well as backend enforcement: an accurate server check does not cure a misleading approval screen. A pending or failed consent must leave the tool unavailable. This is a product permission, not permission to test a third-party system.