Sicherheit, Permissions und Autonomie

Sicherheit, Permissions und Autonomie

0:00 Ein Werkzeug, das Befehle auf Ihrem Rechner ausführen darf, wirft Fragen auf, die bei einem Chatfenster nicht entstehen. Wie viel darf es? Wann fragt es nach? Und was passiert mit dem Code, den es liest? In diesem Modul geht es um die technische Seite der Kontrolle — nicht um Misstrauen gegenüber dem Modell, sondern um eine nüchterne Rechnung: Wie groß wäre der Schaden, wenn etwas schiefgeht, und wie wahrscheinlich würde es auffallen?

0:25 Aus dieser Rechnung folgt alles Weitere.

Sicherheit, Permissions und Autonomie

0:28 Der Leitsatz dieses Moduls: Vertrauen ist keine Einstellung — Grenzen schon. Acht Kapitel führen vom Sicherheitsmodell mit seinen zwei Reglern über Datei- und Systemzugriffe bis zur Abwägung zwischen Geschwindigkeit und Kontrolle. Dazwischen liegen die Themen, die in Unternehmen am häufigsten Rückfragen erzeugen: Was verlässt eigentlich den Rechner, und was gilt für Zugangsdaten?

0:50 Beispielprojekt bleibt kanuverleih, diesmal mit Blick auf Rechte und Risiken.

Das Sicherheitsmodell verstehen

0:55 Beginnen wir mit dem Modell dahinter, denn es ist einfacher, als viele erwarten. Es gibt genau zwei Regler, und wenn Sie deren Zusammenspiel verstanden haben, sind alle weiteren Einstellungen nur noch Kombinationen daraus. Sehen wir uns an, was diese beiden Regler steuern und warum es wichtig ist, sie nicht zu verwechseln.

1:13 Codex trennt zwei Dinge. Der Sandbox-Modus bestimmt, was technisch möglich ist — lesen, im Arbeitsbereich schreiben oder alles. Die Freigaberegel bestimmt, wann der Agent nachfragt, bevor er die Grenze überschreitet. Das Bild dazu: eine Werkstatt mit abgeschlossenen Schränken. Der Sandbox-Modus legt fest, welche Schränke überhaupt aufgehen. Die Freigaberegel legt fest, ob jemand fragt, bevor er einen davon öffnet.

1:40 Beides zusammen ergibt erst das tatsächliche Verhalten — deshalb lohnt es sich, sie getrennt zu betrachten. Drei Stufen mit klarer Steigerung. Nur lesen — der Agent kann sich alles ansehen, aber nichts verändern. Im Arbeitsbereich schreiben — er darf im Projektordner ändern und dort Befehle ausführen; das ist die Voreinstellung für lokale Arbeit. Und volle Rechte ohne Beschränkung.

2:04 Wichtig ist die Fußzeile: Im mittleren Modus bleibt der Netzzugriff standardmäßig zu. Das ist der Grund, warum Installationsbefehle in dieser Einstellung scheitern — nicht der Agent versagt, sondern die Grenze greift. Der zweite Regler, ebenfalls dreistufig. Bei der ersten Regel fragt der Agent vor allem, was außerhalb vertrauter Befehle liegt — das ist die vorsichtigste Einstellung.

2:28 Bei der zweiten fragt er, wenn die Sandbox-Grenze im Weg steht; das ist der Alltagsfall. Und bei der dritten fragt er gar nicht. Die Fußzeile ist der Punkt, den man sich merken muss: Beide Regler wirken zusammen. Erst ihre Kombination ergibt das Verhalten — und deshalb gibt es fertige Voreinstellungen, die gleich beide setzen.

2:48 Der erste Punkt ist der wichtigste dieses Kapitels und wird gern missverstanden: Die Sandbox schützt den Rechner, nicht das Repository. Innerhalb des Arbeitsbereichs darf der Agent alles — auch Dateien löschen. Wovor Sie Ihr Projekt schützt, ist Git, nicht die Sandbox. Der zweite erklärt ein häufiges Rätsel: Ohne Netz schlagen Installationsbefehle fehl.

3:09 Der dritte betrifft die Kombination aus vollen Rechten und keinen Rückfragen — die ist möglich, aber sie sollte eine bewusste Entscheidung sein. Und der vierte: Die Modi gelten je Session.

Berechtigungen konfigurieren

3:20 In der Praxis werden Sie die beiden Regler selten einzeln anfassen. Es gibt fertige Kombinationen für die typischen Situationen, und die decken den Alltag gut ab. Sehen wir uns an, wie man sie in der Session umschaltet, wie man sie dauerhaft festlegt und welche Stufe zu welcher Art von Arbeit passt. Statt beide Regler einzeln zu setzen, bietet Codex fertige Kombinationen: nur lesen, selbstständig im Arbeitsbereich arbeiten oder voller Zugriff.

3:46 Umgeschaltet wird in der Session oder dauerhaft in der Konfiguration. Das ist bequem und hat einen zweiten Vorteil: Sie können die Stufe benennen. „Ich arbeite hier nur lesend" ist eine Aussage, die man im Team verstehen kann — während „sandbox_mode gleich read-only bei approval_policy untrusted" eine Konfiguration ist, die man nachschlagen muss.

4:08 Vier Handgriffe in der laufenden Sitzung. Sie wählen eine Voreinstellung, sehen sich die aktuellen Rechte und den Modus an, prüfen die bisherigen Änderungen und geben eine anstehende Anfrage frei. Der zweite ist der, den man sich angewöhnen sollte — gerade weil die Einstellungen aus mehreren Quellen kommen können und man sonst nicht sicher weiß, womit man arbeitet.

4:28 Die Fußzeile nennt die wichtige Einschränkung: In der Session gesetzte Rechte gelten nur für diese Session. Was dauerhaft gelten soll, gehört in die Konfigurationsdatei. Die ersten beiden Zeilen sind die Voreinstellung für lokale Arbeit — im Arbeitsbereich schreiben, nachfragen, wenn die Grenze im Weg steht. Darunter steht auskommentiert die engere Variante: nur lesen, vor allem nachfragen.

4:51 Diese Form finde ich praktisch: Man hat beide Möglichkeiten vor Augen und kann bewusst umschalten, statt jedes Mal die Schreibweise nachzuschlagen. Die Datei liegt in Ihrem Heimatverzeichnis und gilt zunächst für alle Projekte. Vier Situationen. Fremden Code verstehen — da genügt Lesen, und mehr sollte es auch nicht sein. Ein eigenes Projekt bearbeiten — Schreiben im Arbeitsbereich.

5:15 Lange Läufe ohne Aufsicht — nur in einer isolierten Umgebung, also Container oder Cloud, nicht auf Ihrem Arbeitsrechner. Und ein unbekanntes Repository — immer die engste Stufe zuerst. Der letzte Punkt ist mehr als Vorsicht: In fremdem Code können Anweisungen stehen, die an einen Agenten gerichtet sind. Lesen ist harmlos, Ausführen nicht.

5:37 Diese Übung ist schnell gemacht und lehrreich: Stellen Sie einen Auftrag, der bewusst an die Grenze stößt. Der Hinweis nennt das beste Beispiel — etwas, das installiert werden will. Dann sehen Sie die Netzgrenze in Aktion und verstehen zugleich, warum manche Aufträge scheinbar grundlos scheitern. Führen Sie denselben Auftrag anschließend mit erweiterten Rechten aus.

5:58 Der Unterschied sollte für Sie erklärbar sein — und genau diese Erklärung brauchen Sie später, wenn ein Kollege fragt, warum bei ihm etwas nicht geht.

Datei- und Systemzugriffe

6:07 Sprechen wir über die Grenze, die im Alltag am meisten zählt: den Arbeitsbereich. Alles innerhalb ist erlaubt, alles außerhalb braucht eine Freigabe. Klingt einfach — ist es auch, solange man weiß, wo diese Grenze tatsächlich verläuft. Und da gibt es zwei Stellen, an denen man sich täuschen kann. Im Standardmodus darf der Agent innerhalb des Arbeitsbereichs schreiben — also im Projektordner.

6:32 Alles darüber hinaus, ob Heimatverzeichnis, Systempfade oder Netz, verlangt eine ausdrückliche Freigabe. Der Arbeitsbereich ist dabei nicht abstrakt: Es ist das Verzeichnis, in dem Sie Codex gestartet haben. Deshalb war der Hinweis in Modul eins wichtig, dass man im Projektordner startet. Wer versehentlich eine Ebene höher startet, hat den Arbeitsbereich auf alle Nachbarprojekte ausgedehnt — und merkt es nicht.

6:57 Vier Kategorien außerhalb der Grenze. Konfigurationsdateien im Heimatverzeichnis — dort liegen Zugangsdaten für allerlei Dienste. Schlüsselbunde, Anmeldedaten und Zertifikate. Andere Projekte auf derselben Maschine. Und alles im Netz, einschließlich der Paketquellen. Diese Aufzählung erklärt, warum die Voreinstellung so gewählt ist, wie sie ist: Nicht weil man dem Modell etwas unterstellt, sondern weil ein Versehen in jeder dieser Kategorien Folgen hätte, die weit über das Projekt hinausreichen.

7:28 Der erste Punkt wiederholt eine Warnung aus Modul zwei, weil sie hierher gehört: Die Ignorierdatei hält Inhalte aus dem Kontext, nicht vom Zugriff fern. Der zweite erklärt es technisch — Shell-Befehle des Agenten lesen daran vorbei. Der dritte ist die eben erwähnte Falle mit dem zu weit gewählten Arbeitsbereich; sie hebt die Grenze faktisch auf.

7:48 Und der vierte ist ein technisches Detail mit Wirkung: Symbolische Verweise führen aus dem Arbeitsbereich heraus, ohne dass man es dem Pfad ansieht. Bei dieser Übung geht es darum, eine Annahme durch eine Feststellung zu ersetzen. Prüfen Sie, welche Pfade tatsächlich beschreibbar sind und welche eine Freigabe auslösen. Der Hinweis nennt die Stelle, an der man am ehesten überrascht wird: Umfasst Ihr Arbeitsbereich versehentlich das übergeordnete Verzeichnis?

8:14 Das passiert schneller, als man denkt — etwa wenn man Codex im Monorepo-Wurzelordner startet, obwohl man nur in einem Paket arbeiten will.

Shell-Befehle sicher ausführen

8:23 Jetzt zu der Fähigkeit, die den Agenten stark macht und zugleich das größte Schadenspotenzial trägt: dem Ausführen von Befehlen. Ohne sie könnte er nicht testen, nicht bauen, nicht prüfen. Mit ihr wirkt jeder Befehl sofort und meist unwiderruflich. Sehen wir uns an, wie man damit umgeht, ohne in gedankenloses Wegklicken zu verfallen.

8:44 Der Agent führt Befehle aus, um zu bauen, zu testen und zu prüfen. Genau das ist seine Stärke und zugleich der Punkt mit dem größten Schadenspotenzial: Ein Befehl wirkt sofort und meist unwiderruflich. Anders als bei einer Codeänderung, die im Diff sichtbar wird und sich verwerfen lässt, ist ein ausgeführter Löschbefehl einfach ausgeführt.

9:03 Deshalb gilt für Befehle eine andere Aufmerksamkeit als für Code — und deshalb lohnt es sich, sie vor der Freigabe wirklich zu lesen. Fünf Regeln. Vorgeschlagene Befehle vor der Freigabe lesen. Bei Löschbefehlen und Umleitungen genau hinsehen. Netzzugriffe bewusst und einzeln freigeben. Lange Läufe ohne Rückfrage nur in isolierter Umgebung. Und nach dem Lauf Diff und Historie prüfen.

9:27 Die Fußzeile formuliert die einfachste Regel von allen: Ein Befehl, den Sie nicht verstehen, ist kein Kandidat für eine schnelle Freigabe. Das klingt selbstverständlich, ist aber genau die Situation, in der die meisten Freigaben falsch erteilt werden. Vier Muster, die Aufmerksamkeit verdienen. Rekursives Löschen oder erzwungenes Überschreiben.

9:49 Umleitungen, die bestehende Dateien ersetzen — das kleine Zeichen, das eine Datei überschreibt statt anzuhängen, ist im Vorbeilesen leicht zu übersehen. Installation von Paketen aus unbekannter Quelle. Und alles, was Zugangsdaten liest oder verschickt. Diese vier decken den Großteil dessen ab, was im schlimmsten Fall Schaden anrichtet — und sie lassen sich in wenigen Sekunden prüfen.

10:13 Der erste Punkt beschreibt das eigentliche Sicherheitsproblem im Alltag: Freigaben im Minutentakt führen zum blinden Bestätigen. Wer alle zwei Minuten gefragt wird, liest irgendwann nicht mehr — und dann ist die Rückfrage wirkungslos geworden, ohne dass es jemand merkt. Der zweite ist die Konsequenz: Ein einziger unbedachter Befehl macht viel Arbeit zunichte. Der dritte warnt vor Skripten, die mehr tun, als ihr Name verspricht.

10:37 Und der vierte erinnert an das Sicherheitsnetz: Ohne Commit vorher ist die Wirkung schwer rückgängig zu machen.

Grenzen autonomer Aktionen

10:44 Jetzt zur wichtigsten Frage dieses Moduls: Wie viel Selbstständigkeit ist angemessen? Die übliche Antwort lautet „so viel, wie man dem Modell zutraut" — und das ist die falsche Perspektive. Sehen wir uns an, worauf es stattdessen ankommt. Die Rechnung, die dahintersteht, ist aus der Risikobetrachtung bekannt. Wie selbstständig der Agent arbeiten darf, ist keine Frage des Vertrauens in das Modell, sondern des Schadens, den ein Fehler anrichten kann — und der Wahrscheinlichkeit, dass er auffällt.

11:14 Das ist derselbe Maßstab, den Sie auch bei Menschen anlegen. Eine erfahrene Kollegin darf ohne Rückfrage refaktorieren, aber die Produktionsdatenbank rührt niemand allein an. Nicht weil man ihr misstraut, sondern weil der Schaden im Fehlerfall unverhältnismäßig wäre. Vier Zeilen mit abnehmender Autonomie und einer klaren Logik in der rechten Spalte. Code lesen und erklären: hohe Autonomie, denn es kann kein Schaden entstehen.

11:40 Ein Feature im Branch: mittlere Autonomie, weil Diff und Tests abfangen. Abhängigkeiten ändern: niedrig, weil es über das Projekt hinauswirkt. Migration und Deployment: keine, weil beides schwer umkehrbar ist. Die Fußzeile bringt den Perspektivwechsel auf den Punkt: Die Frage ist nicht, ob der Agent es kann, sondern was ein Fehler kostet.

12:02 Vier Voraussetzungen. Ein sauberer Ausgangszustand in der Versionskontrolle — sonst gibt es keinen Rückweg. Tests, die eine Verschlechterung bemerken; ohne sie merkt niemand, wenn etwas kaputtgeht. Ein begrenzter, klar benannter Wirkungsbereich. Und jemand, der das Ergebnis tatsächlich prüft. Der letzte Punkt klingt banal, ist aber der, der in der Praxis fehlt.

12:25 Autonomie ohne nachfolgende Prüfung ist keine Autonomie — es ist Blindflug mit besonders effizientem Autopiloten. Diese Übung führt zu einem Dokument, das Sie im Team teilen können: eine Zuordnung von Aufgabentypen zu Autonomiestufen, jede begründet. Der Hinweis nennt einen guten Einstieg — beginnen Sie bei den Aufgaben, die Sie heute schon delegieren, und prüfen Sie ehrlich, ob die Stufe passt.

12:49 Erfahrungsgemäß findet man dabei zwei Sorten von Abweichungen: Dinge, die man vorsichtiger behandelt als nötig, und Dinge, bei denen man aus Gewohnheit großzügiger ist, als man sollte.

Profile und Projektkonfigurationen

13:00 Wenn Sie täglich zwischen verschiedenen Arbeitsweisen wechseln, wird das Umstellen einzelner Werte lästig — und lästige Handgriffe unterbleiben. Profile lösen das. Sehen wir uns an, wie man sie anlegt, wofür sie sich lohnen und wo die Gefahr liegt, dass ein bequemes Profil zur stillen Voreinstellung wird. Profile bündeln eine Kombination aus Modell, Denkaufwand und Rechten unter einem Namen.

13:23 So lässt sich zwischen vorsichtigem Sichten und zügigem Arbeiten wechseln, ohne die Einstellungen einzeln anzufassen. Der Vergleich, der trägt: die Fahrmodi im Auto. Sie stellen nicht Federung, Lenkung und Gasannahme einzeln ein, sondern wählen einen Modus. Der wesentliche Unterschied hier: Sie legen die Modi selbst fest — und tragen damit auch die Verantwortung, sie sinnvoll zu schneiden.

13:47 Zwei Profile mit sprechenden Namen. „Sichten" ist eng: nur lesen, vor allem nachfragen — gedacht für fremde Repositorien und für den ersten Blick in unbekannten Code. „Bauen" ist der Alltagsmodus: im Arbeitsbereich schreiben, nachfragen, wenn die Grenze im Weg steht. Die Fußzeile ist wichtig für die Erwartung: Profile nehmen Ihnen die Entscheidung nicht ab.

14:08 Sie machen sie wiederholbar — und das ist genau dann wertvoll, wenn man unter Zeitdruck nicht nachdenken will. Vier Anwendungsfälle. Fremde Repositorien grundsätzlich nur lesen — das ist eine gute Standardhaltung. Eigene Projekte zügiger bearbeiten. Automatisierte Läufe eng und ohne Rückfragen konfigurieren, weil dort niemand antwortet. Und das Umstellen ohne Nachdenken über Einzelwerte.

14:32 Der Gewinn liegt vor allem im ersten Punkt: Wenn das Sichten fremden Codes ein benanntes Profil hat, wählen Sie es auch — statt aus Bequemlichkeit im Alltagsmodus zu bleiben. Der erste Punkt beschreibt den häufigsten Fehler: Ein zu großzügiges Profil wird zur stillen Voreinstellung. Man legt es für einen Sonderfall an und arbeitet irgendwann immer darin. Der zweite betrifft global gesetzte Werte, die auch in fremden Projekten wirken.

14:59 Der dritte ist eine Erinnerung: Profile ersetzen kein Nachdenken je Aufgabe. Und der vierte ist praktisch — wer den Namen nicht liest, weiß nicht, womit er arbeitet. Deshalb lohnt sich der Blick auf den Status.

Datenschutz und sensible Daten

15:12 Kommen wir zu der Frage, die in Unternehmen meist zuerst gestellt wird: Was passiert eigentlich mit dem Code, den der Agent liest? Die Antwort ist unbequem einfach, und sie hat Konsequenzen für die Art, wie man Repositorien pflegt. Sehen wir uns an, welche das sind und was daraus praktisch folgt. Der Agent verarbeitet Inhalte beim Anbieter. Alles, was in den Kontext gerät — Quellcode, Konfiguration, Logausgaben — verlässt damit die lokale Maschine.

15:39 Das ist beherrschbar, aber es muss bewusst entschieden sein. Und es ist keine Besonderheit dieses Werkzeugs, sondern gilt für jeden cloudbasierten Dienst. Der Unterschied liegt im Umfang: Ein Agent liest deutlich mehr als das, was Sie ihm bewusst zeigen — er sucht ja selbst. Genau deshalb lohnt sich die Frage, was in Ihrem Repository überhaupt liegt.

16:01 Vier Kategorien. Zugangsdaten in Konfiguration, Logs und Testdaten — der Klassiker, und er findet sich in fast jedem gewachsenen Projekt. Personenbezogene Daten in Fixtures und Datenbankauszügen; auch das ist verbreiteter, als man denkt. Fremdes Material unter restriktiver Lizenz. Und interne Systeme, die in Logausgaben auftauchen — Hostnamen, interne Adressen, Strukturinformationen. Die ersten beiden sind ohnehin ein Problem, unabhängig von Agenten.

16:32 Ein Agent macht sie nur sichtbar. Fünf Schritte in sinnvoller Reihenfolge. Klären, was im Unternehmen zulässig ist — das ist keine technische Frage. Geheimnisse aus dem Repository entfernen; das ist ohnehin überfällig. Große und heikle Ordner aus dem Kontext nehmen. Testdaten anonymisieren statt nur zu verkleinern. Und bei Unsicherheit den engsten Modus wählen. Die Fußzeile trennt Hygiene von Schutz: Die Ignorierdatei ist Hygiene.

17:01 Echter Schutz sind fehlende Geheimnisse und enge Rechte — alles andere ist Kosmetik. Der erste Punkt ist eine harte, aber richtige Regel: Ein Geheimnis, das der Agent gelesen hat, gilt als kompromittiert. Nicht weil etwas Böses passiert wäre, sondern weil Sie es nicht mehr ausschließen können — und Zugangsdaten austauschen ist billiger als hoffen.

17:22 Der zweite betrifft Logausgaben, die beim Einfügen mehr enthalten, als man bedenkt. Der dritte ist die rechtliche Ebene: Vertragliche Vorgaben gelten unabhängig von der Technik. Und der vierte gilt für Cloud-Läufe, die eine bewusste Freigabe brauchen.

Geschwindigkeit gegen Kontrolle

17:38 Zum Abschluss die Abwägung, die dieses ganze Modul zusammenfasst. Mehr Autonomie bedeutet schnellere Ergebnisse und weniger Kontrollpunkte. Die interessante Erkenntnis dabei: Man gibt Kontrolle nie wirklich ab — man verschiebt nur, wo sie stattfindet. Sehen wir uns an, welche drei Möglichkeiten es dafür gibt. Mehr Autonomie bedeutet schnellere Ergebnisse und weniger Kontrollpunkte.

18:01 Die Frage ist nicht, ob man Kontrolle abgibt, sondern an welcher Stelle man sie zurückholt — vor der Ausführung oder danach im Review. Diese Umformulierung ist mehr als rhetorisch. Sie macht deutlich, dass eine schnelle Einstellung nicht weniger Arbeit bedeutet, sondern verschobene Arbeit. Wer vorne spart und hinten nicht nachholt, hat die Kontrolle nicht verschoben, sondern gestrichen.

18:24 Drei Ansätze mit jeweils passendem Einsatzgebiet. Viele Rückfragen: Kontrolle vor der Aktion, passend für fremden Code und heikle Pfade. Selbstständig im Branch: Kontrolle nach dem Lauf, passend für eigene Projekte mit Tests. Ohne Rückfragen: Kontrolle nur im Review, und das setzt eine isolierte Umgebung voraus. Die Fußzeile ist die Kernaussage: Ganz ohne Kontrolle geht keine der drei Zeilen. Sie verschieben nur ihren Ort — und müssen dafür sorgen, dass sie dort auch stattfindet.

18:55 Der erste Punkt beschreibt ein Paradox, das man ernst nehmen sollte: Ständige Rückfragen erzeugen genau das Wegklicken, das sie verhindern sollen. Zu viel Sicherheit kann also unsicherer sein als weniger. Der zweite ist die Gegenrichtung: Volle Autonomie ohne Tests verschiebt die Kontrolle ins Nichts. Der dritte beschreibt die schleichende Gewöhnung — die schnellste Einstellung wird zur einzig benutzten. Und der vierte: Ein Profil überlebt den Anlass, für den es gedacht war.

19:22 Das Ergebnis dieser Übung ist kurz: Modus, Freigaberegel und Profil, jeweils mit einem Satz Begründung. Wenn Ihnen die Begründung schwerfällt, ist das die eigentliche Erkenntnis. Und der Hinweis enthält die wichtigste Nachbereitung: Prüfen Sie die Begründung nach zwei Wochen erneut. Denn Gewohnheit ist keine Begründung, und die meisten Einstellungen driften mit der Zeit in Richtung mehr Bequemlichkeit — meist ohne dass jemand die Entscheidung bewusst getroffen hätte.

19:49 Vier Punkte zum Mitnehmen. Zwei Regler: Der Sandbox-Modus bestimmt das Mögliche, die Freigaberegel das Nachfragen. Die Sandbox schützt den Rechner, nicht das Repository — dafür ist Git zuständig. Autonomie bemisst sich am Schaden eines Fehlers, nicht am Vertrauen ins Modell. Und alles, was der Agent liest, verlässt den Rechner, weshalb Geheimnisse ohnehin nicht ins Repository gehören.

20:13 Im nächsten Modul geht es um etwas Konstruktiveres: wie Sie wiederkehrende Abläufe als wiederverwendbare Fähigkeiten verpacken.