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?

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 the token containing only those requested scopes — no more, no less. The 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' in the OAuth configuration during MCP server registration, the agent's token is constrained at the authorization layer — this is cryptographically enforced, not just convention. Even if an agent topic or malicious input tried to invoke the write tool, the MCP server would reject the request with an insufficient scope error. The question is testing where the restriction is enforced, not merely which scope string is requested; a configuration that merely requests the read scope without ensuring the authorization server issues a token constrained to that scope would not satisfy the requirement. The requirement is that the agent never create or modify projects, so the correct configuration is to request only the 'projects.read' scope in the OAuth configuration during MCP server registration, ensuring the token the agent receives grants only read access at the authorization server level — not just at the application logic level. Requesting both 'projects.read' and 'projects.write' scopes during registration and then trying to restrict write access through agent topic logic is wrong because it violates least privilege. The token would carry write permission, and application logic can have bugs, be bypassed, or be modified. The authorization server is the more reliable enforcement point. Requesting 'projects.read' during registration and then having the agent request 'projects.write' at runtime when a user asks for changes is also wrong because it expands the token's permissions beyond the required read-only boundary; once write scope is granted, the agent can perform write operations, which conflicts with the requirement. Registering separate MCP server entries — one with 'projects.read' and one with 'projects.write' — and enabling only the read-only entry in the agent is wrong because the MCP server is the 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 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 nice-to-have.