Set organization policies

Policies give an organization administrator one place to set the defaults, tools, models, and limits available to groups of members.

Note

Policies are available to administrators of managed organizations. Members do not see the Policies tab. On an organization that is not managed, the tab shows Managed only and an Upgrade to Managed option instead of the policy editor.

Open your organization’s policies

1. Open your account menu and select Organizations.
2. Select the organization you want to manage.
3. Select Policies.

The page lists each policy and marks the organization’s Default policy. If the organization has no policies yet, the first one you create becomes the default for new members.

Create a policy

1. Select Add policy.
2. Enter a Policy name between 4 and 18 characters.
3. Optionally enter a Monthly spend limit. Leave it blank for no policy-level limit.
4. Configure the chat defaults, model access, and feature controls your members need.
5. Review the footer for the Unsaved changes indicator, then select Save.

The monthly limit applies to managed-domain members assigned to the policy. A limit set directly on an individual member overrides the policy limit for that person.

Set chat defaults

Turn on Enable chat defaults to choose the Model, Instructions, Language, and Temperature that new chats outside projects start with. Project chats use their project settings instead of these policy chat defaults.

Each default can be Unlocked or Locked:

• Unlocked gives members the default while allowing them to change it.
• Locked prevents members from changing that setting.

Temperature runs from more focused to more creative. The Factual, Default, and Creative presets provide useful starting points.

Control model access

Under Models, choose one of three Model access modes:

• Off leaves chat models unrestricted by this policy.
• Allow-list permits only the models you add to Allowed models.
• Deny-list permits models except those you add to Denied models.

Use Filter available models to find a model, then select Add or Remove. An allow-list must contain at least one model before the policy can be saved.

A ZDR badge marks each model whose provider does not retain prompts or responses after processing them. Search for zdr in the filter to narrow the list to those models. See Use zero-data-retention models.

Model access controls chat models. Use the feature sections below it to permit or restrict Bearly’s other tools.

Choose which features members can use

Under Feature access, choose how the policy handles features Bearly adds later:

• Enabled by default makes new features available automatically. New policies use this setting.
• Disabled by default keeps new features unavailable until you switch them on.

Changing this default keeps access to every current feature unchanged. It only determines the starting state of features added later.

Each feature has a standard switch. On means members can use the feature, or that the named requirement is enforced. Off means members cannot use it. The controls are arranged by the kind of work they affect:

Section	What you can manage
Web & Research	Web tools, web search, Image Search, Deep Research, People Search, X, SEO data, Domain research, Maps, and Weather
Media & Creativity	Images, video, Pages, Charts, voice, transcription, and text to speech
Code & Automation	Run Python, local work, Computer Use, Browser, Connectors, personal MCP servers, chat management, email notifications, text messages, Routines, and browser use in Routines
Collaboration	Sharing, public Page links, sharing Pages with people and teams, Screen Share, Council, and Meetings
Privacy & Security	Memory Recall, the PII Blocker, local encryption, existing-chat locking, and file uploads
Skills	Whether members can use, add, and run Skills, including Skills supplied by a policy
Projects	Project creation, password requirements, collaboration, and project documents and data
Developer	Developer API access, which lets members create API keys and call Bearly models from their own code, plus personal remote modules and staging builds

The exact controls shown can depend on the features available to your organization.

Full access eligibility is managed separately under Overview → Agent access. Only organization administrators can change its default or individual exceptions; group administrators and ordinary feature policies cannot grant it. Members must then enable Full access for each chat or separately for each routine on its device. Allowing Full access does not turn on tools disabled by a policy.

Turning off the Full access default leaves individual allowances in place. To remove eligibility for everyone, use Turn off for everyone under Agent access. This removes individual exceptions while preserving saved tool approvals and routines’ separately enabled unattended permissions. See Choose how Bearly uses external tools for the controls, confirmation and recovery steps.

Under Developer, Developer API access is on unless you turn it off, or the policy is set to Disabled by default. Turning it off hides API Keys from members and blocks their requests to the Bearly API.

Under Privacy & Security, Unitemized billing lets members choose daily totals for their own accounts.

Under Code & Automation, Browser in Routines controls whether members can let a scheduled routine use Bearly Browser while they’re away, on the sites they approve and without asking first, including clicking, typing, and submitting forms when they allow it. A routine also needs Browser on, and the switch is unavailable while Routines is off. Turning it off doesn’t affect Browser or Chrome in chats. See Let a routine use a browser.

Under Collaboration, Sharing is the master control for Page publishing. Public links permits Anyone with the link, while Share with people and teams permits restricted links for selected members and teams. To allow restricted Page links without public links, turn on Sharing and Share with people and teams, then turn off Public links. These controls do not disable the owner’s live Page preview.

Note

Some features depend on another feature. For example, Deep Research requires Web and Web search. A dependent switch is unavailable while its requirement is off.

Locking existing chats cannot be undone

Lock Existing Chats restricts affected members’ existing chats to local access. The keys are unrecoverable, and the confirmation cannot be reversed. Make sure your organization understands the effect before enabling it.

Provide MCP servers to members

Under Code & Automation, MCP Connectors controls the whole Connectors feature. Personal MCP servers controls whether members can add their own custom servers; turning it off does not remove Bearly’s built-in services or servers supplied by the policy.

Use Team MCP servers to give every member on this policy the same server definition:

1. Select Add server.
2. Choose HTTPS or npm package.
3. Enter the server name and connection details. For bearer tokens, custom headers, or npm environment variables, enter the required variable names only.
4. Select Add server, then save the policy.

The server appears automatically in each assigned member’s App Settings → Connectors. Members cannot change or remove its definition. They connect with their own OAuth account or enter their own token, header, or environment values. Those values never become part of the policy.

HTTPS servers work in desktop and mobile browsers and in the desktop app. In the iOS and Android apps, custom HTTPS servers can use a bearer token, custom headers, or no authentication. Services requiring OAuth sign-in must be connected and used in a regular browser; that connection does not carry back to the mobile app. npm servers require the desktop app. A policy does not remove these platform limits.

See Connect services and MCP servers for the member setup and runtime behavior.

Disable new features by default for every policy

On the policy list, select Disable new features by default to update every policy where new features currently start enabled. Confirm Disable by default.

Bearly preserves each policy’s current feature access. Features added later start unavailable until an administrator enables them. If a policy cannot be updated, Bearly names it so you can retry the same action safely.

Make a policy the default

The default policy is assigned automatically to new managed-domain members. To change it:

1. Open the policy you want to use.
2. Select Make Default.
3. Confirm Make Default.

Changing the default does not reassign existing members. To change an existing member, open Members, select the member, choose a Policy, and select Save.

Review or share a policy summary

Open an existing policy and select Summarize the Policy to generate a plain-language summary. If you have unsaved edits, the summary identifies that it reflects those edits.

Select Email me a copy to send the current summary to your account email. If Bearly cannot generate the summary, select Try again. An organization’s model restrictions can prevent summary generation when no suitable model is available.

Edit or delete a policy

Select a policy from the list to edit it. Bearly marks pending edits as Unsaved changes; select Save to apply them or Cancel to leave the editor.

Only a non-default policy offers Delete. Deleting a policy does not automatically move its current members to another policy: they continue using the deleted policy’s settings until an administrator changes their assignment, and the policy can appear as Inactive beside those members. Reassign them before deleting the policy if you want a clean transition.

If a policy will not save

• Check that Policy name contains 4–18 characters.
• If Model access is set to Allow-list, add at least one model or switch the mode to Off.
• If Bearly shows Failed to save policy. Please try again., keep the editor open and select Save again after checking your connection.