A water utility's multiagent workflow needs one agent to be the only one that can issue work orders, while every other agent in the workflow may only read sensor data. What is the right way to enforce this difference?
Select an answer to reveal the explanation.
Short Explanation
Not every agent in a crew should carry the same set of keys — the one authorized to issue work orders needs a different keyring than the ones just reading meters. Agent Identity is what lets you hand out those different keyrings per agent instead of one master key for everyone.
Full Explanation
Agent Identity supports per-agent permission scoping, which is exactly what this workflow needs: one identity configured with write access for the work-order agent, and separate identities for the read-only agents, enforced at the platform level rather than left to convention. A shared service account for every agent collapses that distinction entirely — once all agents share one identity, there's no way to grant write access to just one of them without granting it to all. Relying on broad permissions plus prompt-level self-restriction puts the security boundary inside the model's behavior, which is probabilistic and can be bypassed by unexpected input, rather than in the platform's access-control layer where it belongs. Documenting the intended split in design notes describes an intention but enforces nothing — without configuring the actual identity and permission grants, any agent with underlying access could still issue a work order regardless of what the documentation says. Scope note: this pattern generalizes to any multiagent workflow where different agents need genuinely different capabilities, not just this water-utility example. Operational check: attempt a work-order call using a read-only agent's identity in a test environment and confirm the platform denies it.