Review the query-parameter boundary of an MSP metadata allowlist

Source facts

MSP privileges can identify an endpoint by its path and optional query parameters. Without query parameters, a privilege covers every value on that path. Matching is case-insensitive. With defaultAccess set to Allow, an endpoint becomes deny-by-default when a privilege exists for that resource. For query-qualified rules, extra request parameters do not prevent a match. Microsoft positions these controls as defense in depth, not a primary isolation boundary. Microsoft Learn.

Applicability

Use this review when turning observed metadata traffic into a custom allowlist. Identify the actual operations needed by each application rather than approving a shared path name without its request context.

DSE recommendation

Review each permitted path together with the query conditions and default-access behavior. Have the application owner explain which requests should succeed and which should fail. Record why each privilege omits or includes query parameters. Keep the identity and role assignments alongside that decision so a narrowly written privilege is not evaluated in isolation from its callers.

Verification

On a controlled workload, exercise an intended request, a request for a different operation on the same path, and a request containing an additional parameter. Compare observed authorization with the written expectation. Investigate surprises before broadening the allowlist, and preserve sanitized request shapes rather than tokens or response secrets.

Official references

Microsoft Learn: Advanced configuration for MSP. Source reviewed September 9, 2026.