A multi-agent system previously used one shared service principal for the orchestrator and all specialist agents to call Azure resources and tools. A security assessment flags lateral movement risk if any agent is compromised. What should you implement?
Select an answer to reveal the explanation.
Short Explanation
Assign each agent its own managed identity and give it only the least-privilege RBAC it needs. You’ll limit blast radius and stop lateral movement by enforcing identity-based access at tools and network boundaries. Shared super-identities, baked-in tokens, and no auth are the wrong path.
Full Explanation
The correct approach is assigning per-agent managed identities with least-privilege RBAC scoped only to the resources and tools each agent requires, and enforcing identity-based access at tool and network boundaries. Security design includes identity-based access, network boundaries, access control policies, and RBAC. Zero Trust multi-agent guidance emphasizes per-agent identity scoping and lateral movement prevention. Separate managed identities with minimal RBAC per agent, enforced at tools and network edges, meet that bar.
The option granting the shared identity Owner on the subscription is wrong because it vastly increases blast radius and violates least privilege. The option embedding a single long-lived access token in every agent container image is wrong because long-lived tokens in images are secret-sprawl and hard to rotate. The option disabling authentication between agents and tools is wrong because removing authentication removes a core control.
Exam caveat: One identity per agent + least-privilege RBAC + boundary enforcement.