- Overview
- Quickstart
- Trust and compliance
- Governance
- Features
- Cartographer
- Delegate for Testing
- Reference
- Settings reference
- Security settings reference
- Troubleshooting
Fine-grained local security controls in Delegate — tool permissions, terminal and files, protected files, and UI automation — that extend beyond Approval mode.
These settings live under Settings → Security, organized into four areas: Tool permissions, Terminal and files, Protected files, and UI automation.
Tool permissions
Configure when Delegate needs your approval. Tools are organized into four top-level categories, each showing how many tools or operations it covers:
| Category | Covers |
|---|---|
| Connectors | Slack, GitHub, Notion, Linear, Jira, Microsoft 365, and more |
| Office | Word, Excel, PowerPoint, Outlook, Teams |
| System tools | Filesystem, web search, computer use, memory, shell |
| MCP servers | Any MCP servers you have connected |
Expanding a category breaks it down further. System tools, for example, splits into four groups:
| Group | Covers | Default |
|---|---|---|
| Read-only | Reading files, searching the web, inspecting UI elements — operations that don't change anything | Allow |
| Write & modify | Creating or editing files, downloading files, generating images | Ask |
| UI automation | Clicking, typing, or otherwise interacting with an app | Ask |
| Shell & script | Running a PowerShell or Bash command | Ask |
Each group can be set independently to Allow (run automatically), Ask (prompt first), or Block (deny automatically), and expands further to set individual operations on their own.
Connectors and Office follow the same read-only vs. write-and-modify principle at their own scale: each app or service (Outlook, Slack, Excel, and so on) breaks down into its own operations, generally split the same way — for example, reading a Slack channel or an Excel range is read-only, while posting a message or writing to a range is write — each set to Allow, Ask, or Block the same way as System tools.
MCP servers are handled the same way as the other categories, except the operations available depend entirely on which servers your organization has configured.
Terminal and files
Delegate can run shell commands and scripts through the Shell command sandbox, currently in BETA: a scope-aware sandbox manager using Windows AppContainer for kernel-level file system, network, process, and credential isolation. See Scripting and code execution in Security overview for how the sandbox works conceptually.
Kernel isolation
A toggle that turns the sandbox on or off for shell commands. When off, commands run with full user rights instead of the confined environment described in Security overview.
Paths
Shell commands can access only the paths listed here; everything else is blocked. Add your own paths beyond the defaults.
Capabilities
Additional capabilities you can grant to sandboxed shell commands, since they're outside what the sandbox allows by default:
- Internet access — lets sandboxed commands make outbound network connections (HTTP, HTTPS, etc.).
- Private network — lets sandboxed commands reach your local network or LAN.
- Removable storage — lets sandboxed commands read or write USB drives and external disks.
- Shell profile — loads your shell's profile (
.zshrc,.bash_profile, or PowerShell profile) before running commands, so your usual aliases and environment variables are available.
Changes to these may require restarting the app to take effect.
Blocked commands
Block specific types of commands from running — click a suggestion to add it, or type a custom pattern (for example, shutdown, format c:, netstat). These patterns are checked before execution: the agent's command is matched against them as regex and blocked before it runs. This is a separate mechanism from Kernel isolation, and applies regardless of whether the sandbox is on.
Protected files
Delegate needs approval before accessing these files, grouped into categories by what they protect:
| Category | Protects | Example patterns |
|---|---|---|
| Secrets | Environment files and credential stores | .env, .env.*, secrets/*, credentials/*, .npmrc, .pypirc |
| Keys | SSH keys and certificates | .ssh/*, *.pem, *.key, *.p12, id_rsa, id_ed25519 |
| Cloud | Cloud provider credentials | .aws/*, .azure/*, .gcloud/*, service-account*.json |
| Config | Project configuration files — reading is unrestricted, only writes need approval | tsconfig.json, .eslintrc*, Dockerfile, .github/workflows/* |
| Data | Local databases and history files | *.sqlite, *.db, wallet.dat, .bash_history |
You can add your own custom path or pattern beyond these.
Use case: Catch files that might contain credentials, cryptographic material, cloud account access, or other sensitive data, without having to enumerate every possible location yourself.
UI automation
Controls which applications and websites Delegate can act on without asking, and which it must never touch.
Trusted apps and sites (auto-approve)
- Trusted apps — apps Delegate can use without asking. Quick-add by category (Code Editors, Terminals, Office Apps, File Managers, Notes & Docs), or type to select any individual app that's installed or currently running.
- Trusted sites — sites Delegate can use without asking. Search or enter a domain; your browser history can help you pick.
Protected apps and sites (block)
- Blocked apps — apps Delegate won't open or interact with. Type or select an app to add it.
- Blocked websites — sites Delegate won't access. Recommended for banking, payments, password managers, and anything sensitive. Quick-add an entire category with one click — Banking, Payments, Crypto, Password Manager, Government, Healthcare — which populates the list with a set of known sites for that category (for example, clicking Banking added 54 sites), or search/enter a domain to add one yourself.
Use case: Pre-approve trusted workflows (such as Microsoft Excel, Microsoft Word, or an internal site) so they do not trigger repeated confirmation prompts, and block specific applications or sites, or entire sensitive categories, so the agent can never read or act on them.
Permission setting best practices
For individual users
To configure Delegate securely as an individual user, take the following steps:
- Start with Cautious mode until you understand what Delegate does.
- Enable only the tool categories you need — if you do not use command execution, disable it.
- Review permissions after installing new skills — skills may request additional capabilities.
- Use Protected files and Blocked apps/sites for sensitive directories and destinations (tax documents, medical records, etc.)
- Disable Screen Context when working with confidential visual information.
- Pin important sessions so you can review what Delegate did later.
For IT administrators
Deploying and enforcing these settings centrally, across all users, is covered in Governance with Automation Ops, including the recommended baseline for regulated environments.
For developers creating skills
To develop skills that follow good permission-setting practices, take the following steps:
- Request only the permissions you need — do not ask for UI Automation if your skill only reads files.
- Document required permissions clearly in your skill description.
- Handle permission denials gracefully — explain to users why a permission is needed.
- Test in all three Approval mode settings to ensure your skill behaves appropriately.
- Never request access to blocked sites — these are hardcoded for safety.