> ## Documentation Index
> Fetch the complete documentation index at: https://ade-app.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions and security

> How ADE keeps agent work scoped to a lane, makes shared config trusted before it runs, and keeps secrets local.

ADE agents edit files and run commands, so permissions matter. The goal is simple: keep each agent's work scoped to the right lane, make shared config trusted before it can run on your machine, and keep secrets off disk in plaintext.

## Main controls

> [card] Lane scope
>
> Sessions run inside the selected lane's worktree under `.ade/worktrees/`, isolated from your primary checkout and from other lanes.

> [card] Provider permission modes
>
> Each provider runtime exposes its own approval modes; ADE maps them to a common set.

> [card] Shared-config trust
>
> Shared config that can spawn processes requires a trust confirmation before ADE will run it.

> [card] Secrets
>
> Provider keys and credentials stay in local encrypted stores or gitignored files — never in shared config.

## Lane scope

A lane is a git worktree. Chats, terminals, CLI sessions, and the processes they start are scoped to that worktree, so an agent working a task can't reach into your primary checkout or another lane's files. Do agent edits in lanes and keep the primary checkout for inspection — it's your real working tree and the safer default to leave alone.

## Per-agent tool control

Each agent runs with a permission mode that governs how freely it can edit files and run commands. Set a stricter mode for unfamiliar repositories, and a more permissive one only when you trust the lane and the task. You can also scope which tools a session may use from the chat header.

## Provider permission modes

> [accordion] How provider modes map
>
> Permission names vary by provider, but ADE groups them into a common set:
>
> | Mode | Meaning |
> | - | - |
> | Plan / read-only | The agent can inspect and propose, but cannot freely edit. |
> | Edit / default | The agent works in the lane with normal approval guardrails. |
> | Full auto | The agent runs with fewer prompts. Use only when the environment is trusted. |
> | Custom | The provider's own configuration decides. |
>
> Set defaults per provider in **Settings → Providers**, and override per chat or worker as needed.

## The trust model for shared config

ADE splits project configuration into shared, version-controlled `.ade/ade.yaml` and a per-user, gitignored `.ade/local.yaml`. Shared config can introduce new commands — processes, stacks, test suites — that you haven't approved. ADE treats that as sensitive: when the shared config changes, it must be **trusted** again before ADE will return an executable config that spawns processes. Cloning a repo and opening it requires confirming trust on its shared config the first time.

Local config isn't trust-gated — you only need to trust your own overrides. Treat a shared-config change the same way you'd review a CI script or Dockerfile.

## Practical defaults

* Do agent edits in worktree lanes, not the primary checkout.
* Keep the primary checkout for inspection or manual commands.
* Review diffs before committing or pushing.
* Use stricter approval modes for unfamiliar repositories.
* Keep provider keys and tokens out of shared config and out of Git.
* Review shared-config changes carefully before confirming trust.

## Sensitive actions

Be extra careful with:

* Force pushes.
* Commands that run outside the repository.
* Secret files and `.env` files.
* Scripts pulled from unreviewed branches.
* Networked deployment or release commands.

> [!WARNING]
>
> ADE helps enforce boundaries, but agents still run tools on your machine. Review what they ask to do, especially in new repositories and the first time you open a teammate's shared config.

> [card] [AI providers](https://ade-app.dev/docs/configuration/ai-providers.md)
>
> Connect each agent and set permission presets.

> [card] [Configuration overview](https://ade-app.dev/docs/configuration/overview.md)
>
> The `.ade/` directory, the trust model, and what not to commit.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.