Permissions

Every time an agent 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.

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:

{
  "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: who can see and reference a resource, the other half of access control.
• Agents: where agent permissions are configured.
• Projects: the project-level permission layer.