Forum Discussion
What are the recommended guardrails for...
Preventing the agent from making changes to any Azure resource?
Companies who have heard stories about hallucinations, etc. believe that the agent is a threat their production systems potentially.
From what I can tell, the agent can be given a managed identity that has limited rights to Azure resources. Read/list, etc.
Without guardrails, adoption of this tech will be difficult in some environments.
"But the hallucinations..."
I'm not sure it's a great idea to let an agent make changes to a production system... or even suggest doing it "for" the benefit of the on-call. It's too easy to screw up.
What is the guidance here? Managed identity with RBAC?
1 Reply
Hi,
A few guardrails tend to work well across most Azure environments, especially when multiple teams share the same platform.
✔️ 1. Start with a clear landing‑zone structure
Use Management Groups to separate:
- platform
- shared services
- workloads
- sandboxes
This gives you a clean place to apply policies and RBAC.
✔️ 2. Enforce governance with Azure Policy
Typical baseline policies include:
- allowed locations
- allowed SKUs
- mandatory tags
- diagnostic settings to Log Analytics
- resource locks for critical assets
- network rules (no public IPs unless approved)
✔️ 3. Use RBAC with least privilege
Define roles per persona:
- platform admins
- workload owners
- developers
- automation accounts
Avoid using Owner except for platform teams.
✔️ 4. Control cost and sprawl
Set:
- budgets + alerts
- quotas
- lifecycle policies for unused resources
- automation to clean up abandoned assets
✔️ 5. Standardize deployment
Use:
- Bicep/Terraform modules
- Azure DevOps/GitHub Actions
- environment‑based pipelines
- policy‑driven validation before deployment
This keeps teams aligned and prevents configuration drift.
If you can share your current structure (MGs, subscriptions, teams), I can suggest a more tailored baseline.
