Good question — this was actually one of our biggest design challenges. Policy UX: The JSON rules are the developer-facing format (and what the SDK uses). For teams without security backgrounds, the Enterprise Dashboard has a visual Policy Builder where you pick agent, tool, effect (allow/deny/require approval), and conditions from dropdowns. No JSON editing required. We found that CISOs want to read the JSON (it's auditable), but they don't want to write it. Auto-suggesting policies: Yes two mechanisms:

Auto-Discovery: When an agent calls a tool that isn't in its registered toolset, the system registers it automatically and logs it. So you get a live inventory of what tools your agents actually use, without defining anything upfront. Permission Score: This tracks the ratio of allowed tools vs. actually used tools per agent. If an agent has access to 15 tools but regularly uses 3, the score surfaces that. It's the data you need to tighten policies; "this agent is over-permissioned, here's what it actually needs."

So the flow is: deploy agent → auto-discovery builds the tool inventory → Permission Score shows the gap → you write (or click together) a tighter policy based on real usage data. Scan first, then define — which sounds like what you're describing.