Advanced

Azure Best Practices & Checklist

This final lesson consolidates everything into an actionable Azure-specific checklist, covers management group hierarchies, Landing Zones, Blueprints, and emergency response procedures for AI agent incidents.

Complete Azure Guardrails Checklist

💡
Azure AI Agent Guardrails Checklist:
  • AI agents use Managed Identities, never service principal secrets or personal credentials
  • Custom RBAC roles exclude all */delete and destructive write actions
  • Deny assignments block delete operations for agent principals
  • PIM is configured for any elevated permissions with 1-hour max duration
  • CanNotDelete locks are applied to all production resource groups
  • ReadOnly locks are applied to critical networking and security resources
  • Azure Policy denies delete operations on critical resource types
  • Policy initiative groups all AI agent safety policies together
  • Activity Log alerts fire on all delete operations (succeeded and failed)
  • Log Analytics workspace collects Activity Logs with 90-day retention
  • Azure Backup is configured for all production VMs and SQL databases
  • Soft delete is enabled on all Recovery Services vaults (set to AlwaysOn)
  • Blob soft delete and versioning are enabled on all storage accounts
  • SQL point-in-time restore retention is set to maximum (35 days)
  • Emergency kill switch scripts are documented and tested quarterly
  • Conditional Access restricts agent authentication to approved networks

Management Group Hierarchy for Isolation

Azure Management Groups create a hierarchy above subscriptions, allowing you to apply policies and RBAC at different levels. For AI agent safety, structure your hierarchy to isolate agent access:

Recommended management group hierarchy
# Root Management Group
# ├── Platform
# │   ├── Identity (Azure AD, PIM)
# │   ├── Management (Monitoring, Log Analytics)
# │   └── Connectivity (Hub networking, DNS)
# ├── Landing Zones
# │   ├── Production (STRICT guardrails)
# │   │   └── sub-prod-001
# │   ├── Staging (Moderate guardrails)
# │   │   └── sub-staging-001
# │   └── Development (Minimal guardrails)
# │       └── sub-dev-001
# └── Sandbox (AI Agent Testing)
#     └── sub-sandbox-001

# Create management groups
az account management-group create --name "platform" --display-name "Platform"
az account management-group create --name "landing-zones" --display-name "Landing Zones"
az account management-group create --name "lz-production" --display-name "Production" --parent "landing-zones"
az account management-group create --name "lz-staging" --display-name "Staging" --parent "landing-zones"
az account management-group create --name "lz-development" --display-name "Development" --parent "landing-zones"
az account management-group create --name "sandbox" --display-name "Sandbox"

# Apply strict deny-delete policy at Production management group level
az policy assignment create \
  --name "deny-delete-production" \
  --policy "deny-delete-critical-resources" \
  --scope "/providers/Microsoft.Management/managementGroups/lz-production" \
  --enforcement-mode Default

Azure Landing Zones and Guardrails

Azure Landing Zones provide a prescriptive architecture with built-in guardrails. The Cloud Adoption Framework (CAF) Landing Zone accelerator includes many of the policies discussed in this course:

Landing Zone Component AI Agent Safety Benefit Implementation
Platform subscriptions Isolates management plane from workloads Agents cannot affect identity or networking infrastructure
Policy-driven governance Policies applied at management group level All subscriptions under a MG inherit policies automatically
Hub-spoke networking Network isolation between environments Agent in dev cannot reach production network resources
Centralized logging All activity logs in one workspace Single pane of glass for monitoring agent behavior

Subscription-Level Isolation: Dev/Staging/Prod

Golden Rule: AI agents should never have credentials that work across multiple environments. An agent working on development code should only have access to the development subscription. Use separate Managed Identities for each environment, each with appropriately scoped custom roles.
Creating environment-isolated agent identities
# Development agent identity - has Contributor minus delete
az identity create --name uai-agent-dev --resource-group rg-identities
az role assignment create \
  --assignee $(az identity show --name uai-agent-dev --resource-group rg-identities --query principalId -o tsv) \
  --role "AI Agent Safe Deployer" \
  --scope "/subscriptions/DEV-SUBSCRIPTION-ID"

# Staging agent identity - has Reader plus limited write
az identity create --name uai-agent-staging --resource-group rg-identities
az role assignment create \
  --assignee $(az identity show --name uai-agent-staging --resource-group rg-identities --query principalId -o tsv) \
  --role "AI Agent Safe Deployer" \
  --scope "/subscriptions/STAGING-SUBSCRIPTION-ID"

# Production - agent has Reader ONLY (no write, no delete)
az identity create --name uai-agent-prod --resource-group rg-identities
az role assignment create \
  --assignee $(az identity show --name uai-agent-prod --resource-group rg-identities --query principalId -o tsv) \
  --role "Reader" \
  --scope "/subscriptions/PROD-SUBSCRIPTION-ID"

Azure Blueprints for Standardized Environments

Azure Blueprints package role assignments, policy assignments, ARM templates, and resource groups into a single deployable artifact. Use Blueprints to ensure every new subscription automatically gets AI agent guardrails:

Blueprint definition with AI agent guardrails
{
  "properties": {
    "displayName": "AI Agent Safe Landing Zone",
    "description": "Blueprint that deploys a subscription with AI agent safety guardrails",
    "targetScope": "subscription",
    "parameters": {},
    "resourceGroups": {
      "rg-monitoring": {
        "name": "rg-monitoring",
        "location": "eastus"
      }
    },
    "blueprintId": "/providers/Microsoft.Management/managementGroups/landing-zones/providers/Microsoft.Blueprint/blueprints/ai-agent-safe-lz"
  },
  "artifacts": [
    {
      "kind": "policyAssignment",
      "properties": {
        "displayName": "Deny delete on critical resources",
        "policyDefinitionId": "/subscriptions/SUB/providers/Microsoft.Authorization/policyDefinitions/deny-delete-critical-resources"
      }
    },
    {
      "kind": "roleAssignment",
      "properties": {
        "displayName": "AI Agent Safe Deployer",
        "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/CUSTOM-ROLE-ID",
        "principalIds": ["[parameters('agentPrincipalId')]"]
      }
    },
    {
      "kind": "template",
      "properties": {
        "displayName": "Deploy resource locks",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "resources": [
            {
              "type": "Microsoft.Authorization/locks",
              "apiVersion": "2020-05-01",
              "name": "subscription-lock",
              "properties": {
                "level": "CanNotDelete",
                "notes": "Applied by AI Agent Safety Blueprint"
              }
            }
          ]
        }
      }
    }
  ]
}

Emergency Response Procedures

  1. Detect: Alert Fires

    An Activity Log alert detects a delete operation by an AI agent identity. The action group sends notifications to email, Slack/Teams, and PagerDuty simultaneously.

  2. Triage: Assess Severity (5 minutes)

    Determine if the deletion affected production, what resource types were impacted, and whether the agent is still active. Check if the operation succeeded or was blocked by policy/locks.

  3. Contain: Kill the Agent (1 minute)

    Run the kill switch script to disable the agent's Managed Identity. This immediately prevents further damage regardless of what commands the agent is executing.

  4. Recover: Restore Resources (30-120 minutes)

    Use Azure Backup, SQL PITR, blob undelete, or ASR failover to restore deleted resources. Follow the recovery procedures from the Backup & Recovery lesson.

  5. Review: Post-Incident Analysis (24 hours)

    Conduct a blameless post-mortem. Identify which guardrails were missing, update policies, strengthen RBAC roles, and apply additional locks as needed.

Azure emergency kill switch script
#!/bin/bash
# azure-kill-agent.sh - Emergency script to disable AI agent access
# Usage: ./azure-kill-agent.sh

set -e

echo "=== EMERGENCY: Disabling AI Agent Access ==="
echo "Timestamp: $(date -u +"%Y-%m-%dT%H:%M:%SZ")"

# Disable user-assigned managed identity
IDENTITY_NAME="uai-ai-agent"
IDENTITY_RG="rg-identities"

# Method 1: Remove all role assignments for the agent identity
PRINCIPAL_ID=$(az identity show \
  --name "$IDENTITY_NAME" \
  --resource-group "$IDENTITY_RG" \
  --query principalId -o tsv)

echo "Removing all role assignments for principal: $PRINCIPAL_ID"

az role assignment list \
  --assignee "$PRINCIPAL_ID" \
  --query "[].id" -o tsv | \
while read assignment_id; do
  echo "  Removing: $assignment_id"
  az role assignment delete --ids "$assignment_id"
done

# Method 2: If using a service principal instead
# az ad sp update --id "$SP_OBJECT_ID" --set accountEnabled=false

echo ""
echo "=== Agent access has been revoked ==="
echo "Next steps:"
echo "  1. Check Activity Log for any recent destructive operations"
echo "  2. Run recovery procedures if needed"
echo "  3. File an incident report"
echo "  4. Schedule a post-incident review"

Frequently Asked Questions

Can Azure Policy completely prevent AI agents from deleting resources?

Yes, when configured correctly. Azure Policy with the DenyAction effect can block delete operations at the ARM layer, which means no CLI command, Terraform operation, or API call can bypass it. However, you need to ensure the policy covers all resource types you want to protect, and that the policy assignment scope covers all relevant subscriptions. Policy exemptions should be time-limited and require human approval.

What is the difference between resource locks and Azure Policy for deletion prevention?

Resource locks are applied to specific resources and prevent deletion regardless of who attempts it (even Owners). Azure Policy defines rules that apply to operations across a scope (subscription, management group). Use both together: locks protect individual critical resources, while policy provides broad organizational rules. The key difference is that locks must be explicitly removed before deletion, while policy exemptions can be created for authorized deletions.

Should I use system-assigned or user-assigned Managed Identities for AI agents?

Use user-assigned Managed Identities for AI agents in most cases. User-assigned identities are independent resources that can be shared across multiple compute resources and have a lifecycle independent of the VM or container. This makes it easier to manage permissions centrally, rotate the identity, and apply consistent RBAC across all agent compute resources. System-assigned identities are better when the agent runs on a single dedicated VM.

How do I handle Terraform state when AI agents use Terraform with Azure?

Store Terraform state in Azure Blob Storage with the following protections: (1) Enable blob versioning and soft delete on the storage account, (2) Apply a CanNotDelete lock on the storage account, (3) Use Azure AD authentication for state access (not storage keys), (4) Enable state file locking via Azure Blob lease, and (5) Set the Terraform backend configuration to use the azurerm backend with use_azuread_auth = true. Never let the AI agent run terraform destroy or terraform apply directly - use CI/CD pipelines with approval gates.

What is the minimum setup for a small team starting with AI agents on Azure?

At minimum: (1) Create a user-assigned Managed Identity with a custom role that has */read and specific */write actions but */delete in NotActions, (2) Apply CanNotDelete locks on your production resource group, (3) Enable blob soft delete and SQL PITR (both free or near-free), (4) Create one Activity Log alert for delete operations with email notification. This takes about 30 minutes and prevents the vast majority of accidental deletion scenarios.

How do I audit what my AI agent is doing in Azure?

Azure Activity Log automatically records every ARM operation, including the caller identity, operation name, status, and timestamp. Send Activity Logs to a Log Analytics workspace for long-term retention and KQL queries. Use the KQL examples from the Monitoring & Alerts lesson to track agent-specific activity. For a quick check, use: az monitor activity-log list --caller AGENT-PRINCIPAL-ID --offset 24h

Can I use Azure Blueprints to standardize guardrails across all subscriptions?

Yes, Azure Blueprints are ideal for this purpose. Create a Blueprint that includes your custom RBAC role definition, policy assignments (deny-delete, require tags), ARM templates for resource locks, and a Log Analytics workspace for monitoring. Assign the Blueprint at the management group level so every new subscription automatically inherits all guardrails. Note that Azure is transitioning some Blueprint functionality to Deployment Stacks - consider using both during the transition period.

Course Complete: You now have a comprehensive understanding of Azure-specific guardrails for AI agents. Start with the minimum viable setup (custom RBAC role + resource locks + Activity Log alerts + blob soft delete), then progressively add Azure Policy, PIM, Blueprints, and advanced monitoring as your team's AI agent usage grows. Remember: the goal is not to prevent AI agents from being useful, but to ensure they can only perform safe operations.

Ready to Go Deeper?

Live instructor-led courses from our partners. Affiliate disclosure.