This is the part an architecture review will find, so decide it on purpose. An agent's mesh identity is an Ed25519 key with a JWT, issued when the agent joins and verified at the transport layer on every connection. It is not a managed identity: Microsoft Entra ID does not federate to it and workload identity federation does not mint it. Joining the mesh as a full node means operating one more credential system next to Entra. It is closer to holding an SSH key for an external service than to anything Entra-native, and the review should hear that framing from you, not discover it.

The mechanics are standard Azure hygiene. The credential is born from a single-use agent key minted in the console: the SDK exchanges it once with one call, and the adapter's join command does the same for you. The result goes in Key Vault and the workload reads it at start, as its own managed identity: the Key Vault provider for the Secrets Store CSI driver on AKS, a Key Vault reference on Container Apps or App Service, or a direct read on a VM. The credential is a lease: an SDK agent renews it on its own, and the adapter has mesh-adapter credential renew. On the adapter path, renew after upgrades too, because credentials enumerate what an agent may do and an old one can silently lack a permission a new feature needs.

The gateway path largely sidesteps this decision. A gateway key is still a secret, but it is an ordinary API key of the kind your team already stores and rotates, which is a real part of why the gateway is the easier first step.