Claude freigeben: die Kontrollpunkte für die Sicherheit

TL;DR

Sieben Punkte entscheiden über die Freigabe. Drei davon betreffen Stellen, an denen Geheimnisse landen, ohne dass es jemandem auffällt — und die stehen in keiner Standardprüfliste.

1. Wo landen die Zugangsdaten?

Nicht die theoretische Frage, sondern die praktische: Suchen Sie sie.

In Prompts und Nachrichten. Der schlimmste Fall und häufiger als erwartet. Was im Systemprompt oder in einer Nachricht steht, liegt dauerhaft in der Ereignishistorie der Sitzung, ist über die Ereignisliste abrufbar und landet in Verdichtungs-Zusammenfassungen. Ein dort abgelegtes Geheimnis ist für die Lebensdauer der Sitzung lesbar.

Auf dem Arbeiterrechner einer selbst betriebenen Sandbox. Wer dort einen organisationsweiten API-Schlüssel setzt, legt ihn in Reichweite der Werkzeugausführung. Dorthin gehört ausschließlich der Umgebungsschlüssel, der nur für die Arbeitswarteschlange einer Umgebung gilt.

In Umgebungsvariablen des Containers. Der richtige Weg ist der Tresor: Der Container sieht einen Platzhalter, das echte Geheimnis wird erst beim Verlassen der Sandbox eingesetzt. Damit kann auch vom Modell erzeugter Code es nicht auslesen. Die Einrichtung steht im Beitrag zu Tresor-Zugangsdaten.

2. Was kann ein manipuliertes System auslösen?

Die belastbare Frage lautet nicht "wie verhindere ich Manipulation", sondern "was passiert, wenn sie gelingt".

Ein System, das nur liest und Text ausgibt, richtet begrenzten Schaden an. Eines mit schreibenden Werkzeugen ist ein anderes Problem.

Regel: Kein Schreibzugriff ohne menschliche Freigabe. Wo das nicht praktikabel ist, begrenzen Sie den Schaden — Mengenobergrenzen je Aufruf, Tageskontingente, eine Protokollierung, die eine Rücknahme erlaubt.

Der Angriffsweg, der dabei zählt, ist nicht die Nutzereingabe, sondern die indirekte Einschleusung über Dokumente, die das System abruft. Die Einordnung steht im Beitrag zu Prompt-Injection.

3. Erben Werkzeuge die Rechte des Nutzers?

Der häufigste Architekturfehler: Der Dienst läuft mit einem technischen Konto, das alles darf, und filtert nachträglich.

Eine erfolgreiche Manipulation umgeht diesen Filter. Wenn stattdessen die Berechtigung des angemeldeten Nutzers bis in die Abfrage durchgereicht wird, kann auch ein manipuliertes System nur das sehen, was der Nutzer ohnehin sehen dürfte.

Prüffrage für den Abnahmetest: Melden Sie sich mit einem Konto aus der Produktion an und fragen Sie nach etwas, das nur die Personalabteilung wissen sollte. Kommt eine Antwort, ist die Freigabe zu verweigern.

4. Was steht im Netzwerkpfad?

Zwei Ebenen, die beide greifen müssen und regelmäßig verwechselt werden:

Bei eingeschränkten Netzwerkregeln steuert die Freigabeliste am Zugangsdatum, für welche Hosts ein Geheimnis eingesetzt wird — nicht, welche Anfragen erlaubt sind. Der Host muss zusätzlich auf Umgebungsebene erreichbar sein.

Und bei einer selbst betriebenen Sandbox gibt es keine Voreinstellung für ausgehende Verbindungen: Was Ihre Firewall zulässt, kann der Agent erreichen.

5. Wer darf welches Werkzeug aufrufen?

Berechtigungen gehören je Werkzeug geprüft, nicht je Dienst. Ein authentifizierter MCP-Server, bei dem jeder angemeldete Mitarbeiter jedes Werkzeug aufrufen darf, ist selten das Gewollte — der Vertrieb soll Bestände sehen, aber keine Einkaufspreise.

Zwei Details: Die Fehlermeldung bei fehlender Berechtigung darf nicht verraten, welche Gruppe gereicht hätte. Und Werkzeuge sollten eng geschnitten sein und Pflichtparameter erzwingen — eines, das ohne Parameter den gesamten Bestand zurückgibt, ist ein Datenleck mit Schnittstelle.

Die Umsetzung steht im Beitrag zum MCP-Server mit Berechtigungsprüfung.

6. Was wird protokolliert, und wie lange?

Ohne Aufrufprotokolle ist ein Sicherheitsvorfall nicht aufklärbar. Sie brauchen je Aufruf: Zeitstempel, Nutzerkennung, aufgerufenes Werkzeug, Parameter, Dauer — strukturiert, nicht als Fließtext.

Zugleich ist genau das mitbestimmungspflichtig: Aufrufprotokolle mit Nutzerkennung ermöglichen eine Leistungs- und Verhaltenskontrolle. Klären Sie die Ausgestaltung vor dem Produktivgang; die Einordnung steht im Beitrag zur Mitbestimmung.

Der wirksame Kompromiss: pseudonymisierte Nutzerkennung, kurze Frist für vollständige Inhalte, längere für aggregierte Kennzahlen, Zugriff auf benannte Rollen beschränkt.

7. Welche Modelle und Plattformen sind zugelassen?

Der Punkt, der ohne Gateway nicht durchsetzbar ist.

Mit einem Gateway definieren Sie logische Modellnamen und binden sie an Plattformen — vertraulich an ein lokal betriebenes Modell, standard an ein Cloud-Modell. Anwendungen sprechen die Rolle an und können die Bindung nicht umgehen.

Ein sicherheitsrelevantes Detail dabei: Das vertrauliche Modell darf keine Ausweichroute nach außen haben. Sonst wandern bei einem Ausfall des lokalen Servers genau die Daten in die Cloud, für die die lokale Verarbeitung eingerichtet wurde — lautlos, ohne Fehler. Ein Fehler ist hier das gewünschte Verhalten.

Die drei Punkte, die niemand prüft

Zusammengefasst, weil sie in Standardprüflisten fehlen:

1. Geheimnisse in Prompts — dauerhaft in der Ereignishistorie, über die API abrufbar
2. Organisationsweiter API-Schlüssel auf dem Arbeiterrechner — in Reichweite der Werkzeugausführung
3. Stille Ausweichroute vom vertraulichen zum Cloud-Modell — der Datenabfluss, der keinen Fehler erzeugt

Häufig gestellte Fragen

Wo landen API-Schlüssel unbemerkt?

An drei Stellen: in Systemprompts und Nachrichten, wo sie dauerhaft in der Ereignishistorie liegen und über die API abrufbar bleiben; auf dem Arbeiterrechner einer selbst betriebenen Sandbox, wenn dort ein organisationsweiter Schlüssel statt des Umgebungsschlüssels gesetzt wird; und in Container-Umgebungsvariablen statt in einem Tresor.

Wie verhindere ich Datenabfluss durch ein manipuliertes System?

Nicht über Filter, sondern über Begrenzung: kein Schreibzugriff ohne menschliche Freigabe, und Werkzeuge, die die Berechtigung des angemeldeten Nutzers erben statt mit einem allmächtigen technischen Konto zu laufen. Dann sieht auch ein manipuliertes System nur das, was der Nutzer ohnehin sehen dürfte.

Was ist die wirksamste Prüffrage im Abnahmetest?

Melden Sie sich mit einem Konto aus einem Bereich mit engen Rechten an und fragen Sie nach etwas, das nur ein anderer Bereich wissen sollte. Kommt eine Antwort, laufen die Berechtigungen über ein technisches Konto mit nachgelagerter Filterung — und die Freigabe ist zu verweigern.

Warum ist eine Ausweichroute beim vertraulichen Modell gefährlich?

Weil sie bei einem Ausfall des lokalen Servers genau die Daten in die Cloud schickt, für die die lokale Verarbeitung eingerichtet wurde — ohne Fehler und ohne Hinweis. Konfigurieren Sie das vertrauliche Modell deshalb ohne Ausweichziel; ein Fehler ist in diesem Fall das gewünschte Verhalten.

Sind Aufrufprotokolle mitbestimmungspflichtig?

Ja, wenn sie eine Nutzerkennung tragen — sie ermöglichen dann eine Leistungs- und Verhaltenskontrolle im Sinne des Betriebsverfassungsgesetzes. Klären Sie die Ausgestaltung vor dem Produktivgang. Praktikabel sind pseudonymisierte Kennungen, kurze Fristen für vollständige Inhalte und ein auf benannte Rollen beschränkter Zugriff.

Der nächste Schritt

Suchen Sie in Ihren Agentenkonfigurationen und Systemprompts nach Zugangsdaten. Jede Fundstelle liegt dauerhaft in der Ereignishistorie und lässt sich nachträglich nicht entfernen — das ist der Punkt, an dem eine Sicherheitsfreigabe scheitern sollte. Bei der Prüfung unterstützen wir gern.