So sehen Sie, welche KI-Tools Zugriff auf Ihren Google Workspace haben

Sie können jedes KI-Tool mit OAuth-Zugriff auf Ihren Google Workspace über die Admin-Konsole einsehen, unter Security → Access and data control → API controls → App access control. Dort werden alle in Ihrer Domain autorisierten Drittanbieter-Apps aufgelistet – einschließlich KI-Assistenten, Browser-Erweiterungen und Meeting-Notiz-Bots – zusammen mit den Google-Daten, für die jede einzelne freigegeben wurde.

Diese Anleitung führt Sie durch diesen Pfad, zeigt, was die Konsole tatsächlich anzeigt, wo ihre Grenzen liegen und wie Sie die Liste danach aktuell halten.

Wo finde ich den Zugriff von Drittanbieter-Apps in der Google Admin-Konsole?

1. Melden Sie sich bei admin.google.com als Super-Admin oder als Admin mit der Berechtigung „Services" an.
2. Gehen Sie zu Menu → Security → Access and data control → API controls.
3. Klicken Sie auf Manage App Access (in manchen Konsolenversionen auch als App access control bezeichnet).

Sie gelangen zu einer Liste, die in Configured apps (Apps, für die Ihre Organisation ausdrücklich eine Zugriffsebene festgelegt hat) und Accessed apps (jede App, die derzeit in Nutzung ist, unabhängig davon, ob Sie sie konfiguriert haben) unterteilt ist. Für jede App sehen Sie:

• Name, Herausgeber und OAuth-Client-ID der App.
• Ob sie Googles App-Verifizierungssiegel trägt.
• Die einzelnen angeforderten Google-Dienst-Scopes – Drive, Gmail, Calendar, Admin Directory und so weiter –, die pro App aufklappbar sind.
• Wie viele Nutzer in Ihrer Domain sie autorisiert haben.
• Die Zugriffsebene, die Sie festlegen können: Trusted, Limited, Specific Google data oder Blocked.

Sie können die vollständige Liste außerdem als CSV exportieren und unterschiedliche Zugriffsebenen für verschiedene Organisationseinheiten statt für die gesamte Domain auf einmal festlegen.

Wie erkenne ich, welche dieser Apps KI-Tools sind?

Die Google-Konsole kennzeichnet nichts als „KI" – sie listet jede über OAuth verbundene App gleich auf, egal ob es sich um ein Tabellenkalkulations-Add-on oder einen Large-Language-Model-Assistenten handelt. In der Praxis tauchen KI-Tools unter Namen auf wie ein KI-Anbieter direkt (OpenAI, Anthropic, Perplexity), ein Meeting-Notiz-Bot (Otter.ai, Fireflies, Fathom), ein Schreibassistent (Grammarly, Jasper) oder ein spezielleres Add-on („GPT for Sheets and Docs", „AI Email Writer"), dessen Herausgebername keinen Hinweis auf die Funktion gibt. Sie zu erkennen ist manuelle Detektivarbeit: Überfliegen Sie App- und Herausgebernamen und prüfen Sie die angeforderten Scopes – eine App, die drive.readonly oder gmail.readonly anfordert und einen Namen trägt, den Sie nicht kennen, ist unabhängig von der Kategorie einen genaueren Blick wert.

Wie prüfe ich, welche KI-Tools eine bestimmte Person autorisiert hat?

Die domänenweite Ansicht oben zeigt Ihnen, dass eine App Nutzer hat; sie verrät jedoch nicht, *wer* sie autorisiert hat oder *wann*. Dafür gehen Sie folgendermaßen vor:

1. Gehen Sie zu Menu → Directory → Users und öffnen Sie das Konto der betreffenden Person.
2. Öffnen Sie deren Security-Tab.
3. Scrollen Sie zu Connected applications.

Dieser Bereich listet jede Drittanbieter-App auf, die dieser Nutzer autorisiert hat, zusammen mit der Zugriffsebene (den nutzbaren Scopes) und dem Autorisierungsdatum. Ein Admin mit der Berechtigung „User Security Management" kann jede dieser Freigaben direkt auf dieser Seite widerrufen. Dies ist die einzige Stelle in der Konsole, an der angezeigt wird, *wann* eine App autorisiert wurde – allerdings bedeutet das, jede Person einzeln zu prüfen, ohne Massenexport und ohne Möglichkeit, nach „nur KI-Tools" zu filtern.

Wo liegen die tatsächlichen Grenzen dieser manuellen Vorgehensweise?

Die domänenweite Ansicht „App access control" aggregiert Zahlen, verzichtet aber auf Details pro Nutzer; die Ansicht „Connected Applications" pro Nutzer liefert diese Details, aber keine Gesamtübersicht. Keine der beiden zeigt:

• Ob der Zugriff noch genutzt wird oder einmalig erteilt und dann vergessen wurde.
• Was die App tatsächlich mit den Daten getan hat, auf die sie zugreifen kann – die Konsole zeigt, worauf eine App zugreifen *kann*, nicht, worauf sie *zugegriffen hat*.
• Wie sich das Bild über die Zeit verändert hat, da es keine historische Zeitleiste hinzugekommener Freigaben oder erweiterter Scopes gibt.
• Welche der aufgelisteten Apps KI-Tools sind, sofern Sie nicht jeden Anbieternamen selbst erkennen.

Für einen Workspace mit einer Handvoll verbundener Apps ist die manuelle Durcharbeitung beider Ansichten durchaus machbar. Ab einigen Dutzend Apps und einigen Hundert Nutzern hört das Aktuellhalten der Liste auf, eine einmalige Aufgabe zu sein, und wird zu einer wiederkehrenden – dieselben Informationen, immer wieder erneut geprüft, auf unbestimmte Zeit. Und beide Ansichten erfordern eine Admin-Rolle mit der passenden Berechtigung („Services" für die domänenweite Ansicht, „User Security Management" für die Ansicht pro Nutzer) – ein Workspace mit mehreren Admins braucht trotzdem eine Person, die beides regelmäßig prüft; das ist keine Aufgabe, die zwangsläufig bei demjenigen landet, der es zufällig bemerkt.

Was kann die manuelle Ansicht nicht zeigen, und wie beantwortet 8200.dev das?

Der manuelle Weg beantwortet, *was* auf die Daten zugreifen kann. Er beantwortet nicht, *wer* den Zugriff genutzt hat, *wann* und *ob er noch benötigt wird* – die Fragen, die tatsächlich darüber entscheiden, ob eine App ihren Zugriff behalten sollte. 8200.devs Agent Guard inventarisiert jeden KI-Agenten und jede OAuth-verbundene App über Ihre verbundenen Quellen hinweg in einer kontinuierlich aktualisierten Ansicht, bewertet jede einzelne nach Risiko und erklärt den Befund in verständlicher Sprache statt in einer Scope-Zeichenfolge. Die Erkennung erfolgt schreibgeschützt: Die Verbindung zu Google Workspace nutzt einen schreibgeschützten Drive-Metadaten-Scope, und die tiefergehende OAuth-App-Inventarisierung, wie oben gezeigt, steht zur Verfügung, sobald eine Organisation das OAuth-App-Auditing aktiviert – dabei wird die Autorisierung um die zusätzlichen schreibgeschützten Admin-SDK-Scopes erweitert, die Google für diese spezifische Ansicht erfordert. Nichts davon ändert eigenständig Zugriffsrechte; jede Maßnahme bleibt eine Empfehlung, bis die Organisation sich entscheidet, danach zu handeln.

Die vollständige Connector-Liste zeigt, wie sich dies über Google Workspace hinaus auf Microsoft 365, Slack, GitHub und die KI-Anbieter selbst erstreckt.