Scope-Konfiguration für Tools

Wie default- und allowed-Scopes in Tool-Einstellungen wirken und welche Priorität bei der Auflösung gilt.

Diese Seite erklärt das Scope-Modell für Tool-Einstellungen in meinGPT, insbesondere:

default*-Felder (z.B. defaultFolderId, defaultCalendarId)
allowed*-Felder (z.B. allowedFolderIds, allowedLabelIds)
Priorität zwischen Nutzer-Input, Defaults und Restriktionen

UI-Ort

Scope-Einstellungen findest du in:

Settings > Verbindungen – hier legst Du Deine eigenen default*/allowed*-Werte fest. Diese Konfiguration gilt für das Tool überall dort, wo Du es nutzt, auch direkt in einem Chat ohne Assistenten.
Settings > Tool-Verwaltung (Admin-Freigaben auf Tool-Ebene)
Assistent > Tool konfigurieren > Tab Bereich – eine zusätzliche Einschränkung (scopeOverride), die nur für den jeweiligen Assistenten gilt und die Werte aus Verbindungen weiter eingrenzen kann. Für einen Konnektor, der direkt in einem Chat ohne Assistenten genutzt wird, gibt es diese zusätzliche Einschränkung nicht – dort zählt allein die Konfiguration aus Verbindungen.

Grundmodell

In der Scope-Konfiguration haben Felder üblicherweise diese Bedeutung:

default*: Standardwert, wenn im Prompt/Tool-Call kein expliziter Scope mitgegeben wird.
allowed*: Restriktionsmenge für erlaubte Ressourcen.

Praktische Faustregel:

Kein allowed* gesetzt -> Vollzugriff innerhalb der OAuth/API-Berechtigungen.
allowed* gesetzt -> Zugriff soll auf diese Ressourcen begrenzt werden.
default* gesetzt -> wird als bevorzugter Startpunkt genutzt, wenn kein expliziter Scope angegeben ist.

Priorität bei der Auflösung

Typische Reihenfolge (tool-spezifisch):

Explizite Nutzerangabe im Tool-Call (z.B. konkrete Folder-ID)
default*-Wert aus der Tool-Konfiguration
Tool-interner Fallback (z.B. Inbox, aktueller Benutzerkontext)

Wenn allowed* gesetzt ist, gilt es als oberes Limit und sollte die endgültige Auswahl einschränken.

Was ist bei `default` vs. `allowed` wichtig?

default* ist Komfort, kein Sicherheitsmechanismus.
allowed* ist Restriktion.
Für verlässliche Begrenzung sollten immer beide gesetzt werden: default* innerhalb von allowed*.

Beispiele

Google Drive

defaultFolderId: Startordner für Listen/Suchen ohne expliziten Ordner.
allowedFolderIds: Beschränkt den Zugriff auf ausgewählte Ordner.

Empfehlung:

Setze defaultFolderId auf den Hauptarbeitsordner.
Setze allowedFolderIds auf die freigegebenen Projektordner.

Gmail

defaultLabelIds: Standard-Labels bei unspezifischen Abfragen.
allowedLabelIds: Nur E-Mails innerhalb dieser Labels.

Outlook

Mail: defaultFolderId + allowedFolderIds
Kalender: defaultCalendarId + allowedCalendarIds

Teams

defaultTeamId: Standard-Team.
allowedTeamIds: erlaubte Teams.
allowedChannelIds: zusätzliche Einschränkung auf Kanäle innerhalb der erlaubten Teams.

Für Outlook und Teams gelten diese Felder ausschließlich auf Verbindungsebene (Settings > Verbindungen) — sie lassen sich nicht zusätzlich pro Assistent einschränken, anders als bei Google Drive, OneDrive und SharePoint.

SharePoint

defaultSiteId: Standard-Site, wenn im Tool-Call keine Site explizit angegeben wird.
allowedSiteIds (UI-Label „Restrict to Sites“): Beschränkt den Zugriff auf ausgewählte SharePoint-Sites.

Achtung

Die Einheit der Restriktion ist bei SharePoint die Site, nicht der Ordner. Anders als bei Google Drive und OneDrive (allowedFolderIds) lässt sich der SharePoint-Connector nicht auf einen einzelnen Unterordner innerhalb einer Site einschränken — nur auf ganze Site(s). Für eine echte Unterverzeichnis-Beschränkung mit Garantie, dass kein weiterer SharePoint-Inhalt eingebunden wird, ist eine Datenquelle mit SharePoint als Quelle der richtige Weg, nicht der native Connector.

Wichtiger Implementierungs-Hinweis

Anders als bei Method-Policies ist Scope-Enforcement aktuell noch tool-spezifisch implementiert, nicht vollständig zentralisiert.

Das bedeutet:

Semantik von default*/allowed* ist einheitlich designt.
Die konkrete Laufzeitdurchsetzung hängt vom jeweiligen Tool und dessen Methodenimplementierung ab.

Admin-Empfehlung bis zur vollständigen Vereinheitlichung:

Scope immer konfigurieren (default* + allowed*).
Kritische Write/Dangerous-Methoden zusätzlich über Method-Policy begrenzen.
Scope-Verhalten pro wichtigem Tool einmal in einem Testchat validieren.