Tool Scope Configuration

How default and allowed scopes behave in tool settings and which precedence rules apply.

This page explains the scope model for tool settings in meinGPT, especially:

  • default* fields (e.g. defaultFolderId, defaultCalendarId)
  • allowed* fields (e.g. allowedFolderIds, allowedLabelIds)
  • Precedence between user input, defaults, and restrictions

UI Location

Scope settings are available in:

  • Settings > Assistant Integrations (admin-level tool availability/policy)
  • Assistant > Configure Tool > Scope tab

Core Model

In scope configuration, fields usually mean:

  1. default*: fallback value when no explicit scope is passed in prompt/tool call.
  2. allowed*: restriction set for permitted resources.

Practical rule of thumb:

  • No allowed* configured -> full access within OAuth/API permissions.
  • allowed* configured -> access should be limited to those resources.
  • default* configured -> preferred starting point when no explicit scope is provided.

Scope Resolution Precedence

Typical order (tool-specific):

  1. Explicit user input in tool call (e.g. specific folder ID)
  2. default* value from tool config
  3. Tool-internal fallback (e.g. Inbox, current user context)

If allowed* is configured, it acts as an upper bound and should limit the final selection.

What Matters for default vs allowed?

  1. default* is convenience, not security.
  2. allowed* is restriction.
  3. For robust boundaries, set both: choose default* values that are inside allowed*.

Examples

Google Drive

  • defaultFolderId: starting folder for list/search without explicit folder.
  • allowedFolderIds: limits access to selected folders.

Recommendation:

  • Set defaultFolderId to the primary working folder.
  • Set allowedFolderIds to approved project folders.

Gmail

  • defaultLabelIds: default labels for unspecific requests.
  • allowedLabelIds: only emails within those labels.

Outlook

  • Mail: defaultFolderId + allowedFolderIds
  • Calendar: defaultCalendarId + allowedCalendarIds

Teams

  • defaultTeamId: default team.
  • allowedTeamIds: permitted teams.
  • allowedChannelIds: additional channel restriction within allowed teams.

Important Implementation Note

Unlike method policies, scope enforcement is currently tool-specific, not fully centralized yet.

This means:

  • default*/allowed* semantics are consistently designed.
  • Runtime enforcement depends on each tool and method implementation.

Admin recommendation until full standardization:

  1. Always configure scope (default* + allowed*).
  2. Limit critical write/dangerous actions via method policy as well.
  3. Validate scope behavior for each critical tool in a test chat.

Troubleshooting

"Why do I still see full access although I configured restrictions?"

UI restriction state is based on configuration. Runtime behavior is tool-specific. Validate with the concrete tool in a test chat.

"Why are scope options not loading?"

Usually missing OAuth connection or missing prerequisite selection (e.g. choose team/site first, then load channels/spaces).

"Can I only set default*?"

Only for convenience. For real restriction, set allowed* as well.

Was this page helpful?