Eine entzogene Berechtigung kann einem KI-Assistenten noch nützen, nachdem die ursprüngliche Anwendung das Öffnen der Datei verweigert. Erkennt ein Suchindex weiterhin die gestrige Gruppenmitgliedschaft an, kann eine Frage das Dokument in den Modellkontext bringen. Niemand muss wissen, dass es existiert: Schon eine Zusammenfassung oder ein Vergleich kann Inhalte offenlegen.
Amazon Quicks Ankündigung vom 7. Oktober 2026 setzt an dieser Zeitspanne an. Vor der Generierung werden ausgewählte Dokumente an ihrer Quelle geprüft. AWS kombiniert gespeicherte Zugriffskontrolllisten, kurz ACLs, mit einer zweiten Live-Entscheidung. Das ändert die letzte Instanz für den Dokumentzugriff, macht aber weder jede Bedrock-Wissensbasis live-geprüft noch Suchfilter zur Benutzerauthentifizierung.
Zwei Schranken zwischen Suche und Modell
Übliche Aufnahmeprozesse kopieren Dokumente und Berechtigungen in einen Suchindex. Bei einer Anfrage bestimmen semantische Relevanz und gespeicherte ACL-Metadaten die zurückgegebenen Passagen. Das ist effizient, doch der Berechtigungsstand stammt aus der letzten erfolgreichen Synchronisierung und muss nicht dem aktuellen Zustand entsprechen.
Quick behält diese schnelle erste Stufe bei. Es sucht relevante Passagen, filtert anhand indexierter ACLs und validiert die verkleinerte Kandidatenmenge über die Quell-API. Ein Dokument, das die Live-Prüfung nicht besteht, entfällt selbst bei weiterhin erlaubendem Indexeintrag. Nur Passagen, die beide Stufen passieren, erreichen das Sprachmodell.
Das ist eine Prüfung ausgewählter Dokumente während der Anfrage, keine ständige Synchronisierung aller Repository-Berechtigungen. Weniger Kandidaten begrenzen Remote-Aufrufe und Latenz. Der ursprüngliche Index beeinflusst allerdings weiterhin, welche Dokumente Kandidaten werden. Die abschließende Prüfung behebt deshalb nicht automatisch sämtliche Suchauslassungen.
Im Google-Drive-Beispiel verwendet Quick administrativ bereitgestellte Dienstkonto-Zugangsdaten, um durch Nutzer-Impersonation individuelle Zugriffstokens zu beziehen. Drive bleibt für die aktuellen Rechte maßgeblich. Die Quick-Identität muss zum richtigen Google-Workspace-Nutzer passen; Delegationsdaten, Token-Verarbeitung und administrative Privilegien werden sicherheitskritische Teile des Suchpfads.
SharePoint nutzt einen anderen Identitätsablauf. Bei einer ACL-fähigen Wissensbasis fordert Quick zur Anmeldung auf, sobald geschützter Inhalt relevant wird, und prüft Kandidaten anschließend über delegierten Zugriff. Laut AWS ist dies normalerweise eine einmalige Anmeldung; das zugehörige Refresh-Token hält ungefähr 90 Tage. Das bedeutet nicht, dass jedes Access-Token 90 Tage gültig ist.
Die delegierten Bereiche umfassen das Lesen von Websiteelementen und Dateien, das grundlegende Nutzerprofil und das Aufrechterhalten genehmigten Zugriffs. Die administrativ verwaltete Aufnahme-App kann separat Verzeichnis- und Gruppenleserechte sowie Zugriff auf ausgewählte oder umfangreichere SharePoint-Websites benötigen. Das sind unterschiedliche Anwendungen und Aufgaben. Genehmigungen für die Aufnahme sind nicht mit der delegierten Abfrageprüfung gleichzusetzen.
Hinzu kommt eine folgenreiche Einrichtungsvorgabe: Die ACL-Verwaltung muss bei Erstellung der SharePoint-Wissensbasis aktiviert werden und lässt sich danach nicht ändern. Wer sie auslässt, benötigt eine neue Wissensbasis – einschließlich Auswirkungen auf Neuindexierung, Einführung und Abnahmetests.
Warum kopierte Berechtigungen nicht immer reichen
Unternehmensrechte sind keine flache Liste. SharePoint kombiniert Websites, Gruppen, Vererbung und Ausnahmen. Drive verbindet persönliche Dateien, geteilte Ablagen, direkte Freigaben, Gruppen und organisationsweite Einstellungen. Confluence ergänzt Bereiche, Seitenbeschränkungen und geerbten Zugriff. Die Übersetzung in einen einzigen Index schafft Zuordnungs- und Aktualitätsrisiken.
Wird jemand unmittelbar nach einem Crawl aus einer vertraulichen Strategiegruppe entfernt, können kopierte Metadaten den Zugriff bis zur nächsten erfolgreichen Synchronisierung weiter gestatten. Ereignisbasierte Updates verkürzen manche Lücken, können aber nicht auf nie empfangene Ereignisse reagieren. AWS weist insbesondere darauf hin, dass manche Änderungen von Confluence-Gruppenmitgliedschaften nicht immer verwertbare Ereignisse erzeugen. Auch neue Freigabeverfahren können der Konnektorlogik vorauslaufen.
RAG verschärft die Folgen, weil es Passagen aus mehreren Repositories zusammenführt. Öffentliche Projektinformationen können mit einem geschützten Budget oder einer Personalentscheidung kombiniert werden. Nachträgliches Filtern ist ein schwacher Ersatz: Das Modell hat die Information bereits erhalten. Quellenverweise, Folgefragen, Exporte und agentengesteuerte Aktionen brauchen dieselbe Grenze vor der Generierung.
Live-Entscheidungen der Quelle reduzieren den Zwang, jede Berechtigungsregel im Index exakt nachzubilden. Eine zu großzügige Freigabe in der Quelle reparieren sie nicht. Eine vertrauliche Datei in einem breit geteilten Ordner besteht ihre tatsächliche Zugriffspolitik weiterhin. Minimale Rechte, klare Repository-Verantwortung, Zugriffsprüfungen und das Entziehen von Rechten beim Austritt bleiben nötig.
Erlaubter Zugriff macht Inhalte zudem nicht vertrauenswürdig. Ein Dokument kann bösartige Anweisungen für den Assistenten enthalten. Bedrock Guardrails, Grounding-Prüfungen, Sicherheitsrichtlinien und Werkzeugbeschränkungen adressieren andere Risiken. Sie verstehen nicht automatisch Dokumentrechte; korrekte ACLs beseitigen keine indirekte Prompt Injection.
Der Produktname beschreibt nicht die Konnektorabdeckung
Quick dokumentiert Integrationen für S3, Confluence, Google Drive, OneDrive, SharePoint und authentifizierte Webinhalte mit unterschiedlichen OAuth- und Dienstkontomustern. Eine verfügbare Integration beweist keine identische Live-Prüfung in jedem Konnektor und jeder Konfiguration. Die Ankündigung betont SharePoint, Drive und Confluence, ihre detaillierten Abläufe betreffen vor allem Drive und SharePoint.
Administrativ verwaltete, nutzerverwaltete und eigene Konfigurationen müssen deshalb getrennt betrachtet werden. Ein unterstützter Quellenname allein klärt weder die Identität noch Live- gegenüber Indexprüfung oder die Auswirkungen von Fehlern auf die Suche.
Bedrocks Dokumentation eigener Datenquellen zieht die Grenze ausdrücklich. Diese verwenden vom Kunden gelieferte ACL-Metadaten statt Live-Quellprüfung. Anwendungen hängen Erlaubnis- und Verbotsregeln an Dokumente; sie werden vor der Suche angewendet, wobei Verbote Erlaubnisse überstimmen. Richtigkeit und Aktualität hängen vom Aufnahmeprozess des Kunden ab. Definiert ein eigener Konnektor die Rechte selbst, gibt es möglicherweise keine maßgebliche Quell-API für Bedrock.
Die Dokumentation warnt außerdem: ACL-bewusstes Filtern ist keine Authentifizierungsgrenze. Bedrock kann den von der aufrufenden Anwendung gelieferten Identitätskontext nicht verifizieren. Diese muss Nutzer vorher authentifizieren und geprüfte Identitätsdaten übergeben. Eine verlässliche Rechteabfrage für eine gefälschte oder falsch zugeordnete Nutzerkennung kann dennoch unsicher ausgehen.
Fehler eigener Quellen können wie fehlendes Wissen statt wie Sicherheitsfehler aussehen. Falsche Groß- und Kleinschreibung von ACL-Feldern, fehlende Listen oder abweichende E-Mail-Adressen können Dokumente still ausschließen. AWS beschreibt hier eine geschlossen verweigernde Suche ohne Autorisierungsausnahme. Dieses dokumentierte Verhalten ist keine belegte Garantie für jeden Ausfall jedes Konnektors.
Aktualität bringt betriebliche Abhängigkeiten
AWS zufolge können Live-Prüfungen Entzüge binnen kurzer Zeit statt nach Stunden oder Tagen der Synchronisierung abbilden. Das ist eine Unternehmensangabe, kein unabhängig gemessenes Service-Level-Versprechen. Entscheidend sind Quellplattform, Tokenzustand, API-Verfügbarkeit, Konnektorkonfiguration und Wissensbasismodus.
Remote-APIs können drosseln, vorübergehend ausfallen oder unerreichbar sein; Einwilligungen können entzogen werden und Tokens ablaufen. Unklare Rechte sollten standardmäßig zum Ausschluss führen. Dann erhält aber auch ein berechtigter Nutzer womöglich eine unvollständige Antwort. Ein System, das Lecks durch häufiges Weglassen legitimer Belege verhindert, kann als Wissensprodukt trotzdem scheitern.
Zusätzliche Aufrufe schaffen einen Leistungskompromiss. Parallele Prüfungen verkürzen Wartezeit, erhöhen aber Lastspitzen. Sequenzielle Prüfungen begrenzen Gleichzeitigkeit und erhöhen Latenz. Zwischengespeicherte erfolgreiche Entscheidungen beschleunigen, öffnen aber erneut ein Aktualitätsfenster. Öffentlich fehlen vollständige Cache-, Timeout-, Wiederholungs- und Ratenbegrenzungsregeln sowie Vergleichswerte zu Lecks, Latenz, API-Aufwand und Ausfällen.
Betriebliche Nachweise müssen Antworten mit den Quellprüfungen verbinden: übermittelte Identität, Ergebnis und Ausschlussgrund, ohne dabei vertrauliche Dokumentnamen in Diagnosen preiszugeben. Fehlenden Inhalt, erfolglose Suche und verweigerten Zugriff auseinanderzuhalten hilft sowohl der Vorfallbearbeitung als auch dem normalen Support.
Der Kundenhinweis von AWS ist kein unabhängiger Sicherheitstest. Mondelēz International habe Quick für mehr als 35.000 Beschäftigte in vier Regionen eingeführt. Der leitende M365-Innovationsspezialist Jamahl Wiggins sagt, Live-Zugriffskontrollen hätten Sicherheits- und Compliance-Prüfer überzeugt. Das zeigt Nachfrage und organisatorische Zustimmung, aber keinen gemessenen Nachweis von Leckvermeidung oder Leistung unter allen Bedingungen.
AWS’ Generative AI Lens warnte bereits vor Entwicklungsaufwand und möglichen Berechtigungslücken beim Nachbauen komplexer ACLs durch Metadaten. Abfragezeitprüfung adressiert einen Teil davon; eigene Implementierungen behalten mehr Verantwortung. Ähnliches gilt für persönliche und gemeinsame KI-Wissensbasen: Eine einheitliche Oberfläche hebt die Grenzen ihrer Informationen nicht auf.
Die Entscheidung wandert, die Verantwortung bleibt
Eine repräsentative Einführung braucht Nachweise über den vollständigen Weg von Anmeldung bis Antwort: entzogener Zugriff, Gruppen- und Vererbungsänderungen, explizite Verbote, abgelaufene Tokens, API-Ausfall und Neuerstellung der Wissensbasis. Neben Autorisierungsgenauigkeit zählen Suchvollständigkeit, zusätzliche Latenz, Erneuerungsfehler, Drosselung und wegen der Prüfung unbeantwortete Fragen.
Alternativen sind sorgfältig synchronisierte ACLs, getrennte Indizes je Sicherheitsdomäne, native berechtigungsbewusste Unternehmenssuche oder weitere Quellaufrufe. Sie tauschen Aktualität, Betriebsaufwand, Suchfreiheit und externe Abhängigkeiten unterschiedlich gegeneinander. Abfragezeitautorisierung könnte zur Beschaffungsbasis werden; die Ankündigung beweist nicht, dass sie das bereits ist.
Quick verbessert konkret die Architektur: Bei unterstützter, richtiger Konfiguration entscheidet die Quelle zuletzt, bevor Text das Modell erreicht. Die praktische Stärke hängt von konnektorspezifischen Garantien und beobachtbarem Fehlerverhalten ab – nicht davon, „ACL-Unterstützung“ als vollständiges Sicherheitssystem zu behandeln.
Quellen und weiterführende Informationen
AWS-Ankündigung; kanonische Ankündigungsadresse; SharePoint-ACL-Konfiguration; Quick-Datenintegrationen; Einordnung persönlicher und gemeinsamer Wissensbasen; ACLs eigener Bedrock-Quellen; AWS Generative AI Lens.