Sicherheit, Berechtigungen und Governance

Sicherheit, Berechtigungen und Governance

0:00 Kommen wir zu dem Modul, das erfahrungsgemäß die meisten Nachfragen erzeugt — und das viele Teams zu spät angehen. Sicherheit im agentischen Arbeiten ist kein Spezialthema für die Sicherheitsabteilung. Sie beginnt bei einer sehr alltäglichen Erkenntnis: Ein Repository ist keine vertrauenswürdige Eingabe. Issues, Kommentare, Dokumentationen, Abhängigkeiten — all das schreiben andere.

0:23 Und ein Werkzeug, das diese Inhalte liest und daraufhin handelt, ist ein Werkzeug, das man begrenzen muss. Wir schauen uns an, wie das geht, ohne die Arbeit zu ersticken.

Sicherheit, Berechtigungen und Governance

0:34 Vier Kapitel. Zuerst die Risiken — geordnet nach drei Ursachen, die man getrennt behandeln muss. Dann Least Privilege in einer Fassung, die im Alltag praktikabel ist: drei Stufen statt einer Rechteliste. Danach die Einbindung in den bestehenden Entwicklungsprozess, denn ein zweiter Prozess neben dem echten wird umgangen.

0:54 Und zum Schluss bauen Sie eine Freigabematrix für fünf Umgebungen.

Risiken agentischer Werkzeuge

0:58 Beginnen wir mit der Systematik. Es gibt einen etablierten Begriff für das, was hier schiefgehen kann, und er hat den Vorteil, drei Ursachen sauber zu trennen. Diese Trennung ist praktisch wichtig, denn jede Ursache hat ein anderes Gegenmittel — und wer alle drei in einen Topf wirft, behandelt keine richtig. Excessive Agency — zu viel Handlungsspielraum — bezeichnet Schaden durch Aktionen, die ein Werkzeug ausführen konnte, weil es zu viele Funktionen, zu viele Rechte oder zu viel Selbstständigkeit hatte.

1:28 Achten Sie auf das Wort konnte. Es geht nicht um böse Absicht und nicht einmal um einen Fehler des Modells; es geht darum, dass eine fehlerhafte Ausgabe eine Wirkung entfalten konnte. Der Schutz liegt deshalb nicht darin, bessere Ausgaben zu erhoffen, sondern darin, die Wirkung zu begrenzen. Das ist dieselbe Logik wie bei jeder anderen Sicherheitsmaßnahme auch.

1:49 Die drei Zeilen sind bewusst getrennt, weil die Gegenmittel verschieden sind. Zu viele Funktionen: Eine Shell, die niemand braucht, ist eine offene Tür — hier hilft, Werkzeuge zu begrenzen. Zu viele Rechte: Schreibrecht auf produktionsnahe Systeme gehört nicht zur Entwicklungsarbeit — hier hilft, Rechte zu trennen. Zu viel Autonomie: Ein Push ohne Rückfrage ist eine Handlung nach außen — hier hilft eine Bestätigung.

2:14 Die Fußzeile ist der Punkt, den ich betonen möchte: Die Ursachen addieren sich. Wer alle drei offen lässt, hat schlicht keine Grenze mehr, nur noch Vertrauen. Diese vier Punkte sind der Grund, warum Prompt Injection kein exotisches Thema ist. Issues, Pull Requests und Kommentare schreiben Beteiligte von außen — bei einem öffentlichen Repository buchstäblich jeder.

2:37 Dokumentation und Webseiten landen über Werkzeuge im Kontext. Abhängigkeiten bringen Code mit, den niemand gelesen hat. Und manipulierte Repository-Inhalte zielen genau auf den lesenden Agenten. Die Konsequenz ist nüchtern: Alles, was der Agent liest und nicht von Ihnen stammt, ist Eingabe — und Eingaben validiert man, statt ihnen zu glauben.

2:59 Der erste Punkt ist der, den man am leichtesten abstellt und am häufigsten vergisst: Zugriff auf Umgebungsdateien und Schlüssel. Eine Ausschlussliste kostet zwei Minuten. Der zweite ist neu und wird unterschätzt: Ein vorgeschlagenes Paket existiert gar nicht oder ist wenige Tage alt — beides sind bekannte Angriffsmuster.

3:17 Der dritte betrifft die Tests: abgeschwächt oder entfernt, und der Lauf wird grün. Und der vierte betrifft Werkzeugserver, die nach der Freigabe still ihr Verhalten ändern. Ein einmal erteiltes Vertrauen bleibt sonst unbefristet gültig.

Least Privilege

3:32 Kommen wir zum wichtigsten praktischen Werkzeug dieses Moduls. Least Privilege ist ein alter Grundsatz, und die Kunst besteht darin, ihn so zu fassen, dass er im Alltag tatsächlich angewendet wird. Drei Stufen reichen dafür — mehr merkt sich ohnehin niemand. Der Agent bekommt die kleinste Rechtestufe, mit der die Aufgabe möglich ist.

3:52 Lesend für Analyse, schreibend im Arbeitsbereich für die Umsetzung, weitergehende Rechte nur mit ausdrücklicher Freigabe. Das Entscheidende steht in dem kleinen Wort Aufgabe. Die Stufe hängt nicht an der Person, nicht an ihrer Erfahrung und schon gar nicht an der Gewohnheit — sie hängt daran, was gerade getan werden soll.

4:10 Ein Review braucht keine Schreibrechte, auch wenn dieselbe Person zehn Minuten später etwas baut. Drei Stufen, und die dritte ist die interessante. Netz, Installation, Push — das sind die Aktionen, die aus Ihrem Rechner heraus wirken, und deshalb brauchen sie eine ausdrückliche Freigabe. Die mittlere Stufe deckt den größten Teil der Arbeit ab und ist völlig ausreichend, um eine Story umzusetzen.

4:33 Die Fußzeile enthält den Satz, den ich mir merken würde: Die Stufe gehört zur Aufgabe, nicht zur Person und nicht zur Gewohnheit. Denn Gewohnheit ist das eigentliche Problem — man setzt einmal alles auf erlaubt und ändert es nie wieder. Vier Dinge kommen zur Rechtestufe hinzu. Verzeichnisse mit Geheimnissen aus dem Kontext ausschließen — nicht nur schreibgeschützt, sondern gar nicht erst lesbar.

4:57 Netzzugriffe und erreichbare Werkzeugserver auf eine Liste beschränken. Erzeugung, Review und Merge auf verschiedene Instanzen verteilen. Und protokollieren, was ausgeführt wurde, nicht nur, was herauskam. Der letzte Punkt ist der, an den kaum jemand denkt: Im Zweifelsfall wollen Sie rekonstruieren können, welcher Befehl gelaufen ist — und das steht in keiner Zusammenfassung.

5:20 Sie sehen hier vier Zeilen, die in die Projektregeln gehören. Bemerkenswert daran ist, wie unspektakulär sie sind: eine Ausschlussliste, eine Netzregel, eine Liste von Aktionen mit Rückfragepflicht und eine Trennungsregel. Zusammen decken sie den Großteil der Risiken ab, über die wir gesprochen haben. Und dann kommt die Fußzeile, die diesen ganzen Block relativiert: Regeln sind Absicht — die Grenze setzen Sandbox, Rechte und der Pull Request.

5:46 Schreiben Sie die Regeln trotzdem auf. Aber verlassen Sie sich nicht auf sie, wo eine technische Grenze möglich ist.

Einbindung in den SDLC

5:53 Im dritten Kapitel geht es um Organisation. Die Versuchung ist groß, für KI-erzeugte Änderungen einen eigenen Prozess zu entwerfen — mit eigenen Regeln, eigenen Freigaben, eigener Dokumentation. Ich rate davon ab, und zwar aus einem sehr praktischen Grund, den wir uns gleich ansehen. Sicherheitspraktiken werden in den vorhandenen Entwicklungsprozess eingebettet, nicht daneben gestellt.

6:16 Das ist die Empfehlung des einschlägigen Rahmenwerks, und sie ordnet die Praktiken in vier Gruppen: Organisation vorbereiten, Software schützen, sicher entwickeln, auf Schwachstellen reagieren. Der praktische Grund dahinter: Ein zweiter Prozess neben dem echten wird umgangen, sobald es eilig wird. Und es wird immer irgendwann eilig.

6:35 Was dagegen im normalen Weg liegt — im Pull Request, in der Pipeline — wird nicht umgangen, weil man es dafür abschalten müsste. Diese Tabelle übersetzt die vier Gruppen in etwas, das man morgen umsetzen kann. Organisation heißt: festlegen, welche Anwendungsfälle und welche Werkzeuge erlaubt sind — diese Entscheidung fehlt in den meisten Teams.

6:57 Software schützen heißt: Herkunft und Abhängigkeiten prüfen. Sicher entwickeln heißt: Pull Request, Review und Scans verpflichtend. Und Reagieren heißt: ein Rückweg und ein Nachweis je Änderung. Die Fußzeile präzisiert den Nachweis: Welches Werkzeug, welcher Auftrag, wer hat freigegeben. Drei Angaben, die man später nicht rekonstruieren kann, wenn sie nicht mitgeschrieben wurden.

7:21 Die gute Nachricht dieses Kapitels: Der größte Teil ist bei den meisten von Ihnen schon vorhanden. Pull-Request-Pflicht, geschützte Branches, statische Analyse, Abhängigkeits- und Geheimnis-Scans, menschliches Review vor dem Merge. All das gilt unverändert weiter — es muss nur ausdrücklich auch für KI-erzeugte Änderungen gelten, und zwar ohne Ausnahme für die schnelle Kleinigkeit.

7:43 Zusätzlich kommen Freigaberegeln für sicherheitskritische Bereiche hinzu. Mehr ist es im Kern nicht. Der Aufwand liegt weniger in neuen Werkzeugen als in der Disziplin, keine Ausnahme zu machen. Der erste Punkt ist der, vor dem ich gewarnt habe: ein eigener KI-Prozess neben dem echten. Der zweite ist ein blinder Fleck vieler Reviews — Konfigurationen von Pipeline und Containern werden weniger streng geprüft als Anwendungscode, obwohl dort mehr Schaden möglich ist.

8:11 Der dritte betrifft den Nachweis, der fehlt, sobald jemand nachträglich fragt. Und der vierte ist eine unangenehme Erinnerung: Proprietärer Code verlässt das Haus, weil niemand geklärt hat, welche Anwendungsfälle überhaupt erlaubt sind. Diese Klärung gehört an den Anfang, nicht in die Aufarbeitung.

Freigabematrix

8:29 Zum Abschluss das Werkzeug, das all das zusammenfasst und im Moment der Eile trägt: eine Freigabematrix. Sie beantwortet für jede Umgebung dieselben vier Fragen — und ihr eigentlicher Wert liegt darin, dass sie vorher existiert und nicht mittendrin ausgehandelt wird. Für jede Umgebung vier Angaben: welche Rechtestufe gilt, welche Werkzeuge erlaubt sind, welche Aktionen eine menschliche Bestätigung brauchen und wer freigibt. Mehr nicht.

8:54 Der Wert liegt im Zeitpunkt — sie ersetzt die Einzelfallentscheidung im Moment der Eile, und das ist genau der Moment, in dem sonst die schlechten Entscheidungen fallen. Wenn die Matrix einmal steht, ist die Frage „darf der Agent das?" keine Diskussion mehr, sondern ein Nachschlagen. Das ist der ganze Trick. Ihre Aufgabe: Entwickeln Sie eine solche Matrix für fünf Umgebungen — vom lokalen Rechner bis zur produktionsnahen Stufe.

9:20 Für jede Umgebung Rechtestufe, erlaubte Werkzeuge, Bestätigungspflichten und Freigeber. Ein Rat, der die Übung deutlich wertvoller macht: Schreiben Sie bei den Freigebern Namen hin, keine Rollen. „Das Team" ist im Zweifelsfall niemand, und dann gibt sich jeder selbst frei. Wenn Ihnen für eine Umgebung kein Name einfällt, haben Sie einen Befund — und sollten ihn nicht mit einer Rollenbezeichnung überdecken.

9:45 Der erste Punkt ist der häufigste Fehler bei solchen Matrizen: Sie bleiben allgemein und entscheiden dadurch nichts. Eine Matrix, die überall „nach Bedarf" sagt, ist Dekoration. Der zweite ist eine Dosierungsfrage — zu viele Bestätigungen werden reflexhaft erteilt und sind dann schlimmer als keine, weil sie Sicherheit vortäuschen.

10:04 Der dritte ist ein häufiger Kopierfehler: für die produktionsnahe Umgebung derselbe Eintrag wie lokal. Und der vierte ist der, den wir gerade besprochen haben: kein benannter Freigeber, also faktisch Selbstfreigabe. Vier Punkte, und dieses Mal mit einem Ausrufezeichen. Zu viele Funktionen, zu viele Rechte und zu viel Autonomie sind drei getrennte Ursachen mit drei verschiedenen Gegenmitteln.

10:28 Repository-Inhalte sind Eingaben von außen, keine vertrauenswürdige Quelle. Die Rechtestufe gehört zur Aufgabe, nicht zur Gewohnheit. Und Sicherheit gehört in den bestehenden Prozess, nicht in einen zweiten daneben. Im nächsten Modul treten wir einen Schritt zurück und schauen uns an, welche Ansätze es neben dem hier gezeigten noch gibt — und wie man zwischen ihnen wählt.