Sicherheit & Agentenzugriff

Sicherheit und kontrollierter Agentenzugriff

0:00 Dieses Modul ist das wichtigste des ganzen Seminars — und das unbequemste. Wir sprechen darüber, was ein Coding Agent auf Ihrem Rechner tatsächlich darf. Die Antwort ist bei Pi verblüffend schlicht: alles, was Sie dürfen. Es gibt keinen eingebauten Sandkasten, und das Projekt sagt das offen. Ich finde diese Ehrlichkeit besser als das beruhigende Gefühl, das andere Werkzeuge mit Bestätigungsdialogen erzeugen.

0:24 Aber sie verlangt etwas von Ihnen: Sie müssen Rechte bewusst setzen, statt sich auf das Werkzeug zu verlassen. Wie das geht, sehen wir in den nächsten acht Kapiteln.

Rechte bewusst vergeben

0:35 „Pi does not include a built-in sandbox." Ein Satz aus der offiziellen Sicherheitsdokumentation, und er ist der Schlüssel zu diesem Modul. Die Entwickler haben sich gegen einen Sandkasten im Prozess entschieden — mit der Begründung, er erzeuge vor allem eine Sicherheitsillusion, während er ohnehin vom Wirtssystem abhängt.

0:54 Das ist eine vertretbare Position, aber sie verschiebt die Verantwortung. Der Kernsatz dieses Moduls lautet deshalb: Pi hat die Rechte Ihres Benutzerkontos. Behalten Sie diesen Satz im Kopf, wenn wir über Vertrauen, Werkzeuglisten und Container sprechen. Vier Themen. Erstens das Projektvertrauen — und vor allem, was es ausdrücklich nicht schützt; hier entstehen die meisten Missverständnisse.

1:17 Zweitens die Werkzeuglisten: Sie können dem Agenten Fähigkeiten wegnehmen, und das ist im Alltag überraschend praktisch. Drittens eine realistische Einschätzung unbeaufsichtigter Läufe, weil dort das Risiko wirklich liegt. Und viertens die Isolation — für die Fälle, in denen Rechte allein nicht genügen. Sie werden merken: Sicherheit entsteht bei Pi nicht durch eine Einstellung, sondern durch mehrere Schichten, die zusammenwirken.

Das Security Modell von Pi verstehen

1:43 Beginnen wir mit dem Modell selbst. Es ist schnell erklärt — und gerade weil es so einfach ist, lohnt es sich, die Konsequenzen sorgfältig durchzudenken. Die Dokumentation formuliert es unmissverständlich: Die eingebauten Werkzeuge lesen, schreiben und ändern Dateien und führen Shell-Befehle aus — mit den Rechten des Pi-Prozesses.

2:02 Und dieser Prozess läuft unter Ihrem Konto. Stellen Sie sich vor, Sie geben einem neuen Mitarbeiter Ihren Hausschlüssel und Ihre Kreditkarte, weil er Besorgungen machen soll. Das kann sehr gut funktionieren — aber Sie würden ihm nicht beides geben und dann den Raum verlassen. Genau diese Kombination aus Reichweite und Aufmerksamkeit ist das Thema dieses Moduls.

2:23 Vier Folgerungen. Wer den Prozess startet, leiht dem Agenten die eigenen Rechte — das ist keine Metapher, sondern technisch wörtlich zu nehmen. Erweiterungen sind TypeScript-Module mit genau denselben Rechten; fremde Erweiterung heißt fremder Code mit Vollzugriff. Entwicklerwerkzeuge wie Paketmanager oder Compiler laufen dabei als völlig normale Prozesse, ohne besondere Schranken.

2:46 Und daraus folgt der wichtigste Punkt: Sicherheit entsteht außerhalb von Pi — über Rechte, Umgebung und Ihre eigene Prüfung. Nicht über eine Einstellung im Werkzeug. Das Prinzip dieser Tabelle ist wichtiger als jede einzelne Zeile: Jeder Mechanismus hat einen genau umschriebenen Wirkungsbereich — und einen blinden Fleck.

3:06 Projektvertrauen schützt Ihre Konfiguration, nicht Ihre Dateien. Eine gekürzte Werkzeugliste verhindert, was fehlt, nicht was erlaubt ist. Ein Container schützt den Host, aber nicht die Pfade, die Sie hineingemountet haben. Und das Review Ihrer Änderungen findet falsche Ergebnisse, verhindert aber nicht die Ausführung. Deshalb kombinieren Sie diese Schichten.

3:27 Keine trägt allein — und genau das ist der Grund, warum wir hier acht Kapitel brauchen.

Vertrauen auf Projektebene bewusst vergeben

3:33 Jetzt zum Projektvertrauen. Das ist der Dialog, den Sie beim Start sehen, wenn ein Projekt eigene Konfiguration mitbringt. Und es ist der Mechanismus, der am häufigsten überschätzt wird. Pi fragt nach Vertrauen, wenn ein Projekt eigene Einstellungen, Erweiterungen, Skills oder Systemprompts enthält. Ihre Entscheidung wird lokal gespeichert.

3:55 Und jetzt der entscheidende Satz aus der Dokumentation: Projektvertrauen ist „only an input-loading guard" — ein Ladeschutz. Es verhindert, dass ein Repository still Ihre Konfiguration verändert, bevor Sie zustimmen. Es ist also ein Schutz gegen Manipulation der Werkzeugumgebung, kein Schutz Ihrer Daten. Das Bild: eine Türklingel, die verhindert, dass jemand unbemerkt Ihre Möbel umstellt — aber keine Alarmanlage.

4:20 Ohne Vertrauen lädt Pi keine projektlokalen Erweiterungen und Skills; das ist die eigentliche Wirkung. Sie können eine Grundhaltung voreinstellen — fragen, immer oder nie —, und ich empfehle nachdrücklich, bei „fragen" zu bleiben. In der Sitzung speichert ein eigener Befehl die Entscheidung. Und jetzt der Punkt, der in der Automatisierung zählt: Die nicht-interaktiven Modi fragen überhaupt nicht, sie folgen der Voreinstellung.

4:45 Wer also in einem Skript arbeitet, hat den Dialog nicht als Sicherheitsnetz — dort entscheidet die Konfiguration, die Sie vorher gesetzt haben. Diese vier Fehler entstehen fast alle aus Bequemlichkeit. Die Grundhaltung global auf „immer" zu setzen und dann fremde Repositories zu öffnen, ist der gefährlichste — damit haben Sie den Mechanismus abgeschafft, den Sie eigentlich wollten.

5:08 Der zweite ist begrifflich: Vertrauen mit Ausführungsschutz zu verwechseln. Dateien bleiben in jedem Fall erreichbar. Der dritte betrifft Skripte, in denen die Zustimmung fest verdrahtet wird, ohne dass jemand das Repository geprüft hat. Und der vierte ist einfach nur Disziplin: Schauen Sie in den Konfigurationsordner, bevor Sie zustimmen. Es sind meist nur wenige Dateien.

Dateizugriffe kontrollieren

5:30 Kommen wir zum Dateisystem. Und hier muss ich Ihre Erwartung dämpfen: Eine feingranulare Pfadfreigabe gibt es im Kern nicht. Kontrolle entsteht auf anderem Weg — dafür aber wirksam. Die Werkzeuge zum Lesen, Schreiben und Ändern arbeiten im Rahmen der Prozessrechte. Es gibt also keine Liste erlaubter Verzeichnisse, die Pi selbst durchsetzt.

5:52 Kontrolle entsteht über drei andere Hebel: die Wahl des Arbeitsverzeichnisses, die Rechte im Dateisystem samt schreibgeschützten Einbindungen — und eine Erweiterung, die Werkzeugaufrufe prüft. Das ist wie bei einem Werkstattbesuch: Sie schließen nicht jede Schublade einzeln ab, Sie führen den Besucher in den Raum, in dem er arbeiten soll.

6:11 Die Wahl des Raums ist Ihre wichtigste Entscheidung. Der erste Filter ist der Verzeichniswechsel — deshalb sollten Sie nie im Home-Verzeichnis starten, sondern immer im Projekt. Der zweite ist eine Hygienefrage: Geheimnisse gehören nicht in den Projektbaum, sondern in einen Passwortmanager, und Sie erinnern sich, dass Pi Schlüssel auch per Kommando holen kann.

6:31 Der dritte Hebel sind schreibgeschützte Einbindungen, wenn Lesen erlaubt und Schreiben ausgeschlossen sein soll. Und der vierte ist der Werkzeugaufruf-Hook, mit dem sich Pfade gezielt blockieren lassen — dazu kommt in Modul zehn der Code. Der rote Faden hier heißt: Reichweite verkleinern, bevor man Rechte diskutiert. Nur das Projekt öffnen, nie das ganze Home.

6:52 Secrets aus dem Arbeitsbaum entfernen — und dabei ausdrücklich die Umgebungsdateien prüfen, die man gewohnheitsmäßig übersieht. Heikle Pfade schreibgeschützt einbinden. Die Werkzeugliste kürzen, wozu wir in zwei Kapiteln kommen. Und zum Schluss der billigste Schritt von allen: die Änderungen als Diff ansehen. Versionskontrolle ist die günstigste Kontrollinstanz, die Sie haben — und sie ist bereits installiert.

Terminalzugriffe und ausführbare Befehle bewerten

7:19 Jetzt zum mächtigsten Werkzeug im ganzen Kern: der Shell. Ich sage bewusst „bewerten" und nicht „verbieten" — denn ohne Shell verliert der Agent einen großen Teil seines Nutzens. Das Shell-Werkzeug führt Befehle mit den Rechten des Prozesses aus. Und jetzt eine Eigenheit, die man wissen muss: Popup-Nachfragen für einzelne Aufrufe gibt es im Kern nicht.

7:40 Das Projekt führt „no permission popups" ausdrücklich unter den bewusst weggelassenen Funktionen. Die Begründung leuchtet mir ein: Wer zwanzig Mal am Tag bestätigt, klickt beim einundzwanzigsten Mal ohne zu lesen. Statt Scheinsicherheit setzen Sie die Rechte vorher — oder bauen genau die Prüfungen ein, die für Ihr Projekt wirklich sinnvoll sind.

8:01 Der Nutzen liegt auf der Hand: Tests, Linter, Build und Versionskontrolle direkt im Arbeitsablauf — der Agent kann seine Behauptungen selbst belegen. Das Risiko ist genauso konkret: löschende Befehle, Netzwerkzugriffe, Installationen. Deshalb der dritte Punkt: Eine Erweiterung kann den Werkzeugaufruf abfangen und gezielt blockieren.

8:21 Genau dort setzen auch die Guardrail-Pakete an, die wir in Modul sieben besprechen. Interessant ist die Denkweise dahinter: Man verlagert nicht das Werkzeug, man prüft den einzelnen Aufruf — im selben Prozess, mit Ihren Regeln. Worauf es hier ankommt, ist ein Muster in drei Schritten: Sie hören auf das Ereignis „Werkzeugaufruf", Sie prüfen, ob es die Shell ist und der Befehl Ihr Verdachtsmuster enthält — und dann fragen Sie nach oder blockieren.

8:48 Diese Rückgabe mit dem Blockier-Kennzeichen verhindert die Ausführung. Zwei Hinweise für die Praxis: Fassen Sie die Muster eng, sonst blockieren Sie Ihre eigene Arbeit. Und behalten Sie im Kopf, dass diese Prüfung im selben Prozess läuft — sie ist eine Hausregel, keine Isolation. Die vollständige Ereignisliste steht in der Extensions-Dokumentation.

Verfügbare Tools gezielt einschränken

9:09 Jetzt kommt der praktischste Hebel dieses Moduls — und der, den ich Ihnen am stärksten empfehle. Sie können dem Agenten Werkzeuge einfach wegnehmen. Das ist schlicht, wirksam und in Sekunden gesetzt. Pi erlaubt vier Wege, die Werkzeugliste zu beschneiden. In den Einstellungen legen Sie fest, welche eingebauten Werkzeuge beim Start überhaupt aktiv sind.

9:31 Beim Aufruf können Sie eine strikte Erlaubnisliste angeben, einzelne Werkzeuge herausfiltern oder alle abschalten. Das Bild dazu: Sie geben dem Handwerker nur die Werkzeuge mit, die er für diesen Auftrag braucht. Ein Schraubendreher kann keine Wand aufstemmen. Diese Art Kontrolle ist deshalb so angenehm, weil sie nicht auf Disziplin angewiesen ist — was fehlt, kann nicht versehentlich benutzt werden.

9:55 Für Analysearbeit brauchen Sie meist nur vier Werkzeuge: Lesen, Suchen, Finden, Auflisten. Ohne Schreib-, Änderungs- und Shell-Werkzeug kann eine Sitzung nichts verändern — das ist eine Garantie, keine Absichtserklärung. In CI-Läufen sind strikte Listen außerdem leichter zu begründen als mündliche Absprachen. Und ein Detail, das oft übersehen wird: Auch Werkzeuge aus Erweiterungen und Paketen fallen unter diese Filterung.

10:20 Die Werkzeugliste ist damit die zentrale Stelle, an der Sie die Reichweite des Agenten festlegen. Drei Zeilen, drei Betriebsarten. Die erste ist der Lesemodus für Analyse und Review — mein Favorit für fremden Code. Die zweite nimmt gezielt nur die Shell weg, lässt aber Änderungen zu; nützlich, wenn Sie Dateien bearbeiten, aber keine Befehle laufen lassen wollen.

10:43 Und die dritte schaltet alle Werkzeuge ab: Damit wird Pi zum reinen Erklärer, der nur mit dem arbeitet, was Sie ihm in den Prompt legen. Wenn Sie diese Vorgabe zum Projektstandard machen wollen, gehört sie in die Projekteinstellungen. In dieser Übung fahren Sie eine echte Analyseaufgabe mit minimaler Werkzeugmenge. Das Erfolgskriterium hat einen ungewöhnlichen zweiten Teil: Benennen Sie die Stelle, an der die Beschränkung gestört hat.

11:08 Denn genau dort lernen Sie etwas — nämlich welches Werkzeug für diese Art Aufgabe wirklich notwendig ist und welches Sie nur aus Gewohnheit dabeihaben. Viele Teilnehmerinnen und Teilnehmer stellen fest, dass sie für Reviews überhaupt kein Schreibrecht brauchen. Das ist eine Erkenntnis, die den Arbeitsalltag dauerhaft verändert.

Risiken autonom arbeitender Coding Agents erkennen

11:27 Jetzt reden wir über den Fall, in dem es wirklich gefährlich wird: wenn niemand zuschaut. Automatisierung ist verlockend — und sie verschiebt genau die Kontrollinstanz, auf die wir uns bisher verlassen haben. Risiko entsteht dort, wo Reichweite und Unbeaufsichtigtheit zusammenfallen. Die Dokumentation ist an dieser Stelle sehr direkt: Für unbeaufsichtigte Automatisierung und fremden Code solle man Pi in einer abgeschlossenen Umgebung laufen lassen — mit nur den Dateien und Zugangsdaten, die die Aufgabe wirklich braucht.

11:57 Das ist ein guter Maßstab, und er lässt sich als Frage formulieren: Welche Dateien und welche Schlüssel braucht dieser Lauf wirklich? Alles darüber hinaus ist unnötiges Risiko — und meist auch unnötiger Kontext. Vier Punkte. Der Agent kann jede Datei lesen, die Ihr Konto lesen darf — auch die, an die Sie gerade nicht denken.

12:17 Inhalte im Projekt sind Eingaben, und das gilt auch für manipulierte Anweisungen in einer Datei oder in einer abgerufenen Webseite. Die nicht-interaktiven Modi fragen nicht nach, sie folgen der Voreinstellung. Und fehlerhafte, aber plausibel formulierte Ausgaben fallen ohne Prüfung schlicht nicht auf. Das ist keine Panikmache: Es sind vier nüchterne Eigenschaften, die man beim Automatisieren einkalkulieren muss.

12:42 Diese vier Fehler haben einen gemeinsamen Kern: Man überträgt Gewohnheiten aus der interaktiven Arbeit in den unbeaufsichtigten Betrieb. Zugangsdaten des Hosts in einer Umgebung, in der der Agent frei arbeitet, ist der schwerste. Offener Netzzugriff, obwohl die Aufgabe ihn nicht braucht, ist der bequemste. Automatische Läufe ohne Protokoll und ohne Abbruchkriterium sind der unauffälligste — Sie merken erst hinterher, was passiert ist.

13:07 Und der vierte begleitet uns durch das ganze Seminar: die Ausgabe des Agenten als Beleg lesen statt als Behauptung.

Berechtigungen passend zum Projekt gestalten

13:14 Aus all diesen Überlegungen lässt sich etwas Praktisches machen: Profile. Statt bei jedem Start neu zu entscheiden, legen Sie einmal fest, was für welche Art Projekt gilt. Ein Profil bündelt vier Entscheidungen: Werkzeugliste, Standardmodell, Vertrauensvorgabe und Compaction-Verhalten. Festgeschrieben wird das in der Projektkonfiguration — und damit wird es reviewbar wie jede andere Datei.

13:38 Der Vorteil liegt in der Wiederholbarkeit: Gleiches Projekt, gleiche Rechte, unabhängig davon, wer gerade startet. Denken Sie an Schutzkleidung nach Arbeitsbereich: In der Werkstatt gilt eine andere Ausstattung als im Büro, und niemand diskutiert das jeden Morgen neu. Genau diese Ruhe gewinnen Sie mit Profilen. Vier Gewinne. Erstens Gleichbehandlung: Rechte hängen am Projekt, nicht an der Person am Terminal.

14:03 Zweitens Sichtbarkeit — Änderungen an Rechten laufen durch das Review, weil sie in einer Datei stehen. Drittens ein sinnvoller Umgang mit fremden Repositories: Die bekommen bewusst das engste Profil, und zwar von Anfang an. Und viertens etwas, das man im Gespräch mit Vorgesetzten oder Auditoren schätzen lernt: Sie können Ihre Rechtevergabe begründen, statt sie zu improvisieren.

14:25 Das ist mehr wert, als es zunächst klingt. Das Prinzip dieser drei Profile ist die aufsteigende Vergabe. Lesen ist das Basisprofil — vier Werkzeuge, keine Veränderung möglich, ideal für fremden Code und Reviews. Arbeiten ergänzt Schreiben und Ändern, für das eigene Projekt in der Feature-Arbeit. Voll ergänzt die Shell, sinnvoll in Projekten mit Tests und Build, deren Ausführung Sie ohnehin wollen. Die wichtige Regel steht in der Fußzeile: aufsteigend vergeben.

14:53 Beginnen Sie nie mit dem vollen Profil und nehmen dann weg — in der Praxis passiert dieses Wegnehmen nämlich nie. Hier wird es verbindlich. Sie entwerfen für ein echtes Projekt eine Konfiguration, in der jede Freigabe mit einem Satz begründet ist — und in der mindestens ein Werkzeug bewusst ausgeschlossen bleibt. Diese eine Ausschlussentscheidung ist der eigentliche Lernkern, denn sie zwingt zur Frage: Was braucht diese Arbeit wirklich?

15:19 Wer mag, nimmt die Stretch-Variante und konfiguriert dasselbe Projekt zusätzlich so, als wäre es ein fremdes Repository. Der Vergleich der beiden Fassungen ist erfahrungsgemäß der Moment, in dem das Thema klick macht.

Pi optional in Docker isolieren

15:32 Zum Abschluss die Schicht, die wirklich isoliert. Wenn Rechte nicht genügen, sperren Sie nicht einzelne Fähigkeiten ein, sondern den ganzen Prozess. Und dafür liefert die Dokumentation eine erfreulich knappe Vorlage. Statt eines Sandkastens im Prozess isoliert man den Prozess selbst. Die Dokumentation stellt dafür ein fertiges Container-Rezept bereit: eine schlanke Node-Basis mit Git und einer schnellen Suche, darin Pi installiert.

15:58 Das Projekt wird in ein Arbeitsverzeichnis eingebunden, die Einstellungen liegen in einem eigenen Datenträger. Das ist der Unterschied zwischen einem Zaun um den ganzen Garten und einzelnen Absperrbändern zwischen den Beeten. Der Zaun ist langweilig, aber er hält — und genau das wollen wir bei unbeaufsichtigter Arbeit. Vier Punkte. Alles läuft in der Container-Grenze: Werkzeuge, Kommandos, Erweiterungen. Erreichbar ist nur, was Sie eingebunden haben — der Rest des Systems bleibt unsichtbar.

16:27 Und dann eine ausdrückliche Warnung aus der Dokumentation: Wer sein persönliches Pi-Verzeichnis in den Container einbindet, legt damit Zugänge und Sitzungsdateien offen. Genau das nicht tun. Für stärkere Isolation nennt die Doku außerdem eine VM-basierte und eine richtliniengesteuerte Variante — sinnvoll, wenn Sie mit wirklich fremdem Code arbeiten.

16:49 Worauf es hier ankommt, sind die drei Einbindungen im Startbefehl. Der Schlüssel wird als Umgebungsvariable durchgereicht — Sie sehen, wie klein die Angriffsfläche wird, wenn nur ein einziger Zugang hineingeht. Das aktuelle Verzeichnis wird als Arbeitsbereich eingebunden; Änderungen dort betreffen tatsächlich Ihre Dateien, das ist gewollt und muss man wissen.

17:10 Und die Einstellungen landen in einem eigenen Datenträger, statt Ihr Host-Verzeichnis zu benutzen. Die Regel für die Praxis: Netzzugriff und Einbindungen so knapp halten, wie die Aufgabe es erlaubt.

Sicherheit ist Umgebung, nicht Einstellung

17:22 Drei Sätze zum Mitnehmen. Pi arbeitet mit den Rechten Ihres Kontos, es gibt keinen eingebauten Sandkasten — und das ist eine ehrliche Angabe, kein Mangel. Projektvertrauen schützt die Konfiguration, nicht das Dateisystem; verwechseln Sie die beiden nie. Und praktisch heißt Sicherheit hier: Werkzeuge beschneiden, Änderungen prüfen, Unbeaufsichtigtes isolieren. Damit haben wir das Fundament gelegt.

17:46 Im nächsten Modul wird es endlich handwerklich: Wir arbeiten mit dem Agenten an echtem Code — Features, Bugs, Refactoring. Und Sie werden merken, wie oft die Rechtefrage dabei mitschwingt.