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:

  1. default*: Standardwert, wenn im Prompt/Tool-Call kein expliziter Scope mitgegeben wird.
  2. 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):

  1. Explizite Nutzerangabe im Tool-Call (z.B. konkrete Folder-ID)
  2. default*-Wert aus der Tool-Konfiguration
  3. 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?

  1. default* ist Komfort, kein Sicherheitsmechanismus.
  2. allowed* ist Restriktion.
  3. 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:

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

Troubleshooting

"Warum sehe ich Vollzugriff, obwohl ich etwas gesetzt habe?"

Die UI zeigt Restriktionsstatus basierend auf Konfiguration. Die tatsächliche Laufzeitwirkung ist tool-spezifisch. Prüfe das konkrete Tool im Testchat.

"Warum lädt die Scope-Auswahl keine Optionen?"

Meist fehlt eine aktive OAuth-Verbindung oder erforderliche Vorbedingung (z.B. erst Team/Site auswählen, dann Channels/Spaces laden).

"Soll ich nur default* setzen?"

Nur für Komfort. Für echte Begrenzung zusätzlich allowed* setzen.

War diese Seite hilfreich?