> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getunbound.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Discovery — Permissions
> How much autonomy the tools on your devices are configured to have
| | |
| ----------- | --------------------------------- |
| **URL** | `/ai-tools-discovery/permissions` |
| **Sidebar** | AI Tools Discovery → Permissions |
| **Roles** | Admin · Analytics Viewer |
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
| Section | Shows |
| ----------------------- | ------------------------------------------------------------------------------------------------ |
| **Autonomy Levels** | Developers by how independently their tools may act — Full Auto, Auto Edit, Ask First, Read Only |
| **Top Risk Factors** | What is contributing most across the fleet, and how many developers each factor covers |
| **Top Risky Users** | The developers with the highest risk scores |
| **Users by Risk Level** | The table underneath: **User**, **Tool**, **Autonomy**, **Risk Factors** and **Score** |
## Filters and controls
| Filter | Values |
| ------------------ | --------------------------------------------- |
| **Risk Level** | Critical · High · Medium · Low |
| **Autonomy Level** | Full Auto · Auto Edit · Ask First · Read Only |
| **Users** | Specific developers |
**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](/dashboard/discovery/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](/dashboard/discovery/summary) leaderboard.
| What you see | What it means |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| A breakdown, badged **last 30d** | Runtime data is available for this developer |
| *Not used in the last 30 days* | The tool is installed but has not run in the window |
| *Not enough runtime data to show a distribution* | It has run, but in modes too ambiguous to rank |
| A chip with nothing to open | No runtime detail for this row — always the case for any tool other than Claude Code, the only tool this breakdown covers |
The breakdown is up to a day behind, so a mode used today appears tomorrow.
## What you can do
| Action | Result |
| -------------------- | ---------------------------------------------- |
| Select a developer | Opens their permissions panel, below |
| Select a risk factor | Narrows the page to the developers carrying it |
### Permissions panel
| Section | Contents |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **User Details** | The developer, their device and device profile |
| **Risk Assessment** | Their score and level, the risk factors, and the reasons behind them |
| **Permission Settings** | **Autonomy Level**, **Permission Mode**, whether the **Sandbox** is on, and the **Settings Source** the values were read from |
| **Allow Rules** | What the tool has been told it may do without asking, listed as written, with the count in the heading |
| **Deny Rules** | What it has been told to refuse. With none configured, the panel suggests a starting set |
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.
**Unconfigured Full Auto** on [Summary](/dashboard/discovery/summary) counts the devices where a tool may act without asking **and** has no deny rules **and** is not sandboxed — nothing stands between the agent and the machine. It links straight into this page with that filter applied: adding deny rules or turning the sandbox on closes the widest gaps first.
## 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
**Risk Level** follows the score: 9 and above is Critical, 7 and above High, 4 and above Medium, below 4 Low.
**Risk Factors** are the labelled findings behind the score. There are ten of them, and no others: Full Auto, Command Execution, No Deny Rules, Auto Edit, Network Access, System Modification, Sandbox Disabled, Sensitive Directories, File Protection, Unrestricted Permissions. **Risk Assessment** in the panel spells out the reason behind each one.
A row here is one tool on one device. A developer's single figure on **Summary** is their **riskiest** tool rather than an average, so extra tools never dilute an exposure. Hovering that score on the [Summary](/dashboard/discovery/summary) leaderboard splits it into **Permission Risk** and **Config File Risk** — the **Score** column here is the permission side alone.
## Messages you may see
| Message | What it means |
| ------------------------------------- | ---------------------------------------------------------------------------------- |
| `No users found matching your search` | No developer matches the current search and filters. Clear one to widen the result |
| `No users available` | No developer matches the current filters |
| `No rules configured` | That tool has no allow or deny rules of this kind |
## Related
| Page | For |
| --------------------------------------------------------- | ------------------------------------------ |
| [Policies — Agentic Use](/dashboard/policies/agentic-use) | Setting what agents may do through Unbound |
| [Discovery — Summary](/dashboard/discovery/summary) | The fleet overview |