Microsoft 365 Copilot absichern: Prompt Injection, Berechtigungen und Agenten prüfen

Copilot absichern beginnt mit einer Produkt- und Berechtigungsinventur. Microsoft 365 Copilot, Copilot Chat und individuell konfigurierte Agenten sind keine identischen Ausführungspfade. Ohne den konkreten Daten- und Aktionsumfang lässt sich eine Prompt-Injection-Prüfung nicht belastbar bewerten.

Der folgende Plan trennt Herstellermechanismen von eigenen betrieblichen Prüfungen. Er beschreibt ausschließlich autorisierte Tests mit synthetischen Daten. Er enthält weder eine Exfiltrationsanleitung noch eine universelle Konfiguration, die Schutz für jeden Tenant verspricht.

1. Den tatsächlichen Ausführungspfad bestimmen

Erfassen Sie die verwendete Oberfläche, Lizenz, aktivierte Funktionen, Benutzergruppe und angebundene Quellen. Bei Agenten kommen Werkzeuge, Connectoren, ausführende Identitäten und mögliche Schreiboperationen hinzu. Eine Prüfung ohne diese Angaben lässt sich später kaum reproduzieren.

Zeichnen Sie einen einfachen Datenfluss: Benutzereingabe → ausgewählte Quellen → Modellverarbeitung → Ausgabe oder Werkzeugaufruf. Markieren Sie an jeder Grenze, wer Inhalte kontrollieren kann und welche Instanz die Berechtigung entscheidet. Unbekannte Connector-Befugnisse werden als offen behandelt und nicht durch eine allgemeine Herstellerbeschreibung ersetzt.

2. Prompt Injection und Oversharing getrennt prüfen

Prompt Injection betrifft die Beeinflussung durch verarbeitete Inhalte. Oversharing betrifft bereits zu großzügige Zugriffsrechte. Für den Test sind das zwei getrennte Fragestellungen: Erhält ein Benutzer unzulässig Daten? Und verändert fremder Inhalt das Verhalten in unerwünschter Weise?

Microsoft beschreibt für Copilot die Nutzung bestehender Benutzerberechtigungen. Prüfen Sie deshalb insbesondere breite Gruppen, veraltete Freigaben und Daten ohne zuständigen Eigentümer. Eine bessere Auffindbarkeit kann bestehende Probleme sichtbar machen, ohne dass eine neue Berechtigung vergeben wurde. Microsoft: Datenschutz und Berechtigungen.

3. Vorhandene Schutzschichten korrekt einordnen

Microsoft dokumentiert mehrschichtige Laufzeitschutzmechanismen. Daneben stehen tenantseitige Daten- und Sicherheitskontrollen. Halten Sie fest, welche davon für Ihren konkreten Einsatz verfügbar und nachweislich eingerichtet sind. Ein Produktname in der Lizenzliste ersetzt keinen Wirksamkeitsnachweis.

Restricted Content Discovery ist beispielsweise von einer Zugriffsrechteänderung zu unterscheiden. Ebenso ist eine Überwachung von Ereignissen nicht dasselbe wie das präventive Blockieren einer Aktion. Diese Trennung verhindert, dass ein erkanntes Signal fälschlich als garantierte Verhinderung berichtet wird. Microsoft: Defense in Depth.

4. E-Mail-Schutz nicht als universellen Injection-Test missverstehen

Die Microsoft-Dokumentation nennt für Defender for Office 365 Plan 2 eine Erkennung in eingehenden E-Mails. Erkannte Fälle werden über bestehende Phishing-Bewertungen und die Detection Technology „Prompt injection protection“ sichtbar. Der Umfang ist gezielt begrenzt; ein harmloser Testtext von einem bekannten Absender muss deshalb nicht anschlagen.

Folgerung für die Abnahme: Ein fehlender Mailalarm beweist weder, dass alle Laufzeitschutzmechanismen versagt haben, noch dass der Inhalt sicher ist. Mailfilter und KI-Verhalten werden getrennt beobachtet. Microsoft: Schutzumfang und Erkennungsgrenzen.

5. Werkzeugbefugnisse außerhalb des Modells begrenzen

Für selbst konfigurierte Agenten empfehlen wir eine eigenständige Prüfung jeder wirksamen Aktion: erlaubtes Ziel, erforderliche Identität, zulässige Parameter und gegebenenfalls eine konkrete menschliche Freigabe. Das Modell selbst sollte keine zusätzlichen Rechte vergeben können.

Unterscheiden Sie delegierte Benutzerrechte von weitergehenden Anwendungsrechten. Ein breit berechtigter Connector kann den möglichen Schaden vergrößern. Für einen Rechercheanwendungsfall sind Schreibrechte häufig nicht nötig. Werden Aktionen benötigt, sollten sie auf den fachlichen Zweck begrenzt und nachvollziehbar protokolliert werden.

OWASP nennt unter anderem die Begrenzung von Rechten und menschliche Kontrolle bei folgenreichen Aktionen als Schutzansätze. Der Risikokatalog ist eine Orientierung für die Architekturprüfung, kein Nachweis der Sicherheit Ihres individuellen Agenten. OWASP LLM01:2025.

6. Einen ungefährlichen Testfall vorbereiten

Legen Sie einen gesonderten Testbereich und synthetische Dokumente an. Ein Dokument enthält ausschließlich erfundene Geschäftsdaten; ein zweites enthält zusätzlich eine klar dokumentierte, harmlose Anweisung, in der Zusammenfassung einen bestimmten Testmarker auszugeben. Keine externen Empfänger, keine echten Zugangsdaten und keine produktiven Schreibaktionen.

Definieren Sie vorab, was als erwartetes Ergebnis gilt: korrekte Zusammenfassung des Inhalts, keine unbeauftragte Aktion und kein Zugriff außerhalb des Testbereichs. Falls ein Marker erscheint, muss zunächst geklärt werden, ob er als zitierter Dokumentinhalt oder als befolgte Anweisung ausgegeben wurde. Das ist eine qualitative Bewertung und darf nicht durch eine bloße Textsuche ersetzt werden.

7. Positive und negative Fälle gemeinsam auswerten

• Normalfall: Ein berechtigter Benutzer kann das vorgesehene Testdokument korrekt verarbeiten.
• Berechtigungsfall: Ein nicht berechtigter Testbenutzer erhält keinen Zugriff auf den geschützten Inhalt.
• Manipulationsfall: Die dokumentierte fremde Anweisung verändert den Auftrag nicht unzulässig.
• Aktionsfall: Eine nicht freigegebene oder außerhalb des Zwecks liegende Aktion bleibt technisch gesperrt.
• Nachweisfall: Die relevanten Vorgänge lassen sich den Testbedingungen zuordnen.

Ein erfolgreicher Einzeltest ist ein begrenzter Nachweis. Varianten von Datenquellen, Agenten und Verbindungen können andere Ergebnisse liefern. Produktänderungen machen wiederkehrende Prüfungen sinnvoll, aber es gibt keine seriöse Garantie durch eine einzelne feste Testphrase.

8. Protokollierung und Reaktion vorbereiten

Erfassen Sie Testzeit, Identität, Produktkonfiguration, Quellversion und beobachtetes Ergebnis. Speichern Sie nur notwendige Inhalte; auch Testprotokolle können sensible Informationen enthalten. Zugriffsrechte und Aufbewahrung werden deshalb vorab festgelegt.

Für den Vorfall muss klar sein, wer einen Agenten oder eine Verbindung sperren darf, wie Logs gesichert werden und welcher Prozess ohne die KI weiterläuft. Eine vorschnelle Wiederholung mit echten Daten erhöht das Risiko. Zunächst werden die betroffene Verbindung und der beobachtete Umfang eingegrenzt.

9. Abnahme und offene Grenzen dokumentieren

Die Abnahme benennt getestete Datenquellen, Rechte und Aktionen, verfügbare Schutzschichten sowie ausdrücklich nicht getestete Funktionen. Herstellerangaben, eigener Konfigurationsnachweis und Testergebnis bleiben getrennte Evidenzarten.

Hamburger IT-Service unterstützt bei dieser technischen Bestandsaufnahme und bei begrenzten Prüfungen von Berechtigungen und Agentenbefugnissen. Copilot-Konfiguration und KI-Grenzen prüfen lassen.

Weiterführend

• Partnerartikel: Prompt Injection in Microsoft 365 Copilot: Wenn Dokumente die KI beeinflussen
• Lokale KI sicher betreiben
• Technische TOM-Nachweise
• Weitere Wissensartikel

Quellen und Datenstand

Datenstand: 21. September 2026. Herstellerangaben und Schutzfunktionen können sich ändern. Die verlinkten Primärquellen wurden für diesen Beitrag geprüft; die beschriebenen Prüfabläufe sind unsere praktische Empfehlung. Illustrationen sind KI-generiert.

• https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy
• https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-prompt-defense-in-depth
• https://learn.microsoft.com/en-us/defender-office-365/step-by-step-guides/prompt-injection-protection-defender-for-office-365
• https://genai.owasp.org/llmrisk/llm01-prompt-injection/