A developer registers an MCP server in Copilot Studio that exposes tools for reading and writing to a company's project management system. The MCP server uses OAuth 2.0 with scopes: 'projects.read' for read operations and 'projects.write' for write operations. The agent should only be able to read project data, never create or modify projects. How should the OAuth scopes be configured during MCP server registration?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Scopes are the authorization server's promise — if you only ask for the read scope, the token you get literally cannot be used for writes. Application logic restrictions can be bypassed; scope restrictions cannot. Always request the minimum necessary scopes at the token level.
Full explanation below image
Full Explanation
OAuth 2.0 scopes define the permissions granted to an access token at the authorization server level. When the agent authenticates against the OAuth server during MCP registration, it requests specific scopes in the authorization request. The authorization server issues a token that contains only those requested scopes — no more, no less. A token issued with only projects.read cannot perform write operations even if the MCP server's tools technically support write operations, because the server validates the token's scope before executing any action.
The security principle of least privilege dictates that applications should request only the permissions they actually need. By requesting only projects.read, the agent's token is constrained at the authorization layer — this is cryptographically enforced, not just a convention. Even if an agent topic or a malicious input tried to invoke a write tool, the MCP server would reject the request with an insufficient scope error.
Option A is incorrect and violates least-privilege security principles. Requesting projects.write and then trying to restrict it through topic logic is a defense-in-depth failure — application logic can have bugs, be bypassed, or be modified. The authorization server is a more reliable enforcement point.
Option B is technically correct in its stated action (only request projects.read) but is distinct from option C only in framing — however, option C adds the critical security reasoning about why this matters: token-level vs application-logic restriction. In the exam context, the option that explains the security rationale correctly is preferred.
Option D is incorrect because the MCP server is a single deployed endpoint — registering it twice with different scope configurations creates unnecessary complexity and management overhead. Scope selection at registration time handles this cleanly with a single registration.
Exam tip: Scope restrictions are enforced by the authorization server and embedded in the token — they cannot be overridden by the application. This is why minimal scopes are the correct security design, not a nice-to-have.