I recently became the system administrator at a company where I previously worked in operations. I'm tightening security, reviewing access controls, reducing unnecessary global administrator privileges, auditing users and guests, moving devices to Entra ID and Intune, and working toward replacing an external IT provider.
A colleague is building an internal business application with AI assistance. It runs in Azure, uses Microsoft accounts for office staff, and has separate accounts for field workers. The application was originally created in his personal Azure subscription and later transferred to the company environment. He currently has an owner role for the relevant Azure resources, while I manage the broader tenant and security controls.
The problem is that he frequently comes to me with instructions generated by an AI assistant and expects me to implement them immediately. He often does not explain the wider context or allow time to assess the security and operational impact. For example, he previously wanted immediate global administrator access during the subscription transfer, even though I was trying to follow least-privilege principles and document the process.
An external auditor has now suggested implementing additional firewall and Azure security controls. I'm concerned that the developer will again expect these changes to be made immediately based solely on AI-generated instructions. I believe changes should be reviewed, documented, tested in a non-production environment, and then implemented through a change-management process. Am I approaching this correctly, and how should I communicate and enforce that process without becoming an unnecessary bottleneck?
5 Answers
You are absolutely right to pause and understand the impact before making security or access changes. AI can suggest options, but it does not know your complete environment, business requirements, existing dependencies, or risk tolerance.
Set up a basic change-management process. Requests should explain what is being changed, why it is needed, what resources are affected, what permissions are required, how it will be tested, how it can be rolled back, and who approved it. Changes should be evaluated in a test environment before production whenever possible.
For access requests, especially administrator access, use just-in-time or temporary elevation where available instead of granting permanent global administrator privileges.
Do not handle this as a conflict between you and the developer. Take it to your manager or the business owner and frame it as a balance between supporting the application and managing security risk.
Explain that you want to help the project move quickly, but need management to approve the process for privileged access, production changes, testing, and emergency requests. Follow up important conversations in writing with a neutral summary so there is a record of the decision and who accepted the risk.
Management may decide that speed is more important than your preferred controls, but that decision should come from the people who own the business risk—not be made informally at your desk.
I’ll try to present it as a way to support the project safely rather than as me blocking him. Getting clear backing from management will probably make the process much easier to enforce.
A short request form does not need to become bureaucracy. Even a ticket with the change description, business reason, affected systems, requested permissions, test plan, rollback plan, and approval is a major improvement.
For urgent work, define an emergency procedure with a limited time window, an approver, and a required post-change review. That lets the business move quickly when necessary without turning every request into an untracked production change.
Pay particular attention to application permissions and secrets. If the system needs to read mail, send mail, access files, or call Microsoft APIs, verify that permissions are narrowly scoped. Broad permissions such as Mail.Read.All can expose a large amount of company data.
Make sure secrets, certificates, and API keys are stored in an approved secret-management service and are not pasted into AI tools, source repositories, or configuration files. Review app registrations, service principals, consent grants, logging, and the separation between development and production. A developer should not need permanent tenant-wide administrator access just to build or maintain an application.
Ask him to explain the proposed change and the reason for choosing it. If he cannot describe what it does, what it affects, and how it will be tested, it should not go into production.
A useful response is: “That may be a valid approach, but I need the request documented and reviewed before I make the change.” This is not refusing to help; it is protecting the company and making sure the person responsible for the environment understands what is being changed.
You can also use the audit requirement as an objective reason for following the process. Access approvals, administrative actions, code changes, and infrastructure changes should all be documented in an auditable environment. That gives you a firm standard rather than making the issue personal.
That makes sense. My concern is that he sometimes stands at my desk asking me to grant access immediately, which makes it difficult to carry out a proper review. I need to make the process clear before the next request comes up.