Permissions shows how far each AI tool on a developer’s machine may go before asking, what it has been told to allow or refuse, and whether it runs sandboxed — and where those settings leave the most room.
What’s on the page
Filters and controls
Risk Factor is not in the Add Filter menu — it is applied by selecting a bar of Top Risk Factors, which is scoped to the top five under your other filters. It then shows as a chip alongside the rest.
The table has its own search, which matches the system user the tool was found under. Selecting a slice of Autonomy Levels, a bar of Top Risk Factors or a bar of Top Risky Users applies it as a filter. Arriving from Unconfigured Full Auto on Summary opens the page with Full Auto selected and a removable Unconfigured Full Auto chip.
What they configured, and what they actually did
The Autonomy chip is what a tool is configured to allow. For Claude Code it is also clickable, and opens what that developer’s agent actually did over the last 30 days, broken down by permission mode — Plan, Manual, Don’t Ask, Accept Edits, Auto and Bypass Permissions — with the turns and sessions spent in each. It settles what the configured chip cannot: whether the posture someone wrote down is the one they work in. A developer configured Ask First who spent four hundred turns in Bypass Permissions is the finding worth acting on. The same breakdown opens from the Autonomy chip on the Summary leaderboard.
The breakdown is up to a day behind, so a mode used today appears tomorrow.
What you can do
Permissions panel
A developer usually has several settings files — a global one, a managed one from your MDM, and one per project. What you see here is the most permissive of them, not the single effective configuration the tool would resolve at runtime — so a permissive grant in one throwaway repository reads as that developer’s posture, even where your managed settings would have overridden it.Read it as what is written down anywhere on that machine, not as what the tool will do next. That makes it the right place to find a stray project file, and the wrong place to confirm that a central policy is being enforced. Settings Source names which file a row came from — a developer’s own settings, a project’s, or your managed ones — so it tells you where to go and fix it.
Reading the risk score
Score runs from 1 to 10, and rises with the gaps in a tool’s configuration. The gaps that raise it, heaviest first:- A full or nested shell, so arbitrary commands can run
- A permission mode that runs any tool without asking
- A wildcard grant
- Commands that can change the system (
sudo,chmod,chown) - Commands that can move data off the machine — fetchers, remote shells, transfer tools, network
git - File deletion allowed
- Package installs allowed
- A root or home directory handed to the agent
- No deny rule covering sensitive files (
.env, keys, credentials) - Sandbox explicitly turned off
- Unrestricted file write or edit