documentation
05 settings

Security settings

The Security settings page is the operator's side of the capability model — toggles that restrict what bot widget sessions can do, whether skills need to be signed before they run, and which Composio toolkits can be installed in this workspace.

What this page is for

The Security & cloud mode admin page explains the conceptual model. This page is where you actually flip the switches. Five cards: Session Sandboxing, Skills, Bot API, Composio Governance, and Default Knowledge Base.

Session sandboxing

ToggleWhen on
Sandbox DM sessions1:1 channel conversations (Telegram DM, Slack DM) get the Channel session type’s narrower capability ceiling
Sandbox group sessionsGroup channel conversations (Discord guild, Slack channel) get the same narrower ceiling

Both default to on. Turning them off lets channel sessions run agents with their full grant set — don’t do this unless you’re running a trusted-internal channel and the agents there need tools that the Channel ceiling blocks. See Security & cloud mode for the details of what Channel sessions can and can’t do.

Skills

ToggleWhen on
Require skill signingOnly skills with a valid cryptographic signature can execute. Unsigned skills are loaded into the catalog but not available to agents until signed

Off by default for personal single-user installs. Turn it on for any multi-user deployment — skill signing closes the “unreviewed skill runs on first request” vector.

When on, newly installed skills land in the Review queues → Skill approvals queue and wait for admin sign-off. Signed skills become available immediately; unsigned ones are held until an admin reviews and approves.

Bot API (public chat widget)

Controls what widget-exposed bots can do. Defaults assume single-tenant self-hosted; for hosted/multi-tenant deployments, harden all three toggles.

ToggleWhen onOff means
Allow CLI providersBot sessions can run on Claude Code / Codex / Gemini CLICLI model picks are swapped for the anonymous fallback model
Allow full tool accessBot sessions can use any tool the bot is grantedBot sessions are restricted to web_search, web_fetch, think, discover_tools, architect only
Allow full capabilitiesFile system, shell, browser are usable from bot sessionsBot sessions are forced to cloud-safe defaults (HTTP + memory only)

The three toggles compose. A widget deployment for a public website should have all three off — that’s the safest default. An internal bot on a trusted internal site can turn them back on.

Composio governance

Exolvra’s Composio integration makes hundreds of third-party toolkits (Gmail, Slack, Linear, HubSpot, …) installable from the dashboard. This card is where the operator controls which toolkits can land in this workspace and how their cost rolls into the budget.

SettingNotes
Enforce budget on Composio actionsWhen on, Composio per-action cost counts against daily/monthly limits. Turn off for on-prem BYOK deployments where Composio bills the operator directly
Enforce toolkit allowlistWhen on, only toolkits ticked in the Allowed list can be installed
Allowed toolkitsCheckbox grid — pick the toolkits your workspace permits
Blocked toolkitsAlways enforced. Wins over the allowlist
Require approval for these actionsFully-qualified toolkit.action names that must route through Review Queues before running

The three-way pattern (allowlist, blocklist, approval list) covers most governance needs. A common pattern for a new workspace:

  • Enforce allowlist off initially (any non-blocked toolkit can install)
  • Block anything that reads personal identifiers you don’t want exposed (Gmail search, contacts lookup)
  • Require approval on anything that writes to external systems (send message, create contact, post to chat)

Once you understand what your team actually uses, flip allowlist enforcement on and move previously-used toolkits into the allowed list.

See Composio integration for the end-to-end install and use flow.

Default knowledge base

Collections ticked here are searched by every agent unless the agent or project overrides it. Use this for instance-wide knowledge — company handbook, brand voice guide, standard operating procedures — that every agent should know.

The list shows every document collection you’ve created under Documents. Tick the ones you want as defaults. Agents still see their own collections (attached on the agent or bot edit page); those layer on top.

When to use default collections:

  • Company handbook that every agent should consult
  • Style guide for consistent voice across specialists
  • Compliance rulebook that applies across every workflow

When not to use them:

  • A document specific to one project — attach it to the project instead
  • A reference only one specialist uses — attach it to that specialist
  • A big dump of miscellaneous files — noise degrades RAG quality

Fewer collections, smaller collections, curated collections. The knowledge base quality is proportional to its curation.

Common pitfalls

Running the widget with full capabilities on. The bot widget is exposed to anonymous end users. Giving anonymous users file system or shell access is a large attack surface. Turn all three Bot API toggles off before enabling a public widget.

Leaving skill signing off on a multi-user instance. One team member installing an unvetted skill can load arbitrary code into every agent. Signing closes that vector.

Defaulting to a bloated default knowledge base. Ticking every collection as a default degrades every agent’s RAG — they end up with irrelevant chunks in context. Keep the default list small; let agents pull specific collections as needed.

Confusing the Composio approval list with the Review → Approvals rules. They’re the same underlying approval system but configured here for the Composio-specific case. Don’t duplicate the rules in both places.

Where to go next