In a Zero Trust multi-agent design, a low-privilege FAQ agent was compromised via prompt injection and attempted to invoke the wire-transfer tool bound only to a payments agent. The tool call succeeded because both agents shared one managed identity with contributor rights on all tools. What architectural fix best prevents this lateral movement?
Select an answer to reveal the explanation.
Short Explanation
You need per-agent identities with tool-scoped RBAC and identity checks at the tool gateway. A shared contributor identity lets a compromised FAQ agent reach payment tools. Broader FAQ permissions, secrets in prompts, or merging agents only widen the blast radius or remove isolation.
Full Explanation
Assigning per-agent identities with tool-scoped RBAC so the FAQ agent's identity cannot invoke payment tools, and enforcing identity checks at the tool gateway, is correct because Zero Trust multi-agent architecture requires per-agent identity scoping and lateral movement prevention. Distinct identities plus tool-gateway authorization ensure a compromised FAQ agent cannot call payment tools reserved for the payments agent. Giving the FAQ agent even broader permissions so it can self-remediate incidents is incorrect because expanding FAQ permissions increases blast radius after compromise. Storing wire-transfer credentials in the FAQ agent's system prompt for faster debugging is incorrect because secrets in prompts are extractable and grant the compromised agent direct payment capability. Merging FAQ and payments into one mega-agent to reduce the number of identities is incorrect because collapsing agents into one identity concentrates privilege and removes the isolation boundary the design needs.