More a thought rather than anything else… however, if you are still trying to unnecessarily restrict your developers, think again.
But governance! Compliance! Regulators!
All valid points, which will inhevitably lead to the same conclusion - unnecessarily restricting developers will only cause them to circumvent your restrictions.
When I say unnecessarily restricting I don’t mean not allowing unfettered production access or similar, to the contrary.
I am of the opinion that anything non-production needs to be as streamlined and light touch as possible. If you are not allowing your developers space to experiment, try out new ideas, innovate and chart the future. Telling them that they cannot use a certain tool, or they need to strictly stick to the User Stories rather than recording spikes and explorations will lead to them getting around your limitations (before leaving for another organisation, that is).
Do you want an extreme example? Have you ever considered that an Azure DevOps Agent Pool is a free hosting service for pretty much anything a disgruntled developer might want to test? Even better - if you lock everything down client-side and then you let a developer use a Microsoft-hosted Pool you are giving said developer access to a serverless compute platform. How long would you think it’s going to take a good engineer building scripts running in pipelines that can be invoked via the Azure DevOps APIs? BYOA (the A stands for API 😊)
There are ways of constructively channelling developer creativity and ingenuity, in 2024 it’s not just a nice to have - it’s very much a requirement to let your developers be developers.