Glean Tau security and permissions

Glean Tau can read and change local files, run programs, and act in connected apps. Use its security controls to limit the work it can perform and the resources it can reach.

Glean Tau doesn't run every component or action inside one isolated environment. Each way it reaches a resource has its own controls, so assess each path separately.

Understand the access controls

Each control answers a different question. An action must satisfy every applicable control.

Control	What it decides	What it doesn't grant
Account and source permissions	Which company information and connected services the user can access	Access to another user's content
Admin policy	Which features, modes, files, and destinations the organization permits	An exception when a user selects Allow
Approval mode	Whether permitted work runs directly, receives automatic review, or asks the user	Access beyond admin restrictions
Sandbox	Which files and network operations a supported local process can reach	Access to an unrelated app's signed-in session
Operating-system permissions	Whether Glean can capture the screen, use the microphone, or control apps	Approval for a specific agent task

Glean search respects the user's existing company permissions. Local files, browser sessions, and credentials use a separate access path. A file doesn't need to be in Glean's company index for an allowed local task to read it. Glean Tau can't read a file that the signed-in operating-system user can't access.

Granting access through one control doesn't grant it through another. For example, admin policy can let the agent run git push, but the Git host still decides whether the user's credentials can push to that repository. A Glean data source can be searchable, but admin policy decides whether the agent can write the results to disk without review.

Know who sets each control

Glean admins and the team that manages employee devices often share these decisions. Agree on an owner for each one before deployment.

Decision	Set by	Where
Whether Glean Tau is available to an account	Admin	ext.glean.tauEnabled in managed settings
Which features load	Admin	features in managed settings
Allowed approval modes, reviewers, and sandbox modes	Admin	core.authority.requirements in managed settings
Commands that need review or are forbidden	Admin	rules.prefixRules in core.authority.requirements
Paths the agent can never read	Admin	permissions.filesystem.denyRead in core.authority.requirements
Network destinations for commands	Admin	networkAccess or permissions.network in managed settings
Guidance for automatic review	Admin	sentinelExtraPolicy in core.authority.requirements
Default approval mode and sandbox within admin limits	User	Settings → Agent access
Project folders and file rules	User	Settings → Agent access or the user settings file
Mode for one chat or project	User	The composer access picker
Remembered approvals	User	Approval cards. Revoke them in Settings → Agent access
What an account can do in a connected service	Service	The connected service's administration

Admins can't set a user's project folders, file rules, or remembered approvals. Admin policy bounds them: every user choice stays inside it. See Manage Glean Tau settings.

Know the access paths

Glean Tau reaches resources through several paths. A review that covers only shell commands misses browser accounts, connected-service changes, app extensions, and background work.

Path	What it does	What limits it
Task content	Supplies prompts, files, tool results, and web pages to the agent	Nothing. Content is information, not permission to act. See Handle untrusted content.
File tools	Read, search, write, and edit files	Approval mode, file rules, and protected paths
Agent commands	Run shell commands and the programs they start	Approval mode, command rules, and the sandbox on supported platforms
Terminal tabs	Run interactive shells for the user	The user's own account. Agent input follows the approval mode, but the tab runs outside the command sandbox
Browser, Browser Use, and Computer Use	Act in signed-in browser sessions and other apps	Feature policy, approval mode, and operating-system permissions. The sandbox doesn't contain these effects
Connected services and MCP servers	Read or change data in Glean, connectors, and MCP servers	The acting account's service permissions, plus review of changes
Model requests and local records	Send task context to the selected model and store chats on the device	Model Hub configuration, telemetry settings, and endpoint protection

Understand how Glean Tau evaluates an action

Glean Tau checks each governed action when the agent proposes it. It considers:

• The requested operation, such as read, write, delete, list, search, or run a process
• The target path, command, destination, or service
• The chat's working folder and project
• The approval mode and Sandbox Mode setting
• Admin policy, the user's access settings, project rules, and built-in rules
• Approvals the user has remembered

The result is one of three outcomes. An allowed action runs within those limits. An action that needs review goes to the automatic reviewer or the user, depending on the approval mode. An action that matches a denial, falls outside an allowed boundary, or fails an operating-system permission check is blocked.

Denials apply before review. An admin denial, a protected path, or a feature that's turned off blocks the action without sending it to a reviewer, so no approval can override it.

Glean Tau checks a reviewed action again immediately before it runs. For a command, the command, working folder, environment, and sandbox profile must match what was reviewed. If policy or the approval mode changed in the meantime, the pending approval doesn't carry over. A recheck can keep or narrow the access that was reviewed, but it can't widen it.

An approval card waits until the user answers or the agent turn ends. It doesn't time out or approve itself. A session that can't show a card, such as an automation run, denies an action that would ask instead of waiting.

Separate approvals from sandboxing

Approvals decide whether an action can proceed. A sandbox limits the effects of supported local execution after approval.

Approve for me can approve an action automatically. It doesn't imply that the action runs in a sandbox. Ask for approval increases human review, but a user can still approve a command with broad access when policy permits it.

Turning off Sandbox Mode in Ask for approval or Approve for me runs commands without confinement. Review and the dangerous-command checks stay active.

A remembered command approval can also change where the command runs:

• Allow for session removes later prompts in that chat. The command still runs in the sandbox.
• Always allow removes later prompts in the project and runs the matching command outside the sandbox in later chats, as an explicit user rule would.
• An admin allow command rule also runs the matching command outside the sandbox.

A command runs outside the sandbox this way only when every part of the command matches such a rule. While admin policy sets a read denial, no remembered approval or rule runs a command outside the sandbox.

Full access skips ordinary action review and the dangerous-command checks, and turns off the user's sandbox setting. The app still applies admin limits and operating-system permissions. A workspace selection or Git worktree doesn't create an operating-system security boundary.

Require sandboxing through admin policy when confinement is mandatory. The user-facing Sandbox Mode preference alone isn't a fleet-wide guarantee. See Agent approval modes.

Limit files and commands

On supported Macs, required sandbox policy constrains supported file operations and local processes. File rules can exclude exact paths or directories from reads, and command rules can allow, prompt for, or forbid specific commands.

Know what the sandbox permits by default

The default sandbox is a compatibility boundary for development work, not a selected-folder-only boundary. Without additional rules, a sandboxed command can:

• Read files broadly across the device
• Write to the chat's working folder, folders added to the project, temporary folders, and the user's ~/.glean folder, except Glean Tau's own policy and approval records
• Make outbound network connections

Use denyRead to exclude credential files and sensitive directories, and limit network access when the workload allows it. See Limit filesystem access.

Know which paths are protected

Glean Tau's file tools refuse to write these locations in every mode, including Full access:

• The credential directories ~/.ssh, ~/.aws, ~/.config/gcloud, and ~/.kube
• The managed settings file /etc/glean/managed-settings.json
• Glean Tau's enrollment record and its approval, policy, and audit records

In sandboxed modes, some locations inside a writable folder stay read-only. A write there needs review, and the approval card offers only Allow once and Deny:

• Credential directories with the same names, such as .ssh or .aws, inside the folder
• Git hooks, config, and config.worktree for the repository, and a .git pointer file
• In writable folders other than the chat's working folder, such as folders added to a project or set for every project, the .git, .agents, .codex, and .aws folders

The protected-path check resolves symbolic links, case variants, and alternate spellings such as /private/etc on macOS before it compares paths. Protection follows the path. A hard link to a protected file, reached by its own path elsewhere, is an ordinary file. The sandbox bounds those writes in sandboxed modes. A command that runs without a sandbox isn't held to the same boundary.

Scope rules to files and operations

Glean Tau evaluates each file operation separately, such as reading, writing, creating, deleting, renaming, listing, and searching. The rules you configure are coarser. They grant or deny read and write access for an exact file or for a directory and everything below it.

Admins set read denials for the organization. Users can add project folders and deny reads or writes for paths in their own access settings, within the limits of admin policy. See Configure your access.

Glean Tau has no setting that grants execute permission for every file in a folder. Command rules and the sandbox control what the agent can run, and the operating system still decides whether a program can start.

Test the boundary with real workloads

Child processes remain subject to the process boundary. If Glean Tau can't establish a required boundary, it rejects the operation. It doesn't silently retry that required operation without confinement.

A read denial also applies to the files a command needs. An interpreter, build system, or package manager can fail if a denied path contains its required files. Test real workloads before deployment.

These controls apply to governed agent work. They aren't a restriction on every file the desktop app needs for sign-in, settings, logs, or operation.

Limit network access

Sandboxed commands can make outbound connections by default. Turn off network access for sandboxed commands, or require a managed proxy with a destination allowlist. See Limit network destinations.

A managed network allowlist controls destinations and ports for supported traffic. A matching deny still blocks a destination. These rules don't filter individual URL paths, HTTP methods, repositories, or message content.

A permitted host can still receive sensitive information. For example, allowing a code-hosting domain doesn't limit requests to your organization's repositories. Combine destination restrictions with service permissions and review of consequential actions.

The process network boundary doesn't replace network controls for Glean sign-in, model requests, updates, or an external browser. Browser, desktop-app, and service traffic use separate routes. Don't treat the boundary as a firewall for the entire device or as complete protection against data leaving it.

Control browser and desktop access

Browser Use and Computer Use can act through sessions that the user has already signed in to. Computer Use can view the screen and interact with other apps. A workspace folder doesn't contain these effects.

Actions that navigate a page, interact with a page or app, or type into a Terminal tab follow the approval mode. Observations, such as reading a page or listing open windows, can run without review. Even an observation can expose private information that's visible in a signed-in session.

Remembered approvals for these actions are narrow:

• Browser panel. An approval covers the checked site and the same kind of action, in any tab. Running page JavaScript is never remembered.
• Browser Use in Chrome. Only navigation to a site can be remembered, by the destination site. Other actions in a Chrome tab are reviewed each time, because the tab can move to another site before the action runs.
• Computer Use. An approval covers only the exact text, keys, or pointer target that was approved.

The Browser panel can import cookies from another browser, which makes the user's existing accounts available there. Set ext.browser.cookieImportEnabled to false to stop cookie import. See Use other managed settings.

Keep these features unavailable when the workflow requires a strict local execution boundary that they can't satisfy. A required policy rejects incompatible features instead of silently granting broader access. The built-in browser, Git features, Activity Journal, and other capabilities also have separate compatibility limits.

Review connected services and MCP servers

Connected services authorize requests with the user's account. Glean Tau review decides whether the agent should make a request. It doesn't change what the account can do in that service.

Reads from Glean run without a separate review. Requests that change Glean data are reviewed under the approval mode.

For MCP servers, a tool's annotations and name can't reclassify a change as a read. They can only raise its risk. Glean Tau also reviews a tool call unless the server marks the tool read-only and not destructive. A tool with no annotations is reviewed. Because the server supplies these annotations, a server that marks a tool read-only can run that tool without review. Allow only MCP servers you trust.

For local MCP servers, review the server's executable, arguments, credentials, and requested access. Approving a tool call doesn't establish that the server itself is safe. Remote servers run outside the local process sandbox. See Connect your own MCP servers.

Review other access paths

Include these paths in your deployment inventory:

• Terminal tabs. A Terminal tab runs the user's shell directly on the device. It isn't subject to the agent's command sandbox. See Terminal.
• Subagents. A subagent inherits the parent chat's approval mode, reviewer, project-wide approvals, and restrictive rules, and can't widen them. Delegating work inside the parent's working folder doesn't need review.
• Extensions. Extensions are part of the trusted app. Separate storage folders and scoped interfaces organize their data, but they don't isolate extension code from the rest of the app. Use feature policy to choose which extensions can run. See Control features.
• Automations. Scheduled automations can run while the user is away, so no one is available to answer an approval prompt. Each automation has its own access mode, separate from the current chat's mode, and Full access is on by default when your organization allows it. Assess the access mode of background work separately. See Automations.
• HTML artifacts. HTML previews run in a restricted frame. The preview can't make network requests, submit forms, or embed other frames. It can load scripts and styles only from a short list of public code-hosting sites, and remote images only from Glean domains. Uploading or sharing an artifact is a separate action with its own data handling.

Understand automatic review

In Approve for me, Glean Tau evaluates work that needs review against the requested task and the proposed action. It can allow the action, ask the user, or deny it. Some routine work can proceed through existing rules without a separate model review.

The reviewer is a separate model. It receives the exact action and its targets, the user's instructions in the chat, and any organization guidance from sentinelExtraPolicy. By default it uses a Glean-hosted model. Admins can select a different review model. See Configure automatic review.

Automatic review can't override an admin denial or extend a required sandbox. Actions that policy already denies never reach the reviewer. If review fails or times out during an interactive task, Glean Tau asks the user. A review failure never approves the action. If no user decision is available, the action doesn't proceed. See Automatic review behavior.

Automatic review reduces manual prompts. It doesn't guarantee that every harmful action or misleading instruction will be detected.

Understand data handling

Local execution doesn't mean that the task stays offline. Glean Tau sends task context to the selected model service. That context can include prompts, file content, tool results, and screenshots used for the task. Review the permitted model providers and enabled capture features before using sensitive data.

Adding a local folder doesn't add its contents to the company's Glean search index. Reading a file for a task can still include its content in a model request.

Data residency, retention, and model training terms come from your Glean service configuration and agreements. A local app or process sandbox doesn't establish them.

Sign-in and credentials

Glean Tau signs in with OAuth and Proof Key for Code Exchange (PKCE). It stores the refresh token in the macOS keychain or in operating-system encrypted storage on Windows. The access token stays in memory and in a shared credential file under ~/.glean/agent, so other Glean tools on the device can reuse the session.

Each Glean account that signs in on a device has its own local profile. Switching accounts relaunches the app with the other profile. This keeps each account's local data separate within the app, but other programs running as the same operating-system user can still read those files.

Glean Tau doesn't make credentials inaccessible to every tool or process. A command running without a sandbox, or a program the user approves, can read credential files that the user can read. Exclude sensitive credential locations with denyRead.

Local records

Glean Tau stores chats, tool results, artifacts, and approval records on the device under each feature's storage. It also records each permission decision in a local audit database, including the approval mode, reviewer, and outcome. Some approval and policy records are signed to detect changes. Signing isn't encryption, and Glean Tau doesn't encrypt all task data at the app level. Use device disk encryption, access controls, and backup and retention practices to protect these records.

Approvals that a user remembers stay in effect for their scope, such as a chat or project, until the user revokes them in Settings → Agent access → Remembered approvals. A remembered approval doesn't show that an unrelated later task is safe.

When a tool returns a large result, Glean Tau sends a shortened version to the model and saves the full result in a local file. Shortening limits size. It doesn't remove secrets.

Telemetry

Telemetry is a separate control. Desktop telemetry and full trace-content export are on by default. Full trace content can include prompts, responses, and tool input and output, with credential redaction and size limits. Redaction doesn't make arbitrary document content safe to share.

Use core.telemetry.enabled to turn managed application telemetry on or off. Use core.telemetry.fullExport to control whether telemetry includes full prompt, response, and tool content. See Use other managed settings.

Turning off full export doesn't stop the model requests needed to complete a task. It also doesn't erase existing chats, local diagnostic files, or previously exported data. Confirm retention and access requirements for those records separately.

Handle untrusted content

A document, web page, repository, email, or tool result can contain instructions that try to redirect the agent. This is a prompt injection attack. Treat content from these sources as information to evaluate, even when it appears in a trusted workflow.

Reduce the effect if the agent acts on a misleading instruction:

• Give the agent a specific task and a limited working folder
• Exclude credential files and sensitive directories from required file access
• Limit network destinations and optional features to the task
• Review proposed uploads, external messages, destructive changes, and production operations
• Keep secrets out of prompts, policy examples, and diagnostic exports

Instruction files such as AGENTS.md guide the agent. They don't create an enforceable admin policy or sandbox.

Know how Glean Tau fails closed

When Glean Tau can't confirm that an action is permitted, it blocks the action instead of running it with broader access.

Condition	Behavior
Admin policy is malformed or fails validation	Agent actions are blocked. The app and chat history stay usable, and a banner names the failing setting
Server-managed settings can't be reached	The last accepted policy applies for up to 30 minutes. Then agent actions are blocked until it refreshes
Automatic review is unavailable or times out	An interactive task asks the user. Otherwise, the action doesn't run
A required sandbox is unavailable	The operation is rejected instead of running without confinement
The user settings file is invalid	Agent actions are blocked until the user corrects the file
Glean Tau's approval storage is unavailable	Local agent actions are blocked. Settings → Agent access offers a retry
An action needs approval in an unattended session	The action is denied

For recovery steps, see Troubleshoot managed settings.

Plan a security review

Before deployment, identify the work users need to do and the access it requires. Record a decision for each area:

Area	Decision to record
Release and platform	The installed app version, supported operating systems, and which paths each workflow uses
User access	The local folders, credentials, apps, browser profiles, and networks available to the user's device account
Approval policy	When users can choose each approval mode, and who reviews sensitive workflows
Service access	Enabled connectors and MCP servers, the accounts they act as, and the changes those accounts can make
Data policy	Permitted models and data classes, regional and retention terms, and how screenshots and artifacts are handled
Background work	Who owns each automation, its access mode, the accounts it acts as, and the effects it can have while unattended
Endpoint operations	Disk encryption, local access controls, backups, incident response, app updates, and enabled extensions

Verify each stronger requirement on the exact app version and platform you distribute. Test ordinary work and attempts to cross the boundary you intend to enforce. Include Git, browser, connected-service, extension, automation, account-switch, and cancellation workflows. A test of one component doesn't establish protection for the whole app.

To verify a deployment, sign in as a pilot user who receives the policy, then:

1. Open Settings → Agent access and confirm that the notices match the restrictions you intended.
2. Ask the agent to run a sandboxed command that writes inside the project. In Approve for me, it runs without an approval card.
3. Ask the agent to read a path in denyRead. The request is refused.
4. Ask the agent to run a command that a rule forbids or sends to review. Confirm the refusal or the approval card.
5. If your policy removes Full access or requires sandboxing, try to select Full access or turn off Sandbox Mode. Confirm that the app explains the restriction.
6. Repeat these checks on each platform you deploy.

Assigning a policy to a group doesn't enforce it on a device. Only a delivered, valid policy does.

Check platform and workflow limits

Managed settings have these platform and workflow limits:

Workflow	Support boundary
macOS desktop	Supports protected policy delivery and required confinement for compatible local operations and features
Windows desktop	Supports machine policy, managed preferences, approval limits, a required sandbox, read denials, feature restrictions, and enrollment. Network confinement is unsupported, and the proxy isn't enforced.
Command-line interface and standalone web execution	Reject nonempty managed settings rather than claim desktop policy enforcement
Browser Use and Computer Use	Require their own feature and operating-system permissions. A local workspace boundary doesn't contain their external effects.
Unattended automation	Can't rely on a person answering an approval prompt. Test the selected access mode and policy before scheduling work.

A successful policy parse doesn't prove that the device enforces the policy. Verify allowed and denied operations on the signed app, operating system, and account type that you distribute.

See also

• Configure macOS privacy permissions — grant screen capture and other macOS permissions by profile
• Check Windows policy support — which controls Windows enforces