I recently became the systems administrator at a company where I previously worked in operations. I'm introducing stronger security practices, including access reviews, least privilege, Entra policies, device enrollment, Intune management, and better account and privileged-access controls. Previously, users were sometimes given excessive permissions by an external IT provider, including broad administrative roles.
A colleague is developing an internal business system with AI assistance. It runs in Azure and supports Microsoft sign-in for office staff, while field workers use separate accounts. The application was originally hosted in his personal Azure subscription, which was later transferred to the company environment. He currently has an owner role on the relevant Azure resources, but he often asks me for additional permissions or configuration changes based on instructions generated by an AI tool.
The problem is that he expects me to apply those instructions immediately and exactly as written. I prefer to understand the change, assess its impact, document a plan, test it safely, and then implement it. For example, he previously suggested being given Global Administrator access so he could resolve issues himself, without considering least privilege or the wider impact on the tenant.
An external auditor has also suggested implementing additional Azure firewall and security controls, and I'm concerned that my colleague will pressure me to make those changes quickly without properly reviewing the architecture and requirements. Am I right to insist on a review and change-management process, and how should I handle the situation without appearing to block his work?
5 Answers
You are absolutely right to review changes before applying them. AI output is a proposal, not an approval or a substitute for understanding the environment. Treat requests for permissions and configuration changes as formal change requests: document the purpose, scope, risks, required access, rollback plan, testing approach, and approval. Test in a non-production environment wherever possible, then schedule the production change.
Also, do not grant Global Administrator merely because it is convenient. Ask what specific task requires elevated access and provide the narrowest role or temporary elevation that will accomplish it. If the request cannot be explained clearly, it is not ready to implement.
Set up a simple change-control process and make it apply to everyone, including developers and senior staff. A short request form or ticket can ask what is changing, why it is needed, who approved it, what could be affected, and how it will be reversed. This makes the process about protecting the business rather than personally saying no.
You should also speak with your manager or the owner and get explicit backing for the process. Explain that you want to support the new system while managing security and operational risk. Follow up important conversations in writing with a neutral summary so there is a record of the decision and who approved it.
Presenting it as a way to support the project safely is probably better than framing it as a conflict between security and development. Management needs to understand both the business value and the risks.
Be especially careful with application registrations, API permissions, secrets, and service principals. An AI-generated setup may request broad permissions such as Mail.Read.All or other tenant-wide access without explaining the consequences. Use narrowly scoped permissions, store secrets in an appropriate vault, keep them out of source code and AI prompts, and review where logs and credentials are being sent.
A developer’s request for Global Administrator access is a warning sign, not evidence that the access is necessary. Separate the application’s needs from the developer’s personal access, and use temporary, auditable elevation when elevated access is genuinely required.
Ask the colleague to explain the requested change, its business purpose, and why the proposed approach is preferable to safer alternatives. If he cannot explain it well enough for you to assess, it should not be deployed yet. Use a development or test environment first and require a clear approval before production changes.
You can say: “I’m happy to help with this, but I need to review the impact and document the change before applying it. That protects the company and makes sure we can undo it if something goes wrong.” This is a normal administrative responsibility, not being slow or obstructive.
Make sure leadership understands that security controls can create friction, but uncontrolled access and undocumented changes create much larger risks. If management decides to accept a particular risk or bypass the process, record that decision and who authorized it. You should not quietly absorb responsibility for changes you were pressured into making.
The goal is not to stop AI-assisted development. The goal is to put normal review, testing, least privilege, and accountability around it.
That makes sense. My concern is that he sometimes stands at my desk asking for access immediately, which makes it difficult to pause and evaluate the request properly.