Ein KI-Agent sieht nur, was seine freigegebenen Berechtigungs-Scopes erlauben. Der Sende-Scope von Gmail kann keine Nachricht lesen; der Readonly-Scope von Drive liest jede Ihrer Dateien. Der Unterschied steckt oft in einer Zeile des Zustimmungsdialogs. Dieser Leitfaden benennt die tatsächlichen Scopes und zeigt, wie Sie Ihre eigenen prüfen.

Berechtigungs-Scopes entscheiden über Ihre Offenlegung. Nicht das Modell, nicht die Sicherheitsseite des Anbieters — sondern die konkreten Zeichenketten, die Sie mit einem Klick auf „Zulassen" freigegeben haben.

Diese Entscheidung fällt meist in einer Sekunde und wird nie wieder geprüft. Zwei Scopes können auf einem Zustimmungsdialog eine Zeile auseinanderliegen, fast gleich klingen und sich um alles unterscheiden: ein Dokument gegen jede Datei im Konto.

Die Sorge dahinter ist verbreitet und messbar. Von den EU-Unternehmen ab 10 Beschäftigten, die den Einsatz von KI jemals erwogen haben, nennen 52,72 % Bedenken wegen Verletzungen des Datenschutzes und der Privatsphäre als Grund, sie nicht einzusetzen. Sie ist auch beantwortbar, und die Antwort steht in Ihren eigenen Kontoeinstellungen — meist in weniger als fünf Minuten.

Zur grundlegenden Unterscheidung zwischen Modell, Agent und Workflow beginnen Sie mit was ein KI-Agent ist.

Was kann ein Agent wirklich sehen?

Drei Grenzen bestimmen die Reichweite eines Agenten:

  • Scope — welche Berechtigungen Sie erteilt haben.
  • Identität — unter welchem Konto der Agent handelt.
  • Mitgliedschaft — zu welchen Dateien, Kanälen oder Bereichen er ausdrücklich hinzugefügt wurde.

Gmail: Lesen und Senden sind getrennt

Hier sind die tatsächlichen Gmail-Scopes, so wie Google sie dokumentiert.

Gmail-ScopeWas er gewährtKann lesenKann senden
gmail.metadataLabels und Kopfzeilen, nicht den NachrichtentextTeilweiseNein
gmail.readonlyNachrichten und Einstellungen ansehenJaNein
gmail.labelsLabels sehen und bearbeitenNeinNein
gmail.sendIn Ihrem Namen sendenNeinJa
gmail.composeEntwürfe verwalten und sendenJaJa
gmail.modifyLesen, verfassen, senden; kein endgültiges LöschenJaJa
https://mail.google.com/Vollzugriff einschließlich endgültigem LöschenJaJa

Die Trennung von Lesen und Senden ist der nützliche Teil. Ein Outreach-Workflow, der mit gmail.readonly liest und mit gmail.send sendet, hält zwei schmale Berechtigungen statt einer breiten. Ein Agent mit gmail.modify hat beide Fähigkeiten und zusätzlich die Möglichkeit, im Postfach alles zu verändern.

Google Drive: eine Datei oder das ganze Konto

Google Drive funktioniert genauso, und der Abstand zwischen zwei seiner Scopes ist der größte im verbreiteten Gebrauch.

Drive-ScopeWas er gewährt
drive.fileNur Dateien, die die App angelegt hat oder die Sie ausdrücklich mit ihr geöffnet haben
drive.metadata.readonlyNur Metadaten, keine Inhalte
drive.readonlyJede Datei im Drive ansehen und herunterladen
driveVollständiger Lese- und Schreibzugriff auf das gesamte Drive

Ein Agent, der eine Tabelle braucht, sollte drive.file halten. Mit drive.readonly liest derselbe Agent Ihre Verträge, Ihren Personalordner und jedes Dokument, das je jemand mit Ihnen geteilt hat.

Eine Aufgabe, zwei Berechtigungen

Enger Zugriff

drive.file
01

Der Agent erreicht nur Dateien, die er angelegt hat oder die Sie ausdrücklich mit ihm geöffnet haben.

Kontoweiter Zugriff

drive.readonly
02

Der Agent kann jede Datei im verbundenen Drive ansehen und herunterladen.

Die Aufgabe ist identisch.

Die Offenlegung nicht.

Slack: Scope und Kanalmitgliedschaft zählen

Slack fügt eine zweite Grenze hinzu, die die meisten Erklärstücke übersehen. Die Verlaufs-Scopes sind zusätzlich durch die Kanalmitgliedschaft begrenzt: channels:history gewährt Nachrichten in öffentlichen Kanälen, „zu denen Ihre Slack-App hinzugefügt wurde". Der Scope setzt die Obergrenze; die Mitgliedschaft setzt die tatsächliche Reichweite.

Slack-ScopeGewährtKlasse
channels:readBasisinformationen zu öffentlichen KanälenLesen
channels:historyNachrichten in Kanälen, zu denen die App hinzugefügt wurdeLesen
im:historyDirektnachrichten, zu denen die App hinzugefügt wurdeLesen
files:readDateien in Unterhaltungen, zu denen die App hinzugefügt wurdeLesen
users:readPersonen im WorkspaceLesen
chat:writeNachrichten als App sendenSchreiben

Warum sind Berechtigungen wichtiger als das Modell?

Das Risiko einer Agenten-Umsetzung liegt im Zugriff, nicht in der Intelligenz. Ein überprivilegierter Agent mit einem schwachen Modell kann mehr offenlegen als ein sauber abgegrenzter Agent mit dem besten verfügbaren Modell.

Nicht der Agent ist das Risiko. Die Berechtigungen sind es, die Sie ihm gegeben haben.

Das häufige Problem ist passender, aber zu breiter Zugriff

Das Versagensmuster ist selten dramatisch.

Eine Prüfung von 2.890 öffentlichen OAuth-App-Einträgen in den Marktplätzen von Google Workspace und GitHub fand 918 — rund 32 % — mit mindestens einem strukturellen Risikosignal. Weitere 677 forderten mindestens eine Berechtigung über ihre angegebene Funktion hinaus an.

Philip Shteyn, CTO von Offroad, das hinter dem OAuth-Forschungsprojekt OhAuth steht, beschrieb das Muster der Prüfung vom Juni 2026 so:

Bei den meisten Fällen fordern Apps keinen völlig willkürlichen Zugriff an. Sie fordern Zugriff an, der zu ihrer Aufgabe passt, aber viel breiter ist als nötig.

Bei Google Workspace fielen rund 90 % der markierten Fälle in diese Gruppe richtige Kategorie, zu viel Zugriff.

Die Prüfung betrifft Marktplatz-Apps, nicht KI-Agenten, und der Herausgeber verkauft Identitätssicherheit. Die Zahlen sind daher als Richtung zu lesen.

Das Muster ist hier entscheidend. Niemand erteilt einem E-Mail-Tool aus Bosheit Zugriff auf Drive. Man erteilt drive.readonly, wo drive.file gereicht hätte, weil der breitere Scope schneller funktioniert und der Zustimmungsdialog den Unterschied nicht deutlich macht.

Agentensysteme können unnötige Rechte erben

OWASP führt dieses Risiko an dritter Stelle. In den peer-reviewten OWASP Top 10 for Agentic Applications 2026 lautet Eintrag ASI03 Identity and Privilege Abuse. Der Bericht erschien am 9. Dezember 2025 mit mehr als 100 Mitwirkenden.

Die Diagnose ist präzise:

Ohne eine eigene, geregelte Identität bewegt sich ein Agent in einer Zurechnungslücke, die echtes Least Privilege undurchsetzbar macht.

OWASP benennt auch den Mechanismus, der in mehrstufigen Systemen zu Überprivilegierung führt: un-scoped privilege inheritance — eine hoch privilegierte Komponente delegiert eine Aufgabe und gibt dabei ihren vollständigen Zugriffskontext weiter, sodass ein eng zugeschnittener Arbeitsschritt überschüssige Rechte erhält.

Ältere Leitfäden verwenden noch den früheren Namen Excessive Agency. OWASP stellt fest, dass ASI03 „die agentische Weiterentwicklung von Excessive Agency (LLM06:2025)" ist.

Wer noch vor Excessive Agency warnt, arbeitet mit der überholten Taxonomie.

Nur-Lesen ist schmaler, nicht automatisch sicher

Einen Agenten auf Lese-Scopes zu beschränken, nimmt ihm die Fähigkeit zu handeln. Es nimmt ihm nicht die Anfälligkeit dafür, durch das beeinflusst zu werden, was er liest.

Das Office of the CISO von Google Cloud beschreibt den Weg direkt. Agenten seien anfällig für „Jailbreaks" — geschickte Eingaben, die ihre Schutzmechanismen umgehen und vertrauliche Informationen offenlegen sollen.

Das ausgeführte Beispiel ist ein Agent, der E-Mails zusammenfasst. Er erhält eine Jailbreak-Eingabe, die ihn dazu bringt, vertrauliche Informationen an einen unbefugten Empfänger weiterzugeben.

Lesezugriff nimmt weiterhin nicht vertrauenswürdige Eingaben an

Was ein Agent liest, ist nicht vertrauenswürdige Eingabe. Eine E-Mail, ein geteiltes Dokument oder eine Kalendereinladung kann Anweisungen enthalten, die sich an den Agenten richten und nicht an Sie. Der Lese-Scope bestimmt, was die Anweisung erreichen kann; er verhindert nicht, dass sie ankommt.

Deshalb sind Abgrenzung und Freigabe zwei Kontrollen und nicht eine. Schmale Scopes begrenzen den Wirkungsradius. Ein Gate vor ausgehenden Aktionen begrenzt, was ein beeinflusster Agent mit dem Gefundenen anfangen kann.

Least Privilege gilt für Agenten wie für Menschen: Der Agent erhält das Mindestmaß an Zugriff für seine Aufgabe — und nichts darüber hinaus. Eine Tool-Verbindung ohne widerrufbaren, protokollierten Berechtigungs-Scope ist eine offene Tür. Und Nur-Lese-Zugriff ist eine kleinere Tür, keine geschlossene.

Welche drei Kontrollen entscheiden über die Offenlegung?

Das Office of the CISO von Google Cloud stützt Agentensicherheit auf drei klassische Kontrollen. Anton Chuvakin, Security Advisor in diesem Bereich, benennt sie als Authentifizierung, Autorisierung und Nachvollziehbarkeit.

KontrolleBedeutung für einen AgentenIn der Praxis
AuthentifizierungJeder Agent hat eine eigene Identität, sodass überprüfbar ist, dass er das ist, was er zu sein vorgibtEin eigenes Konto für den Agenten, kein persönlicher Login
AutorisierungNur das Mindestmaß an Zugriff, das er für seine Aufgabe braucht, und nicht mehrdrive.file statt drive.readonly; gmail.send statt gmail.modify
NachvollziehbarkeitJede Aktion protokollieren — ein klarer Nachweis, ein Audit-TrailEin Protokoll je Aktion mit Tool, Daten und Ergebnis

Die Authentifizierung ist die Kontrolle, die kleine Umsetzungen am häufigsten verfehlen. Ein Agent, der über die OAuth-Freigabe einer Person handelt, erbt alles, was diese Person sehen kann.

Er wird zugleich schwer nachverfolgbar, weil jede Aktion im Protokoll dem Menschen zugeordnet wird. Ein eigenes Konto macht beides möglich — Abgrenzung und Zurechnung.

Dieselbe Aufgabe zweimal: links ein Agent mit drive.file, der ein Dokument erreicht, rechts derselbe
Gleiche Aufgabe, zwei Scopes. Der Scope entscheidet über die Offenlegung, nicht die Arbeitslast.

Wo das Gate sitzt

Wo das Gate sitzt, ist eine Entscheidung getrennt davon, worauf der Agent zugreifen darf. In YardWork-Umsetzungen ist Lesezugriff die Voreinstellung. Sendevorgänge und andere Aktionen mit hoher Auswirkung sitzen hinter einer im Code verankerten Freigabe statt hinter einer Anweisung im Prompt.

Der Agent hält die Sendefähigkeit, aber nichts geht hinaus, bevor eine Person den Vorgang geprüft und freigegeben hat. Das beschreibt die je Projekt abgegrenzte Umsetzungspraxis. Es ist keine Sicherheitsgarantie, kein Audit und keine Zertifizierung.

Prompt und Code

Entscheidend ist der Unterschied zwischen Prompt und Code. Eine Anweisung, die einem Modell sagt, es solle nicht senden, ist eine Präferenz, die es verfehlen kann. Ein Gate im Ausführungspfad ist eine Bedingung, an der es nicht vorbeikommt.

Der Eigentümer was Freigabe-Workflows leisten behandelt das Verhalten dieser Gates. KI-Agenten-Governance behandelt den weiteren Kontrollentwurf.

Was bleibt nach der Aufgabe zurück?

Die Berechtigungen eines Agenten beschreiben, was er erreichen kann. Sie sagen nichts darüber, was er behält.

Die spanische Datenschutzbehörde AEPD hat das in Agentic Artificial Intelligence from the Perspective of Data Protection (V1.1, Februar 2026) direkt aufgegriffen. Das Gedächtnis des Agenten speichert personenbezogene Daten. Seine Protokolle können noch weiter reichen:

Die Protokolle speichern Informationen sowohl über die Nutzer der agentischen KI als auch über die von der Verarbeitung betroffenen Personen; es können sogar Daten über Personen gespeichert werden, die nicht betroffen sein sollten.

Drei Orte halten Daten nach einem Lauf:

  1. Arbeitskontext — das Material, das der Agent für die Aufgabe herangezogen hat.
  2. Langzeitgedächtnis — Zusammenfassungen, Profile und Embeddings, die bestehen bleiben, damit der Agent nicht neu gebrieft werden muss.
  3. Protokolle — der Audit-Trail, der selbst ein Speicher personenbezogener Daten ist.

Die AEPD empfiehlt getrennte Aufbewahrungsfristen je Kategorie statt einer globalen Regel. Sie empfiehlt außerdem, persistentes Gedächtnis abschalten zu können, wenn die Verarbeitung es nicht braucht.

Die praktische Frage: Welche der drei Ebenen existiert in Ihrer Umsetzung, und wie lange wird jede aufbewahrt?

„Wir löschen nichts" ist eine verbreitete und ehrliche Antwort. Es ist auch eine Entscheidung — ob sie jemand bewusst getroffen hat oder nicht.

Daten verlassen die Umgebung außerdem. Modellanbieter, Anreicherungs-APIs sowie Übersetzungs- und Zusammenfassungsdienste erhalten jeweils das, was der Agent ihnen schickt. Fällt Ihr Unternehmen unter die DSGVO, tragen diese Empfänger und jede Übermittlung außerhalb der EU eigene Pflichten — der Leitfaden zu DSGVO und KI-Agenten ordnet jeder Aktion den berührten Artikel zu.

Wie prüfen und entziehen Sie Zugriffe?

Zugriffe zu prüfen und zu entziehen ist der Teil, den Sie heute erledigen können, ohne jemanden zu fragen.

1

Verbindungen inventarisieren

Öffnen Sie die Einstellungen für Drittanbieter-Zugriff Ihres Kontos. Im Google-Konto ist das der Bereich für Drittanbieter-Apps und -Dienste, in Slack die Liste der installierten Apps des Workspace. Jede verbundene App wird mit ihren Scopes aufgeführt.

2

Die Scopes lesen, nicht den App-Namen

Ein Tool namens „Meeting-Notizen" kann drive.readonly halten. Vergleichen Sie jeden erteilten Scope mit dem, was das Tool für seine Aufgabe braucht.

3

Nach dem Konto fragen

Läuft der Agent über den Login einer Person, erbt er deren Reichweite, und seine Aktionen werden ihr zugerechnet. Ein eigenes Konto behebt beides.

4

Das Gate finden

Klären Sie, welche Aktionen unbeaufsichtigt laufen und welche eine Person erfordern. Lautet die Antwort „der Prompt sagt ihm, er soll es nicht tun", gibt es kein Gate.

5

Veraltetes entziehen

Entfernen Sie Verbindungen zu Tools, die nicht mehr genutzt werden. Ein Entzug stoppt künftigen Zugriff; er löscht keine bereits vorhandenen Daten. Fragen Sie danach getrennt.

6

Einen Wiedervorlagetermin setzen

Berechtigungen driften, wenn sich Workflows ändern. Eine für eine Aufgabe erteilte Verbindung überlebt diese Aufgabe meist.

Ein sechsstufiger Kreislauf: inventarisieren, Scopes lesen, Identität prüfen, Gate finden, veraltete
Zugriffsprüfung ist eine wiederkehrende Schleife, kein einmaliges Audit vor dem Start.

Welche Fragen sollten Sie vor dem Verbinden eines Tools stellen?

Nützlich sind die Fragen, deren Antworten sich später überprüfen lassen.

  • Welche Scopes fordert diese Integration genau an? Fragen Sie nach der Zeichenkette, nicht nur danach, ob sie „auf Drive zugreift". Kann der Anbieter das nicht sagen, ist auch das eine Antwort.
  • Geht es mit einem schmaleren Scope? drive.file reicht oft für ein Tool, das nur die übergebenen Dokumente braucht.
  • Unter welcher Identität handelt sie? Achten Sie auf ein eigenes Konto statt auf den persönlichen Login einer Person.
  • Was wird protokolliert, und kann ich es lesen? Ein Protokoll, das Sie nicht einsehen können, schafft keine Nachvollziehbarkeit.
  • Welche Dritten erhalten die Daten? Dazu gehören Modellanbieter, Anreicherungsdienste und alles, was der Agent während der Aufgabe aufruft.
  • Was wird aufbewahrt, und wie lange? Arbeitskontext, Langzeitgedächtnis und Protokolle sind drei getrennte Antworten.
  • Wie entziehe ich den Zugriff, und was geschieht mit bereits vorhandenen Daten? Entzug und Löschung sind verschiedene Vorgänge.

Häufig gestellte Fragen

Kann ein KI-Agent alles in meinem Postfach sehen?

Nur wenn Sie einen Scope freigegeben haben, der das erlaubt. Der Scope gmail.readonly erlaubt das Ansehen von Nachrichten und Einstellungen. Der Scope gmail.metadata erlaubt Labels und Kopfzeilen, aber nicht den Nachrichtentext. Der Scope gmail.send erlaubt das Senden und kann das Postfach überhaupt nicht lesen. Was der Agent sieht, bestimmt Ihre Freigabe, nicht das Können des Agenten.

Was ist der Unterschied zwischen Lese- und Schreibzugriff bei einem KI-Agenten?

Lesezugriff lässt den Agenten Informationen abrufen. Schreibzugriff lässt ihn Dinge ändern oder anlegen, und Senderechte lassen ihn außerhalb Ihrer Organisation handeln. In den meisten Tools sind das getrennte Berechtigungen. Gmail behandelt das Senden als eigenen Scope, sodass ein Agent senden darf, ohne lesen zu dürfen — oder umgekehrt.

Wie prüfe ich, welche Berechtigungen ich einem KI-Tool erteilt habe?

Öffnen Sie die Einstellungen für Drittanbieter-Zugriff Ihres Kontos — bei Google ist das der Bereich für Drittanbieter-Apps im Google-Konto, bei Slack die Liste der installierten Apps des Workspace. Jede verbundene App führt die erteilten Scopes auf. Vergleichen Sie diese Liste mit dem, was das Tool für seine Aufgabe braucht.

Was bedeutet Least Privilege bei einem KI-Agenten?

Least Privilege bedeutet, dass der Agent die schmalste Berechtigung hält, mit der die Aufgabe noch gelingt — und nichts darüber hinaus. Das Office of the CISO von Google Cloud definiert es als das Mindestmaß an Zugriff, das ein Agent für seine Aufgabe braucht, und nicht mehr. In der Praxis heißt das: drive.file statt drive.readonly, wenn der Agent nur ein Dokument braucht.

Ist diese Seite eine Sicherheitsgarantie?

Nein. Diese Seite erklärt, wie Berechtigungs-Scopes funktionieren und wie Sie Ihre eigenen prüfen. Sie ist kein Audit, keine Zertifizierung und keine Garantie für ein Produkt oder eine Umsetzung, auch nicht für die von YardWork. Scope-Definitionen ändern sich zudem; prüfen Sie die aktuelle Dokumentation, bevor Sie sich auf ein bestimmtes Verhalten verlassen.

Quellen

  1. Gmail API — Choose Auth Scopes, Entwicklerdokumentation von Google Workspace, abgerufen am 11. August 2026. Quelle für alle Gmail-Scopes und die genannten Berechtigungen.
  2. Google Drive API — API-specific authorization, abgerufen am 11. August 2026. Quelle für alle Drive-Scopes und die genannten Berechtigungen.
  3. Slack — Scopes reference, abgerufen am 11. August 2026. Quelle für die Slack-Bot-Scopes und die Einschränkung durch Kanalmitgliedschaft.
  4. OWASP Top 10 for Agentic Applications 2026, veröffentlicht am 9. Dezember 2025, peer-reviewed mit mehr als 100 Mitwirkenden; vollständiges PDF abgerufen am 11. August 2026. Quelle für ASI03 „Identity and Privilege Abuse", un-scoped privilege inheritance und das Verhältnis zu Excessive Agency (LLM06:2025). Zitate sind aus dem englischen Original übersetzt.
  5. Google Cloud Office of the CISO, „AI agent security: How to protect digital sidekicks (and your business)", Anton Chuvakin, 13. September 2025, abgerufen am 11. August 2026. Quelle für Authentifizierung, Autorisierung und Nachvollziehbarkeit sowie das Jailbreak-Beispiel. Anbieterpublikation, entsprechend gekennzeichnet. Zitate übersetzt.
  6. AEPD, Agentic Artificial Intelligence from the Perspective of Data Protection, V1.1, Februar 2026, abgerufen am 11. August 2026. Quelle für die Passage zu Gedächtnis und Protokollen und für die Empfehlungen zur Aufbewahrung. Leitlinien der AEPD sind in Spanien maßgeblich und im übrigen EU-Raum überzeugend, aber nicht bindend. Zitate übersetzt.
  7. OAuth-Marktplatzprüfung durch OhAuth, das Forschungsprojekt des Identitätssicherheits-Unternehmens Offroad, geleitet von CTO Philip Shteyn, berichtet von Help Net Security, 4. Juni 2026. Eine Momentaufnahme von 2.890 öffentlichen Marktplatz-Einträgen. Der Primärbericht war zum Redaktionszeitpunkt nicht eigenständig einsehbar, und der Herausgeber verkauft Produkte für Identitätssicherheit; die Zahlen sind als Richtungsangabe der Branche zitiert, nicht als Primärforschung, und sie betreffen Marktplatz-Apps, nicht KI-Agenten.
  8. Eurostat, Datensatz isoc_eb_ai, abgerufen über die Eurostat-Verbreitungs-API am 11. August 2026; Datensatz zuletzt aktualisiert am 15. Juni 2026. Indikator E_AI_BCDP, Einheit PC_ENT_AI_EC, geo=EU27_2020, size_emp=GE10, nace_r2=C10-S951_X_K, time=2025: 52,72 %. Der Nenner sind Unternehmen, die den Einsatz einer der gemessenen KI-Technologien jemals erwogen haben; der Datensatz misst ein Spektrum von KI-Technologien, nicht Agenten.
  9. Die Prüfschleife, die Scope-Vergleiche und der Fragenkatalog für Anbieter sind Arbeitsergebnisse von YardWork. Scope-Definitionen ändern sich; prüfen Sie die aktuelle Anbieterdokumentation, bevor Sie sich auf ein bestimmtes Verhalten verlassen. Dieser Leitfaden ist keine Sicherheitsbewertung, kein Audit und keine Zertifizierung.