# Permissions

Every time an [agent](/docs/deep-dives/concepts/agents/agents/) takes an action (reading a file, running a shell command, calling an MCP tool), Ren checks a permission first. Permissions are capability-based: instead of roles like "admin" or "viewer", you allow, deny, or require approval for each specific capability.

A code-review agent might get `read` and `grep` but not `bash`; a deploy agent might get `bash` and `edit` but not `webfetch`.

## Permission values

Every capability resolves to one of three values:

| Value   | Meaning                                             |
| ------- | --------------------------------------------------- |
| `allow` | The agent may perform the action without prompting. |
| `deny`  | The action is blocked.                              |
| `ask`   | The agent must get human approval first.            |

You can set a single value for everything, or set values per capability.

## Capability keys

| Key                  | What it gates                                                   |
| -------------------- | --------------------------------------------------------------- |
| `read`               | Reading file contents.                                          |
| `edit`               | Writing or modifying files.                                     |
| `glob`               | Listing files matching a pattern.                               |
| `grep`               | Searching file contents.                                        |
| `list`               | Listing directory contents.                                     |
| `bash`               | Executing shell commands.                                       |
| `task`               | Delegating to sub-agents.                                       |
| `external_directory` | Accessing paths outside the project root.                       |
| `todowrite`          | Updating the agent's todo list.                                 |
| `question`           | Asking a clarifying question.                                   |
| `webfetch`           | Fetching content from a URL.                                    |
| `websearch`          | Performing web searches.                                        |
| `codesearch`         | Searching code across repositories.                             |
| `lsp`                | Using language-server features (go-to-definition, diagnostics). |
| `skill`              | Invoking a [skill](/docs/deep-dives/concepts/agents/skills/).   |

## Pattern maps

Capabilities like `read`, `edit`, `bash`, `external_directory`, and `skill` accept a **pattern map** instead of a single value: mapping glob-like patterns to actions. For example, allow reading `src/`, deny `.env`, and ask for everything else:

```json
{
  "read": {
    "src/**": "allow",
    ".env*": "deny",
    "*": "ask"
  }
}
```

Patterns are evaluated most-specific first; `"*"` is the catch-all.

## Project vs. agent permissions

Permissions are set at two levels:

- **Agent permissions** define what an agent needs to function.
- **Project permissions** define organizational policy: the ceiling for any agent running in that project.

When both apply, the stronger restriction wins: `deny` beats `ask` beats `allow`. So a project-level `bash: deny` can't be overridden by any agent. Set restrictive defaults at the project level, then let individual agents request the narrower access they need.

## Where to go next

- [Scopes](/docs/deep-dives/concepts/sharing/scopes/): who can see and reference a resource, the other half of access control.
- [Agents](/docs/deep-dives/concepts/agents/agents/): where agent permissions are configured.
- [Projects](/docs/deep-dives/concepts/compute/projects/): the project-level permission layer.