To avoid repeated troubleshooting tickets, a specialist grants the Agent User a permission set with "View All" on every clinical object across all six regional hospitals. What is the main risk this introduces?

Provisioning the Agent User far beyond what its actions actually need trades a nuisance for a genuine data-exposure risk: because every action executes in that single user's security context, an overbroad grant means a conversation-design gap, a misrouted topic, or an unexpected action input can surface records the owner or channel was never meant to see, including another clinic's patients or another owner's account. That is a direct violation of least privilege and is exactly the kind of configuration error the security objective is testing. The idea that a broader permission set carries no downside, only upside, ignores that access control exists specifically to bound what a single identity can reach; "more access, zero risk" is never true for a shared execution identity. Permission set breadth has no bearing on reasoning engine performance, since classification runs against topic metadata, not against the object permissions the eventual action might use. And applying a custom permission set does not disable standard topics; standard and custom topics both simply execute under whatever permission set the Agent User holds, which is the whole point of the model.