---
title: "Scope-Konfiguration für Tools"
description: "Wie default- und allowed-Scopes in Tool-Einstellungen wirken und welche Priorität bei der Auflösung gilt."
canonical_url: "https://meingpt.com/docs/platform/tool-scope-policy"
language: de
---

# Scope-Konfiguration für Tools

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.

**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](/docs/integrations/data-pools-rag) der richtige Weg, nicht der native Connector.

## Wichtiger Implementierungs-Hinweis

Anders als bei [Method-Policies](/docs/admin-guide/tool-access-policy) 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](/docs/admin-guide/tool-access-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.