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?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: A. In production multi-agent systems on Azure, each agent should authenticate with its own managed identity and receive only the RBAC or app-role permissions it needs. That way a document agent cannot call payout APIs even if its prompts or tools are abused. A shared API key (B) creates a single blast radius and is hard to rotate safely. Giving the host Owner (C) violates least privilege and amplifies lateral movement. Network isolation alone (D) is useful but is not identity-based access control—if something reaches the API, it is trusted. Per-agent identity plus scoped RBAC is the Foundry-aligned Zero Trust pattern.
Full Explanation
Microsoft’s multi-agent security guidance emphasizes per-agent identity scoping so that tool and data plane access follows least privilege. Managed identities remove secret sprawl: 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. Option B centralizes a high-value secret and cannot express different permissions per agent. Option C widens the control plane far beyond what any agent needs and makes compromise of the orchestrator catastrophic. Option D assumes the network boundary is the only control; Zero Trust multi-agent design still requires authenticated, authorized calls with continuous validation. 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.