A financial services firm is deploying a multi-agent claims workflow in Microsoft Foundry. Three specialized agents must call different backend APIs: a document-extraction agent, a policy-lookup agent, and a payout-recommendation agent. Security requires that a compromised agent cannot call APIs outside its role. You must enforce least privilege without embedding long-lived secrets in agent configuration. Which approach best meets these requirements?

Microsoft’s multi-agent security guidance emphasizes per-agent identity scoping so that tool and data plane access follows least privilege. The dedicated managed identity approach meets this requirement: each agent authenticates with its own identity, and that identity receives only Azure RBAC or API-scoped app roles for the resources and tools it is allowed to use. Managed identities remove secret sprawl because agents obtain short-lived tokens from Azure AD (Entra ID) without storing passwords or static keys. Pair each identity with narrow role assignments—custom roles or API app roles limited to specific operations and resources—so a document-extraction agent cannot call payout APIs even if its prompts or tools are abused. The shared API key approach centralizes a high-value secret, creates a single blast radius, is hard to rotate safely, and cannot express different permissions per agent. The host Owner role approach widens the control plane far beyond what any agent needs, violates least privilege, amplifies lateral movement, and makes compromise of the orchestrator catastrophic. The disable authentication and private VNet approach assumes the network boundary is the only control; Zero Trust multi-agent design still requires authenticated, authorized calls with continuous validation, and if something reaches the API it is trusted. Implement network segmentation as defense-in-depth, not as a substitute for RBAC. Operationally, map each agent’s tool manifest to its identity’s allowed scopes and deny by default.