A regulated healthcare provider is deploying a multi-agent clinical documentation system on Azure. Security architects mandate Zero Trust for agentic systems: each agent must have its own identity, tool access must be least privilege, and a compromised summarization agent must not be able to move laterally into the e-prescribing tool path. Which design best meets these requirements?
Select an answer to reveal the explanation.
Short Explanation
Zero Trust for multi-agent means per-agent identity and least privilege — not one super identity. You want each agent to get its own managed identity or app registration, tight RBAC/tool scopes, and gateway isolation so a hijacked summarizer can't call e-prescribing. Shared Owner principals, static keys, or VNets alone won't stop lateral movement.
Full Explanation
AI-500 Zero Trust multi-agent guidance emphasizes per-agent identity scoping, lateral movement prevention, and compliance control mapping. The design that assigns each agent a distinct managed identity or app registration, scopes RBAC and tool permissions tightly, and isolates tool gateways implements distinct identities, least-privilege tool scopes, and isolation between high-risk capabilities, so a compromised summarization agent cannot invoke e-prescribing APIs even if its prompt is hijacked. The shared service principal approach violates least privilege and creates a single blast radius across every agent and tool. The static API key approach lacks individual accountability, complicates rotation, and is incompatible with modern Azure identity practices for production agents. The VNet-only approach is incomplete: network controls are necessary but insufficient. Without identity boundaries, any agent process inside the VNet that can reach a tool endpoint may invoke it. Exam tip: Pair private networking with per-agent Entra identities and tool-level authorization for Zero Trust agent systems.