Session Access Control for Azure Logins

“Allow users to restrict an az login session to one resource group or resource **Related command** `az login` Suggested syntax below is illustrative, not an existing option. **Is your feature request related to a problem? Please describe.** My Azure user has legitimate access to several resource groups, including production systems. When working on development, I would like that specific login session to only have access to the development group. This would be useful for ordinary terminal work, scripts, automation and agents. My account needing production access does not mean every work session I have needs it. Read-only mode does not solve this. I need to write within the selected group, AND prevent reads of sensitive resources outside it. **Describe the solution you'd like** Could `az login` let a user voluntarily narrow their existing permissions for one session, without administrator collaboration or changes to their normal role assignments? For example: ```bash az login --restrict-to \ "/subscriptions/<subscription-id>/resourceGroups/development" ``` Then ordinary commands would behave like this: ```bash # Allowed if my user already has the required permissions. az storage blob upload \ --account-name devstorage \ --container-name test \ --name example.txt \ --file ./example.txt \ --auth-mode login # Blocked because production is outside this session's scope. az group show --name production # Also blocked. az group delete --name production ``` Resource-group scoping would already take us pretty far. Ideally, the same approach could allow selecting an individual resource within a group. The restriction should be tied to the session's credentials and enforced by Azure. Changing command arguments, configuration or using the token directly should not bypass it. It should only reduce existing access, never grant additional permissions. **Describe alternatives you've considered** * A separate identity with scoped RBAC. That can work, but requires provisioning another identity and permission assignments rather than simply narrowing my current login. * Storage SAS tokens. Useful for specific storage tasks, but not a general solution for Azure resource management. * Default resource groups, shell wrappers and instructions to agents. These help avoid mistakes, but do not restrict what the credentials can access. **Additional context** This is a general CLI safety feature, not specifically an agent identity or MCP request. Agents are one use case where limiting the consequences of mistakes matters. The restricted workflow should not silently fall back to unrestricted credentials. Other broad credentials accessible on the machine would still need to be kept away from the script or agent. I am not sure whether Azure's existing authorization APIs support this. Could someone familiar with CLI authentication clarify whether it is feasible today, or which underlying Azure capability would be needed? Related: [\#32974, global read-only mode](https://github.com/Azure/azure-cli/issues/32974). This request differs because it allows writes within the selected scope while also blocking sensitive reads outside it. ”