What should an MCP permission review check?
Review the identity that executes each tool, its effective resource permissions, and the operations the workflow actually needs. For Azure MCP Server, Microsoft recommends narrowly scoped roles and limiting exposed tools. Use authorized tests to check allowed and denied actions, then preserve the result as evidence.
A tool name describes an interface. It does not establish the full authority available to the identity behind it. Start an assessment by making that relationship visible.
Map the executing identity
Microsoft explains that Azure MCP Server reflects the caller’s Azure permissions. Its guidance recommends narrow role assignments and enabling only needed tools. Review both the tool surface and the effective resource permissions.
For an illustrative inventory assistant, ask why a read task would need a role that can change the same resources. Record the intended boundary before deciding what to test.
Make denial observable
My proposed review method pairs an expected allowed action with an explicitly out-of-scope action in an authorized test environment. Agree on the expected decision first. Preserve the caller context, requested operation, target, and observed result without recording credentials.
An allowed operation confirms one path works. A recorded denial helps explain where the boundary holds. Neither result establishes coverage for every possible operation.
Keep the review current
Link the observations to the reviewed tool configuration and permission policy. Revisit the checks when either changes. The useful deliverable is a boundary another engineer can understand and verify, with unknowns written down.
This note presents general engineering guidance and illustrative examples. Review the linked reference for its specific scope and current details.