Sicherheit, Datenschutz und verantwortlicher Werkzeugeinsatz

Sicherheit und Datenschutz

0:00 Das elfte Modul behandelt Sicherheit und Datenschutz beim Werkzeugeinsatz. Und ich sage gleich zu Beginn, was dieses Modul nicht ist: Es ist keine Rechtsberatung. Wir benennen die Fragen, die zu klären sind, und wer im Haus dafür zuständig ist — Paragrafen stehen auf keiner Folie. Was Sie mitnehmen, ist eine Haltung, die sich in einem Satz zusammenfassen lässt: Bringen Sie dem Modell nicht bei, Täuschungen zu ignorieren.

0:25 Bauen Sie das System so, dass die Täuschung folgenlos bleibt.

Sicherheit, Datenschutz und Werkzeugeinsatz

0:29 Wir sind im letzten Drittel des Seminars. Nach dem Bestand kommt jetzt das Thema, das im Alltag oft zu kurz kommt, weil es niemandem sofort weh tut. Genau deshalb lohnt es sich, die Entscheidungen einmal bewusst zu treffen statt sie sich ergeben zu lassen. Und beim Fahrtenbuch wird der Datenschutzteil ungewöhnlich konkret, denn Fahrten sind Bewegungsdaten. Wer wann wo war, steht damit in jeder Zeile der Datenbank.

Datenklassifikation vor Werkzeugeinsatz

0:54 Fangen wir mit der Frage an, die vor allen anderen kommt: Womit geht das Werkzeug eigentlich um? Bevor Sie entscheiden können, welches Werkzeug erlaubt ist, müssen Sie wissen, welche Daten dabei in seinen Kontext geraten. Und die Antwort darauf ist überraschend selten der Quellcode selbst. Und diese Frage lässt sich nicht nachträglich beantworten, wenn das Werkzeug längst läuft.

1:16 Vier Kategorien reichen für den Anfang: öffentlich Zugängliches, internes Material ohne besondere Schutzbedürftigkeit, vertrauliches Material, und personenbezogene oder besonders geschützte Daten. Und jetzt der Satz, auf den es ankommt: Die Antwort hängt vom Betriebsmodell des Werkzeugs ab, nicht von seiner Nützlichkeit.

1:34 Das klingt banal und wird trotzdem regelmäßig anders herum entschieden — erst wird das Werkzeug eingeführt, weil es hilft, und dann klärt jemand die Frage. Oder auch nicht. Die Reihenfolge ist also entscheidend, und sie wird häufig umgekehrt. Das ist die Beobachtung, die ich für die praktisch wertvollste dieses Kapitels halte.

1:54 Die Einstufung entscheidet sich im Alltag nicht am Quellcode, sondern an dem, was drumherum in den Kontext gerät. Ein Fehlerbericht mit angehängtem Protokoll kann personenbezogene Daten tragen. Ein Ticket kann Kundennamen enthalten. Ein Testdatensatz kann aus der Produktion stammen. Und beim Fahrtenbuch ist jede einzelne Fahrt ein Bewegungsdatum einer namentlich bekannten Person. Der Code selbst ist dabei oft das Harmloseste.

2:19 Vier Fragen, und die rechte Spalte ist mir wichtig, weil sie die Zuständigkeit benennt. Auf welcher Grundlage werden die Daten verarbeitet — das beantworten die Datenschutzverantwortlichen, nicht Sie. Wo verarbeitet das Werkzeug, speichert es, trainiert es mit — das steht im Betriebsmodell des Anbieters. Ist die betriebliche Mitbestimmung berührt — Betriebsrat und Personalabteilung. Und die vierte können und müssen Sie selbst beantworten: Stammen Testdaten aus der Produktion?

2:48 Dieses Modul nennt die Fragen und die Zuständigkeit — eine rechtliche Einschätzung gibt es hier nicht.

Secrets und personenbezogene Daten

2:54 Zwei Datenarten verlangen besondere Sorgfalt, und sie haben eine unangenehme Eigenschaft gemeinsam: Ihr Austritt lässt sich nicht rückgängig machen. Bei allem anderen kann man nachbessern. Hier nicht. Deshalb lohnt sich die Vorsorge, auch wenn sie im Alltag lästig wirkt. Deshalb lohnt sich hier eine Sorgfalt, die an anderer Stelle übertrieben wäre. Was einmal draußen ist, bleibt draußen.

3:18 Zugangsdaten geraten auf immer gleichen Wegen in den Kontext, und es lohnt sich, diese Wege zu kennen: über Konfigurationsdateien im Arbeitsverzeichnis, über Umgebungsvariablen, über Protokollausgaben, und über eine Fehlermeldung mit vollständiger Verbindungszeichenfolge. Der letzte Weg ist der unterschätzte — eine gut gemeinte, ausführliche Fehlermeldung kann ein Passwort enthalten.

3:39 Und weil ein Agent Fehlermeldungen liest, um sich zu korrigieren, landet es zuverlässig in seinem Kontext. Deshalb lohnt es sich, diese vier Wege einmal bewusst durchzugehen und im eigenen Projekt zu prüfen. Fünf Punkte, und alle sind bekannt. Das Problem ist nicht das Wissen, sondern der Zeitpunkt: Sie werden meist erst nach dem ersten Vorfall eingerichtet.

4:01 Geheimnisse gehören nicht ins Repository, auch nicht kurz. Beispieldateien enthalten Platzhalter. Eine automatische Prüfung schlägt an, bevor etwas eingecheckt wird. Testdaten werden anonymisiert oder erzeugt, nie aus der Produktion kopiert — das ist die häufigste stillschweigende Verletzung und zugleich die am leichtesten zu vermeidende.

4:21 Und wenn doch etwas passiert ist: zuerst rotieren, erst danach die Historie. Der erste Punkt ist der aus Modul acht: ein Geheimnis nur aus dem aktuellen Stand entfernen und sich für sicher halten. Der zweite ist der praktische Klassiker — Produktionsdaten für einen einmaligen Test kopieren. Dieser eine Test lebt dann erfahrungsgemäß drei Jahre.

4:41 Der dritte ist der Zeitpunkt: die automatische Prüfung erst nach dem ersten Vorfall einrichten. Und der vierte ist der von eben: eine Fehlermeldung mit vollständiger Verbindungszeichenfolge protokollieren, weil es beim Debuggen so praktisch war.

Least Privilege für Agenten

4:56 Jetzt zu einem Thema, das mir besonders wichtig ist. Ein Coding-Agent bekommt Rechte — nur werden sie selten bewusst abgestuft. Meist bekommt er alles, damit nichts hakt. Dabei sind die Stufen gut unterscheidbar, und die Sprünge zwischen ihnen sind erheblich größer, als sie auf den ersten Blick aussehen. Die brauchbare Praxis lautet: mit der niedrigsten Stufe beginnen, die die Aufgabe erlaubt, und höher gehen, wenn es sich als nötig erweist. Nicht vorsorglich.

5:25 Das ist die ganze Regel, und sie klingt einfacher, als sie im Alltag durchzuhalten ist — denn vorsorglich alles zu vergeben spart im Moment Zeit. Zur Einordnung: Die OWASP-Liste für KI-Anwendungen führt übermäßige Handlungsvollmacht in der Fassung von 2026 auf Platz drei, aufgestiegen von Platz sechs. Begründet mit realen Schäden in Produktion.

5:46 Fünf Stufen, und ich möchte zwei Sprünge hervorheben. Der Sprung vom Schreiben zum Ausführen ist der erste große: Damit wird alles möglich, was auf dem Rechner möglich ist — nicht nur im Projektverzeichnis. Und der Sprung zum Netzwerk ist der zweite: Damit können Daten das Haus verlassen. Beide Sprünge sehen in einer Konfigurationsdatei aus wie ein weiteres Häkchen und sind in Wahrheit Größenordnungen.

6:10 Ganz oben steht der Trost: Erkundung braucht Leserechte, mehr nicht. Diese eine Unterscheidung nimmt einem großen Teil der Aufgaben das Risiko. Der erste Punkt ist der ehrlichste: vorsorglich alle Rechte vergeben, damit nichts hakt. Das passiert nicht aus Leichtsinn, sondern aus Termindruck. Der zweite ist die konkrete Verschwendung — Erkundung mit Schreib- und Ausführungsrechten, obwohl Lesen genügt. Der dritte betrifft das Netzwerk, das oft gar nicht gebraucht wird.

6:38 Und der vierte ist der organisatorische, der über die Zeit am meisten anrichtet: Rechte einmal vergeben und nie wieder zurücknehmen. Sie wachsen dann monoton.

Sandbox und isolierte Arbeitsumgebungen

6:48 Wo mehr Rechte tatsächlich nötig sind, ist Eingrenzung das Mittel der Wahl. Und hier gibt es einen Aspekt, der oft übersehen wird: Eine Sandbox ist nicht nur eine Schutzmaßnahme. Sie ist auch eine Produktivitätsmaßnahme — aus einem Grund, der unmittelbar einleuchtet, sobald man ihn hört. Und sie ist billiger einzurichten, als die meisten annehmen.

7:09 Ein abgeschotteter Container, eine virtuelle Maschine oder ein getrenntes Arbeitsverzeichnis begrenzen den Wirkungsbereich auf etwas, dessen Verlust folgenlos ist. Entscheidend ist dabei nicht, was die Sandbox einschließt, sondern was darin erreichbar bleibt. Und da liegt der häufigste Fehler: Ein Container mit Zugriff auf die Produktionsdatenbank ist keine Sandbox. Er ist eine Sandbox mit einer Tür.

7:33 Die Frage lautet also nicht, ob isoliert wurde, sondern wovon. Die Antwort darauf entscheidet, ob die Maßnahme trägt oder nur beruhigt. Und jetzt der Aspekt, den ich hervorheben möchte. Wer weiß, dass der schlimmste Fall ein weggeworfenes Verzeichnis ist, kann einem Agenten mehr Freiheit lassen — und wird dadurch produktiver, nicht vorsichtiger.

7:54 Die Isolation ist also keine Bremse, sie ist die Voraussetzung für Tempo. Dazu kommen zwei praktische Gewinne: Getrennte Arbeitsverzeichnisse erlauben mehrere Aufgaben parallel, ohne dass sich Änderungen vermischen. Und sie machen den Diff je Aufgabe wieder lesbar — was, wie wir in Modul neun gesehen haben, die Grundlage jedes ernsthaften Reviews ist.

8:15 Der erste Punkt ist die Sandbox mit der Tür von eben. Der zweite ist die Variante davon, die aus Pragmatismus entsteht: Zugangsdaten in die isolierte Umgebung durchreichen, weil es sonst nicht läuft. Damit ist die Isolation aufgehoben, und zwar genau an der teuersten Stelle. Der dritte ist ein Arbeitsfehler — mehrere Aufgaben im selben Verzeichnis, Änderungen vermischen sich.

8:37 Und der vierte ist die Denkfalle, die wir gerade aufgelöst haben: Isolation als Bremse verstehen statt als Voraussetzung für mehr Freiheit.

Prompt Injection als reale Angriffsfläche

8:45 Jetzt zu dem Angriff, der seit Jahren auf Platz eins der OWASP-Liste steht — auch in der aktuellen Fassung von 2026, trotz vergleichsweise dünner Vorfallslage. Bemerkenswert ist die Begründung dafür: Organisationen, die ihn erfolgreich abwehren, erzeugen eben keine Vorfälle. Sehen wir uns an, warum er strukturell ist. Und wer den Mechanismus verstanden hat, sucht die Abwehr nicht mehr am falschen Ort.

9:11 Der Kern ist eine Eigenschaft, keine Schwäche eines bestimmten Produkts. Ein Agent unterscheidet nicht zuverlässig zwischen dem, was sein Auftraggeber will, und dem, was in den Inhalten steht, die er unterwegs liest. Für ihn ist beides Text. Und damit wird jeder Text, den er verarbeitet, zu einer möglichen Anweisungsquelle.

9:30 Das ist kein theoretisches Szenario und keine Panikmache — es folgt unmittelbar daraus, wie diese Werkzeuge arbeiten. Wer das verstanden hat, sucht die Verteidigung an der richtigen Stelle. Vier Quellen, und die rechte Spalte macht das Risiko greifbar, weil sie fragt: Wer kann dort eigentlich schreiben? Ein Fehlerbericht oder Ticket — jeder, der ein Ticket anlegen darf, und das sind in vielen Häusern sehr viele.

9:56 Eine Webseite oder Bibliotheksdokumentation — deren Betreiber, und wer sie kompromittiert. Ein Kommentar im Code — jeder mit Schreibrecht im Repository. Und die Ausgabe des Bauwerkzeugs — wer eine Abhängigkeit kontrolliert. Ein Angreifer, der irgendwo in dieser Kette schreiben kann, kann versuchen, Verhalten zu beeinflussen.

10:16 Und damit zur Konsequenz, die dieses Kapitel trägt. Dem Modell das Ignorieren beizubringen ist der aussichtslose Weg — man kann es besser machen, aber nicht sicher. Wirksam ist stattdessen die Architektur drumherum: wenig Rechte, kein unnötiger Netzwerkzugriff, Freigabe für alles, was nach außen wirkt, und Misstrauen gegenüber Inhalten aus fremder Feder.

10:37 Auch gegenüber Dokumentation. Die OWASP-Verantwortlichen fassen ihre eigene Linie sinngemäß so zusammen: Hören Sie auf, ein Modell bauen zu wollen, das sich nicht täuschen lässt. Bauen Sie das System so, dass beim Getäuschtwerden nichts Wichtiges bricht.

Neue Abhängigkeiten und Lieferkette

10:53 Jetzt zu der Zeile, die in vielen generierten Änderungen die folgenreichste ist und zugleich die am leichtesten übersehene: der Vorschlag, eine Bibliothek einzubinden. Vier Prüfungen lohnen sich immer, und die wirksamste ist die letzte — diejenige, die viele gar nicht als Prüfung betrachten. Denn ihre Folgen reichen weit über das Projekt hinaus, in dem sie eingebunden wird.

11:15 Warum ist gerade diese Zeile so folgenreich? Weil sie Wirkung entfaltet, die weit über das Projekt hinausreicht: Lieferkette, Lizenz, Pflege, Sicherheitsupdates — alles hängt daran, und nichts davon steht im Diff. Und sie ist leicht zu übersehen, weil sie im Vergleich zu hundert Zeilen Fachlogik unscheinbar wirkt. Im Review braucht sie deshalb eine eigene Aufmerksamkeit, und genau dafür sind die vier Fragen da. Die vier Fragen sind schnell gestellt und ersparen erheblichen Ärger.

11:43 Die erste Frage klingt seltsam und ist ernst gemeint: Gibt es das Paket wirklich unter diesem Namen? Sie erinnern sich an die Zahlen aus Modul eins — erfundene Paketnamen sind gemessen, und weil verschiedene Modelle dieselben erfinden, werden sie von Angreifern gezielt registriert. Zweitens: Wird es gepflegt? Drittens: Bringt es einen Rattenschwanz weiterer Abhängigkeiten mit? Und viertens, die wirksamste: Braucht man es überhaupt?

12:09 Denn die sicherste Abhängigkeit bleibt die, die man nicht aufnimmt. Der erste Punkt ist der gefährlichste: einen Paketnamen übernehmen, weil er plausibel klingt. Plausibel klingen ist genau das, was erfundene Namen auszeichnet — sie sind ja aus echten Bestandteilen zusammengesetzt. Der zweite ist die Vertrautheitsfalle: die Pflege nicht prüfen, weil das Paket bekannt aussieht. Der dritte betrifft den mitgebrachten Abhängigkeitsbaum, den kaum jemand ansieht.

12:37 Und der vierte ist der organisatorische: eine Abhängigkeit ohne ausdrückliche Freigabe aufnehmen. Das gehört zu den Haltepunkten aus Modul fünf.

Freigabepunkte und Nachvollziehbarkeit

12:47 Zum letzten fachlichen Kapitel, und es wird organisatorisch. Welche Vorgänge verlangen eine ausdrückliche Zustimmung, und wer kann hinterher rekonstruieren, was geschehen ist? Ich möchte das ausdrücklich nicht als Bürokratie rahmen, sondern als etwas anderes — als Lernvoraussetzung. Denn nach einem Vorfall entscheidet sich daran, ob überhaupt etwas gelernt werden kann.

13:09 Freigabepflichtig sollte alles sein, was schwer umkehrbar ist oder nach außen wirkt: Datenmigrationen, Löschungen, neue Abhängigkeiten, Änderungen an Berechtigungen, alles, was das System verlässt. Das ist im Wesentlichen dieselbe Liste wie die Haltepunkte aus Modul fünf, nur aus organisatorischer Sicht. Der Unterschied: Dort ging es darum, wann der Agent stoppt.

13:30 Hier geht es darum, wer danach entscheidet und ob das später noch nachvollziehbar ist. Beides gehört zusammen und wird trotzdem selten gemeinsam festgelegt. Vier Fragen, und die rechte Spalte sagt, warum sie später zählen. Wer hat die Änderung veranlasst — der Ansprechpartner für Rückfragen. Mit welchem Auftrag — und das ist die wichtigste Zeile, denn sie zeigt, ob der Auftrag vollständig war. Unter welchen Rechten — zeigt, ob die Stufe angemessen war.

13:58 Und wer hat freigegeben — das trennt den Vorschlag von der Entscheidung. Diese vier Angaben kosten wenig und beantworten nach einem Vorfall die Fragen, die sonst offenbleiben. Und hier ist der Grund, warum ich das nicht als Bürokratie sehe. Nach einem Vorfall gibt es genau zwei Möglichkeiten: Entweder hat der Agent versagt — dann hilft ein anderes Werkzeug oder engere Rechte.

14:21 Oder der Auftrag war unvollständig — dann hilft eine bessere Vorlage. Das sind völlig verschiedene Konsequenzen. Und ohne festgehaltenen Auftrag lässt sich nicht unterscheiden, welcher Fall vorliegt. Ohne die Unterscheidung wiederholt sich derselbe Fehler, nur mit einem anderen Werkzeug.

Übung: Berechtigungsmodell für drei Agentenaufgaben

14:39 Zum Abschluss entwerfen Sie Berechtigungsmodelle für drei ganz verschiedene Aufgaben am Fahrtenbuch. Der Reiz liegt darin, dass die drei unterschiedliche Antworten verlangen — wer für alle dasselbe Modell aufschreibt, hat die Aufgabe nicht durchdacht. Und am Ende wartet eine Frage, die als Prüfstein dient. Sehen wir uns an, wie unterschiedlich die drei Antworten ausfallen müssen.

15:01 Die drei Aufgaben sind: die Erkundung des Abrechnungsmoduls, die Umsetzung einer fachlichen Änderung samt Tests, und die Ablösung einer veralteten Bibliothek über viele Dateien hinweg. Für jede legen Sie fest, welche Rechte nötig sind und welche ausdrücklich nicht, wo die Arbeit läuft, welche Vorgänge eine Freigabe brauchen und was protokolliert wird.

15:20 Und dann der Prüfstein: Benennen Sie je Aufgabe den plausibelsten Weg, auf dem eine Prompt Injection wirksam werden könnte. Wer das nicht beantworten kann, hat die Rechte nicht durchdacht. Eine Stunde, fünf Schritte je Aufgabe. Achten Sie besonders auf den zweiten Punkt: nicht nur wo die Arbeit läuft, sondern was von dort erreichbar bleibt — die Sandbox mit der Tür.

15:42 Die dritte Aufgabe ist übrigens die heikelste, und das mit Absicht: viele Dateien, eine neue Abhängigkeit, und Dokumentation aus fremder Feder als Eingabe. Damit kommen alle drei Risikoarten dieses Moduls in einer einzigen Aufgabe zusammen. Vergleichen Sie zum Schluss die drei Modelle nebeneinander — die Unterschiede sind der eigentliche Ertrag der Übung.