🪪 Managed Identity Patterns on Azure With AI: Delete the Secrets, Scope the Roles

We found a storage account key in an app-setting, in a Key Vault, in a CI/CD variable group, and — inevitably — in a Slack message from 2023. The key still worked. Rotating it meant tracking down four copies and hoping we found them all. That is the tax you pay for secrets: they multiply, they leak, and rotating them is an archaeology project. Managed identity removes the secret entirely. There is no key to copy, leak, or rotate, because the platform issues a short-lived token to the workload on demand. The hard part isn’t the mechanics — it’s choosing the right pattern and scoping the roles so the cure isn’t a new liability.

AI is well suited to this work because the decisions are pattern-matching against known options: system-assigned versus user-assigned, which data-plane role maps to which operation, what scope is narrow enough. It will not decide your security model, but it will lay out the trade-offs and draft the role assignments, which is exactly the tedious part teams skip when they over-grant Contributor and move on.

Pick system-assigned or user-assigned deliberately

The first fork is the identity type, and teams usually pick by habit rather than fit. A system-assigned identity is bound to one resource and dies with it — clean and simple for a single workload. A user-assigned identity is a standalone resource you attach to one or more workloads, so it survives resource recreation and can be shared across a blue/green pair. Choosing wrong means either re-granting roles every time you redeploy or sprawling one identity across unrelated workloads.

Prompt: “I have an Azure Function that reads from a storage account and a Key Vault, deployed via blue/green slots. Recommend system-assigned vs user-assigned managed identity for this case, explain the trade-off in terms of role re-assignment on redeploy and blast radius, and give the az commands to create it.”

For blue/green, AI should steer you toward user-assigned so both slots share one identity and you assign roles once. For a single standalone resource, system-assigned is the simpler choice. For AKS, the right answer is Workload Identity (federated credentials), not the deprecated pod-managed-identity that still shows up in old tutorials — and a good prompt will call that out. This kind of deliberate pattern choice runs through all the Azure identity and security work.

Map every call to the narrowest data-plane role

The failure mode isn’t too few permissions — it’s too many. An engineer grants Contributor at the resource group because it “just works,” and now a compromised workload identity can rewrite infrastructure. The fix is mechanical: list every downstream call the workload makes and map each to the narrowest data-plane RBAC role at the narrowest scope.

Prompt: “My Container App needs to: read blobs from one container, read secrets from one Key Vault, and send messages to one Service Bus queue. Give me a table of operation -> exact data-plane RBAC role -> narrowest scope, and the az role assignment create commands. Do not use Contributor or Owner for any data access.”

The output should be specific and tight:

# Storage: data-plane read, scoped to the account (or container)
az role assignment create --assignee "$MI_PRINCIPAL_ID" \
  --role "Storage Blob Data Reader" --scope "$STORAGE_ACCOUNT_ID"

# Key Vault: secrets read only
az role assignment create --assignee "$MI_PRINCIPAL_ID" \
  --role "Key Vault Secrets User" --scope "$KEYVAULT_ID"

# Service Bus: send only, scoped to the queue
az role assignment create --assignee "$MI_PRINCIPAL_ID" \
  --role "Azure Service Bus Data Sender" --scope "$QUEUE_ID"

Storage Blob Data Reader, not Contributor. Service Bus Data Sender, not Owner. Each scoped to a single resource. That table is the difference between least privilege and a standing escalation path, and AI builds it faster than you’d assemble it by hand. The companion review prompt is in the prompts library.

The SDK picks up the identity for free

On the code side, the change is small. Most Azure SDKs use DefaultAzureCredential, which transparently uses the managed identity when running in Azure and your developer credentials locally. The connection string disappears from config.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

cred = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://mystorage.blob.core.windows.net",
    credential=cred,
)

Prompt: “Show me how to switch this Python app from a storage connection string to DefaultAzureCredential with a user-assigned managed identity, including how to specify the client ID of the user-assigned identity, and exactly which app-setting/connection string I delete once it works.”

Verify, then delete the secret — never the reverse

The one rule that keeps this migration from causing an outage: assign the identity, grant the roles, switch the code, verify the workload still works, and only then delete the old secret. Deleting the connection string first guarantees an outage the moment any role scope is slightly wrong. The roles are the part most likely to be off by one — a missing data-plane permission, a scope that’s too narrow — so prove it before you tear anything down.

Prompt: “I’ve assigned a managed identity and roles and the app appears to work. Give me a checklist to confirm every downstream operation succeeds under the identity before I delete the old account key, and a rollback plan if something fails after deletion.”

That sequence — assign, verify, switch, then remove — turns a scary secret-removal project into a series of reversible steps where you confirm the app works at every stage. AI drafts the patterns and the role table; you own the rollout order and the deletion. Do it this way and your secrets stop multiplying because there are no secrets left to copy. More identity material is in the Azure category, and the managed-identity review prompt is ready in the prompts library.