# Gemeinsam genutzte Entwickler-Macs: Zugriff von Agents auf Tools kontrollieren Ein gemeinsam genutzter Entwickler-Mac kann ein Team unterstützen. Autonome Agents lassen sich darauf aber nicht sicher ausführen, wenn jede Person und jeder lokale Prozess denselben Stapel an Zugangsdaten erbt. Das Problem beginnt meist mit Bequemlichkeit: ein Projekt-Token in einer Shell-Datei, ein einmal geladener SSH-Schlüssel, ein Editor aus einem alten Terminal und ein Agent, dem man sagt: «Deploy das einfach.» Kurz darauf kann niemand mehr sagen, welche Person die Aktion autorisiert hat oder welcher Prozess noch Zugriff besitzt. Behandle Identität, Verwahrung von Zugangsdaten, Autorisierung und Nachweise als getrennte Aufgaben. Eine macOS-Anmeldung zeigt, welchem Benutzer ein Prozess gehört. Sie beweist aber nicht, wem ein Cloud-Token gehört, ob ein Agent ihn verwenden darf oder ob ein Prozess, der die Mittagspause überlebt hat, den Zugriff behalten sollte. Teams, die diese Aufgaben vermischen, schaffen eine sehr leise Form schleichender Berechtigungszunahme. ## Gemeinsam genutzte Geräte brauchen getrennte Identitäten Eine gemeinsam genutzte Workstation funktioniert nur dann zuverlässig, wenn jede Person, jede Zugangsinformation und jede Agent-Ausführung eine eigene Identität besitzt, die sich prüfen und widerrufen lässt. Die Geräteanmeldung ist die erste Grenze, aber nicht das gesamte Konzept. Richte nicht ein einziges «dev»-Konto für eine Gruppe ein, nur weil es leichter zu verwalten scheint. In diesem Konto werden Dateibesitz, Shell-Verlauf, Browsersitzungen, Schlüsselbund-Einträge und laufende Prozesse gemeinschaftlich. Wenn ein Deployment schiefgeht, zeigt der Audit-Eintrag nur, dass das gemeinsame Konto die Aktion ausgeführt hat. Das ist keine Verantwortlichkeit, sondern eine Sackgasse. Gib jedem Entwickler ein eigenes macOS-Konto. Verwende für unbeaufsichtigte Aufgaben, die tatsächlich eine eigene Identität brauchen, zusätzlich eine separate Dienstidentität. Eine Dienstidentität braucht einen Besitzer, einen festgelegten Zweck, einen engen Satz an Zugangsdaten und einen Plan für ihre Ausmusterung. Sie darf nicht zu einem getarnten Teamkonto werden, das man nutzt, sobald die eigene Einrichtung unbequem ist. Bei einem Agent ist dieser Unterschied besonders wichtig. Ein Coding-Agent kann Unterprozesse starten, sein Arbeitsverzeichnis lesen, die geerbte Umgebung untersuchen und freigegebene Tools aufrufen. Wenn zwei Personen Agents über dasselbe lokale Konto ausführen, können die alte Umgebung oder ein Hilfsprozess der einen Person zur unbeabsichtigten Autorität der anderen werden. Apple Platform Security beschreibt die Schutzmechanismen von macOS für getrennte Benutzerdaten und Systemdienste. Diese Schutzmechanismen sind wichtig. Sie entscheiden aber nicht, ob ein in ein Repository, ein gemeinsames Verzeichnis oder eine Prozessumgebung kopiertes Token für den Prozess geeignet ist, der es findet. Dateiberechtigungen begrenzen eine Fehlerklasse. Sie stellen keine Absicht fest. Führe für jede Zugangsinformation, die Produktionssysteme, Quellcodeverwaltung, die Veröffentlichung von Paketen oder Kundendaten verändern kann, einen einfachen Besitznachweis: - Benenne einen menschlichen Besitzer und eine Vertretung. - Halte Dienst, erlaubte Aktionen und Umgebungen fest. - Dokumentiere, wo das Geheimnis liegt und wie es rotiert wird. - Lege einen Prüftermin und einen Auslöser für die Ausmusterung fest. Vermeide es, das eigentliche Geheimnis in diesem Nachweis zu speichern. Ziel ist sichtbare Verantwortlichkeit, nicht eine weitere Kopie der Zugangsdaten. Ein benannter Besitzer muss nicht jede Aktion manuell ausführen. Er sorgt dafür, dass jemand eine direkte Frage beantworten kann: Warum existiert diese Zugangsinformation, wer darf ihre Verwendung autorisieren und was passiert, wenn wir sie jetzt widerrufen? Wenn niemand das beantworten kann, widerrufe sie in einem sicheren Zeitfenster und richte den Zugriff mit einem klareren Zweck neu ein. ## Ein Unix-Konto enthält kein kopiertes Geheimnis macOS-Kontogrenzen schützen Daten nur, solange die Zugangsinformation innerhalb dieser Grenze bleibt und nicht über einen anderen Weg angeboten wird. Teams sichern oft das Home-Verzeichnis und lassen dasselbe Token anschließend in Projektdateien, im Terminalverlauf, in Editoreinstellungen, in CI-Exporten oder einem lang laufenden Agent-Prozess liegen. Beginne mit einem Inventar der Orte, die Entwickler tatsächlich verwenden. Gehe dabei sorgfältig und mit Erlaubnis vor: Ein aktives Geheimnis in eine gemeinsam sichtbare Terminalhistorie zu schreiben, erzeugt genau das Problem, nach dem du suchst. ```sh # Nach Dateinamen und wahrscheinlichen Konfigurationsverweisen suchen, nicht nach Geheimniswerten. find "$HOME" -maxdepth 3 \( -name '.env' -o -name '.netrc' -o -name 'credentials*' \) -print # Nur die Namen von Umgebungsvariablen der aktuellen Shell anzeigen. env | cut -d= -f1 | grep -E 'TOKEN|SECRET|KEY|PASSWORD' || true # Geladene SSH-Identitäten anzeigen, ohne private Schlüssel zu drucken. ssh-add -l ``` Der letzte Befehl gibt normalerweise eine Zeile pro Identität mit Fingerabdruck, Algorithmus und Kommentar aus. Wenn `The agent has no identities.` erscheint, ist das ein nützliches Ergebnis. Wenn ein Fingerabdruck erscheint, den du nicht erklären kannst, solltest du den Rechner nicht länger als sauber betrachten. Finde heraus, welcher Ablauf ihn geladen hat. Führe `env` nicht innerhalb eines Agent-Transkripts aus und kopiere die Ausgabe anschließend in ein Ticket. Agents, Terminals, Editorenprotokolle und Support-Tickets sind schlechte Speicherorte für Geheimnisse. Suche zuerst nach Variablennamen und Dateipfaden. Rotiere eine Zugangsinformation, wenn du Grund zu der Annahme hast, dass ihr Wert in ein Transkript oder in die Repository-Historie gelangt ist. Eine häufige, aber unzureichende Empfehlung lautet: «Lege Geheimnisse in einer lokalen .env-Datei ab und halte sie aus Git heraus.» Sie ist beliebt, weil sie in fünf Minuten funktioniert. Gleichzeitig wird jedes Programm, das aus diesem Verzeichnis gestartet wird, zu einem möglichen Leser der Zugangsdaten. Ein `.gitignore`-Eintrag verhindert einen Commit. Er hindert aber keinen lokalen Agent daran, die Datei zu lesen, kein Archivierungsprogramm daran, sie einzusammeln, und keinen Entwickler daran, sie in das nächste Projekt zu kopieren. Verwende `.env`-Dateien nur für lokale Einstellungen mit geringen Folgen oder für vorübergehende Migrationsarbeiten mit einem festgelegten Löschdatum. Zugangsdaten, die gemeinsam genutzte Systeme verändern können, gehören in einen geschützten lokalen Speicher. Dem Agent sollte eine Aktion und nicht der rohe Wert bereitgestellt werden. Auch die Vererbung von Prozessen verdient Misstrauen. Ein Terminal exportiert `DEPLOY_TOKEN`, ein Editor startet aus diesem Terminal, eine Erweiterung startet einen Language Server und ein Agent ruft über den Editor ein Tool auf. Der ursprüngliche Entwickler hat das Token vielleicht seit Stunden vergessen, aber jeder Kindprozess kann es weiterhin lesen. Die macOS-Berechtigungen haben genau das getan, was von ihnen verlangt wurde. Das Team hat zu vielen Prozessen das Geheimnis gegeben. ## Verwahrung von Zugangsdaten und Aktionsberechtigung sind verschieden Eine Zugangsinformation beantwortet die Frage «Wer kann sich authentifizieren?». Eine Autorisierung beantwortet die Frage «Darf dieser Prozess diese Aktion jetzt ausführen?». Teams behandeln den Besitz der ersten Information oft als Beweis für die zweite, besonders bei API-Tokens. Gib einem Agent kein Bearer-Token, nur weil er einen einzigen API-Aufruf ausführen muss. Ein Bearer-Token gilt für jeden, der es besitzt, und zwar im Rahmen seiner Berechtigungen. Sobald es im Kontext des Agents, in einem Tool-Argument, in der Umgebung eines Kindprozesses oder in einer Debug-Ausgabe auftaucht, musst du davon ausgehen, dass jedes System mit Lesezugriff es wiederverwenden kann. Definiere stattdessen einen Aktionsvertrag. Der Agent fordert eine benannte Operation mit strukturierten Eingaben an. Eine vertrauenswürdige lokale Komponente verwahrt die Zugangsinformation, prüft Ziel und Form der Anfrage, führt den Aufruf aus und gibt das Ergebnis zurück. Der Agent erhält überhaupt keine Zugangsinformation. Ein Release-Agent könnte beispielsweise einen Deployment-Eintrag erstellen müssen. Seine Anfrage könnte so aussehen: ```json { "action": "create_deployment", "environment": "staging", "revision": "7c31f4a", "summary": "Fix request timeout handling" } ``` Die vertrauenswürdige Komponente kann `create_deployment` einem freigegebenen Endpunkt und einer gespeicherten Zugangsinformation zuordnen. Sie sollte Eingaben ablehnen, die einen Host, Pfad, Authorization-Header oder beliebigen Request-Body einschleusen wollen. Wenn der Aktionsvertrag beliebige URLs und Header erlaubt, hast du allgemeinen Netzwerkzugriff nur mit mehr Zeremonie nachgebaut. Halte den Umfang der Zugangsinformation so klein, dass ein Fehler begrenzte Folgen hat. Trenne Lese- und Schreibzugriff. Trenne Staging und Produktion. Bevorzuge kurzlebige Zugangsdaten, wenn der vorgelagerte Dienst sie unterstützt. Betrachte eine kurze Lebensdauer aber nicht als Heilmittel gegen einen zu großen Umfang. Ein Token kann auch in seiner ersten Sekunde einen irreversiblen Aufruf ermöglichen. Dasselbe gilt für SSH. Ein privater SSH-Schlüssel beweist die Kontrolle über eine Identität. Er erklärt aber nicht, warum ein lokaler Agent in diesem Moment einen Befehl auf einem Host ausführen sollte. Host- und Befehlsauswahl müssen Teil der Autorisierungsentscheidung sein. Gib einem Agent keinen allgemeinen Shell-Zugang und hoffe, dass Repository-Anweisungen ihn zurückhalten. ## Lokale Prozesse können mehr Autorität ausleihen als beabsichtigt Ein lokaler Prozess kann Autorität über Umgebungsvariablen, offene Dateideskriptoren, Unix-Sockets, Browsersitzungen und Hilfsdienste erben. Der riskante Prozess ist oft nicht bösartig. Er ist veraltet, falsch konfiguriert oder wurde von jemandem gestartet, der nicht wusste, was sein übergeordneter Prozess bereits gewährt hatte. Untersuche einen verdächtigen Prozess, bevor du ihn beendest. Unter macOS liefern diese Befehle nützliche Hinweise, ohne Zugangswerte offenzulegen: ```sh ps -axo pid,ppid,user,command | grep -i '[a]gent\|[c]laude\|[n]ode\|[p]ython' lsof -nP -p | grep -E 'cwd|unix|TCP|IPv4|IPv6' ``` Der erste Befehl zeigt Prozess-ID, ID des übergeordneten Prozesses, Konto und Startbefehl. Der zweite zeigt häufig das aktuelle Arbeitsverzeichnis, Unix-Socket-Pfade und offene Netzwerkverbindungen. Ein Arbeitsverzeichnis in einem alten Projekt und ein übergeordnetes Terminal aus einer früheren Sitzung erklären mehr Vorfälle als exotische Malware. Gehe nicht davon aus, dass ein Prozess beendet ist, nur weil sein Fenster verschwunden ist. Editoren lassen Language Server weiterlaufen. Terminal-Multiplexer bewahren Shells auf. Build-Tools starten Watcher. Ein lokaler MCP-Client kann die Verbindung lange aufrechterhalten, nachdem der Entwickler nicht mehr darauf achtet. Mache das Beenden des Zugriffs zu einem bewussten Schritt. Beende den Agent-Client, stoppe die Terminalsitzung, die ihn gestartet hat, und entferne jede vorübergehende Autorisierung dieser Ausführung. Muss ein Helfer weiterlaufen, dokumentiere seinen Zweck und mache seine Prozessidentität für die Person sichtbar, die den Zugriff freigibt. Ein praktischer Übergabetest erkennt Probleme früh. Entwickler A führt einen Agent mit Zugriff auf eine Staging-Aktion aus, schließt ihn und meldet sich ab. Entwickler B meldet sich mit dem eigenen Konto an und stellt eine harmlose Anfrage. B sollte weder As Arbeitsverzeichnis, Umgebungsvariablen, SSH-Socket, Browsersitzung noch aktive Autorisierung vorfinden. Wenn B etwas davon erreichen kann, gibt es gemeinsam genutzten Zustand, der entfernt werden muss. Löse dieses Problem nicht, indem du Entwickler zu Administratoren machst. Administratorrechte können für die Systemverwaltung nötig sein, vergrößern aber den Schadensradius eines unvorsichtigen Installers oder lokalen Skripts. Verwende für die tägliche Agent-Arbeit ein Standardkonto, sofern eine konkrete Aufgabe keine Erhöhung erfordert. Erhöhe die Rechte dann nur für diese Aufgabe und kehre anschließend zur normalen Nutzung zurück. ## SSH-Agents brauchen dieselbe Aufmerksamkeit wie private Schlüssel Ein SSH-Agent hält Signaturberechtigungen hinter einem lokalen Socket. Ein Prozess, der diesen Socket erreichen kann, kann deshalb Signaturen anfordern, ohne die private Schlüsseldatei zu lesen. Das ist besser, als private Schlüssel auf der Festplatte zu verteilen, aber kein Freibrief für jeden Prozess auf der Workstation. OpenSSH beschreibt `SSH_AUTH_SOCK` als Pfad zum Agent-Socket. Behandle diese Umgebungsvariable als sensible Routing-Information. Wenn ein Agent sie erbt, kann er möglicherweise Signaturen von Identitäten anfordern, die aktuell im SSH-Agent geladen sind. Der private Schlüssel bleibt verborgen, aber das operative Risiko bleibt bestehen. Führe dies aus, bevor du Automatisierung gegen ein entferntes System einsetzt: ```sh printf '%s\n' "${SSH_AUTH_SOCK:-SSH_AUTH_SOCK is unset}" ssh-add -l ssh -G deploy@staging.example.internal | grep -E '^(hostname|user|identityfile|forwardagent) ' ``` `ssh -G` gibt die wirksame OpenSSH-Clientkonfiguration aus. Die Ausgabe enthält unter anderem Zeilen wie `user deploy`, `identityfile ...` und `forwardagent no`. Prüfe die letzte Zeile sorgfältig. Agent-Weiterleitung ermöglicht einem entfernten Host, deinen lokalen Agent über die weitergeleitete Verbindung zu verwenden. Sie sollte deaktiviert bleiben, solange du nicht den genauen entfernten Hop und seinen Bedarf erklären kannst. Das OpenSSH-Handbuch zu `ssh_config` beschreibt `ForwardAgent` und warnt, dass eine Weiterleitung den lokalen Agent Benutzern mit ausreichenden Rechten auf dem entfernten Host zugänglich machen kann. Teams aktivieren sie trotzdem oft, weil dadurch keine Schlüssel kopiert werden müssen und ein Jump-Host bequem wirkt. Diese Bequemlichkeit ist real. Ebenso real ist, dass eine kompromittierte oder zu großzügig berechtigte entfernte Umgebung Signaturen anfordern kann, solange die weitergeleitete Sitzung besteht. Verwende getrennte Identitäten für getrennte Zugriffsklassen. Eine Identität für Produktions-Deployments sollte nicht neben einer persönlichen Quellcode-Identität im selben Agent liegen, nur weil beide während der Entwicklung nützlich sind. Entferne Identitäten nach der Aufgabe, wenn möglich: ```sh ssh-add -d ~/.ssh/id_staging_deploy # Oder entferne nach einer kurzen, dedizierten Sitzung alle Identitäten. ssh-add -D ``` Das Entfernen aller Identitäten kann andere legitime Arbeit unterbrechen. Verwende es daher am Ende einer dedizierten Sitzung und nicht in einem gemeinsam genutzten Shell-Tab, auf den jemand anderes angewiesen ist. Besser ist es, gemeinsam genutzte Shells vollständig zu vermeiden. Vermeide es, private Schlüsselpfade, Host-Aliase und großzügige Weiterleitungsregeln in Repository-Konfigurationen abzulegen, die jeder Entwickler blind übernimmt. Ein Repository kann den erwarteten Host und das Konto dokumentieren. Jeder Entwickler sollte selbst entscheiden, welche lokale Identität ihn erreichen darf. ## Die Freigabe muss Prozess und Aktion benennen Eine Freigabeaufforderung hilft nur, wenn ein Mensch den Aufrufer erkennen, die angeforderte Operation verstehen und die Berechtigung nach Ende der Arbeit widerrufen kann. Eine Aufforderung mit dem Text «Zugriff erlauben» bringt Menschen dazu, unverständliche Meldungen einfach zu bestätigen. Eine Freigabe pro Sitzung eignet sich für gewöhnliche Entwicklungsarbeit. Der erste Aufruf eines neu gestarteten Agent-Prozesses zeigt die Identität des Aufrufers, und der Benutzer entscheidet, ob diese Ausführung einen Aktionskanal verwenden darf. Die Autorisierung sollte enden, wenn der Prozess beendet wird, und nicht als unsichtbare Einstellung bestehen bleiben. Eine Freigabe pro Aufruf eignet sich für Aktionen mit ungleichen Folgen: das Löschen in der Produktion, die Veröffentlichung eines Pakets, das Ändern einer Zahlungseinstellung oder das Ausführen eines Befehls auf einem sensiblen Host. Diese zusätzliche Hürde ist Absicht. Wende sie nicht auf einen rein lesenden Statusaufruf an, nur um ein beruhigendes Ritual zu schaffen. Sonst bestätigen Menschen die Meldung irgendwann, ohne sie zu lesen. Die Freigabekarte sollte diese Fragen in klarer Sprache beantworten: - Welcher lokale Prozess hat den Zugriff angefordert, einschließlich seiner Signatur, sofern verfügbar? - Welche gespeicherte Zugangsinformation oder Aktionskategorie wird verwendet? - Welches Ziel, welcher Host oder welche Umgebung erhält die Anfrage? - Welche Operation findet statt und welche Eingaben verändern ihre Wirkung wesentlich? - Gilt die Freigabe für diesen Aufruf oder nur bis zum Ende dieses Prozesses? Akzeptiere kein Freigabesystem, das den Aufrufer nur als «Terminal» oder «Agent» bezeichnet. Auf einem lokalen Rechner können mehrere Terminals und Agent-Prozesse laufen. Die freigebende Person braucht genug Informationen, um eine neue Arbeitsausführung von einem alten, zufällig noch laufenden Prozess zu unterscheiden. Sallyport verwendet eine feste Entscheidungskette: Ein gesperrter Tresor verweigert jede Aktion, ein neuer Agent-Prozess benötigt standardmäßig eine Sitzungsautorisierung und für ausgewählte Zugangsdaten kann bei jeder Verwendung eine Freigabe erforderlich sein. Dieses enge Modell ist auf einem Entwickler-Laptop besser als eine umfangreiche lokale Richtliniensprache, deren undurchsichtige Regeln mit der Zeit veralten und deren Ergebnis niemand sicher vorhersagen kann. Eine Freigabe ersetzt keinen begrenzten Umfang. Ein Mensch kann das Falsche bestätigen. Begrenze Ziele, Zugangsdaten und Aktionsformen zuerst. Frage anschließend nach einer Freigabe, wenn menschliches Urteilsvermögen tatsächlich zusätzliche Kontrolle bringt. ## Ein Log muss nachträglich Fragen zur Verantwortlichkeit beantworten Ein brauchbarer Audit-Eintrag ermöglicht es einem Entwickler, nachzuvollziehen, wer was ausgeführt hat, welcher lokale Prozess Autorität erhielt, welche externe Aktion stattfand und wann jemand den Zugriff entzogen hat. Ein Terminalverlauf erfüllt diesen Standard nicht, weil Benutzer ihn bearbeiten, Shells ihn rotieren und getrennte Prozesse in einer gemeinsamen Verlaufsdatei verschwinden. Halte zwei Ansichten desselben Ereignisstroms vor. Die eine verfolgt Sitzungen: Identität des Agent-Prozesses, Start- und Endzeit, Freigaben und Widerrufe. Die andere verfolgt Aktionen: Zeitstempel, Ziel, Methode oder Befehl, Referenz auf die Zugangsdaten, Ergebnis und Fehler. Verknüpfe beide über eine Sitzungs-ID, aber halte die Informationen auch ohne Archäologie in einer Datenbank verständlich. Manipulationsnachweise verändern die Qualität der Untersuchung nach einem Vorfall. Eine nur einmal beschreibbare Sequenz mit verketteten Hashes macht stille Änderungen erkennbar. Sie beweist nicht, dass jede aufgezeichnete Aktion sinnvoll war, und sie kann fehlende Aufzeichnungen nicht wiederherstellen. Sie erschwert aber die Behauptung «Jemand hat das Log bereinigt». Prüfe den Audit-Trail unabhängig. Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem verschlüsselten, hashverketteten Audit-Log. `sp audit verify` prüft die Kette offline, ohne Zugriff auf Tresorschlüssel. Diese Trennung ist wichtig, weil der Prüfprozess nicht den Speicher für Geheimnisse benötigen sollte, dessen Nutzung gerade untersucht wird. Logs müssen ebenfalls Geheimnisse schützen. Zeichne eine Referenz auf die Zugangsinformation, den Aktionsnamen, das Ziel und das Ergebnis auf. Speichere keine Bearer-Tokens, Authorization-Header, privaten Schlüssel oder Befehlsargumente, die Passwörter enthalten. Ein vollständiges Log, das jedes Geheimnis reproduziert, ist ein zweiter Tresor mit schlechteren Zugriffskontrollen. Prüfe fehlgeschlagene Aktionen und nicht nur erfolgreiche. Wiederholte Ablehnungen können zeigen, dass ein Agent einen veralteten Aktionsvertrag verwendet, ein Entwickler das falsche Konto nutzt oder ein Hintergrundprozess seine Aufgabe überlebt hat. Eine einzelne ungeklärte erfolgreiche Aktion verdient Aufmerksamkeit. Fehler zeigen aber die Grenzen, an denen deine Kontrollen nicht zur tatsächlichen Arbeit passen. ## Ein praktikables Betriebsmodell für einen Team-Mac Teams können lokale Agents auch für ernsthafte Arbeit ausreichend sicher betreiben, wenn individuelle Identität und ausdrückliche Aktionsberechtigung wichtiger sind als die gemeinsam genutzte Hardware. Das Betriebsmodell braucht tägliche Gewohnheiten und darf nicht aus einem Sicherheitsdokument bestehen, das nur beim Onboarding auftaucht. Verwende diese Abfolge, wenn du einen Agent-Ablauf auf einem gemeinsam genutzten Bürorechner einführst: 1. Bestimme für jede Zugangsinformation Besitzer, erlaubten Dienst, Umgebung und Bedingung für die Ausmusterung. 2. Erstelle für den Agent einen eigenen Aktionsvertrag, statt ein allgemeines Token oder eine Shell-Sitzung freizulegen. 3. Starte den Agent aus dem vorgesehenen Entwicklerkonto mit einer leeren oder minimalen Zugangsdatenumgebung. 4. Gib den neuen Prozess erst frei, nachdem du seine Identität und sein angefordertes Ziel geprüft hast. 5. Beende die Ausführung, widerrufe sie bei Bedarf und bestätige, dass Hilfsprozesse und SSH-Identitäten verschwunden sind. Diese Abfolge ist bewusst weniger bequem, als ein Produktions-Token in ein beliebtes Shell-Profil zu legen. Diese Abkürzung wirkt effizient, bis ein Auftragnehmer den Rechner nutzt, ein Editor die Umgebung erbt oder ein alter Prozess über die nächste Schicht hinweg aktiv bleibt. Definiere den Notfallzugriff vor einem Ausfall. Ein Team braucht eine dokumentierte Person, die eine Notfallaktion freigeben kann, eine separate Zugangsinformation mit engem Notfallumfang und einen Log-Eintrag, der den Grund für ihre Verwendung erklärt. Lege kein dauerhaft mächtiges Token «für Notfälle» in einem gemeinsamen Ordner ab. Es wird zum normalen Zugriff, weil es vorhanden ist. Wenn eine lokale Aktionsvermittlung nötig ist, halte das Gateway im Konto des jeweiligen Entwicklers und mache die Prozessgrenze sichtbar. Ein gemeinsam genutzter Mac kann im Laufe der Zeit mehrere Benutzer beherbergen. Er sollte aber keinen undifferenzierten Pool an Autorität beherbergen. ## Widerruf testen, solange der Agent noch läuft Ein Widerruf ist nur glaubwürdig, wenn er den nächsten Aufruf eines Prozesses blockiert, der bereits eine Berechtigung hatte. Wenn du erst alle Clients beendest und dann testest, beweist das kaum etwas. Richte eine harmlose Staging-Aktion ein, die eine bekannte Antwort liefert. Starte einen Agent-Prozess, gib ihn für die Sitzung frei und führe die Aktion einmal aus. Widerrufe dann die Sitzung oder sperre den Zugangsdaten-Speicher, während der Prozess weiterläuft. Fordere dieselbe Aktion erneut an. Das erwartete Ergebnis ist eine Ablehnung, die auf den aktiven Prozess oder den gesperrten Zustand verweist. Der Agent darf nicht auf ein Token in seiner Umgebung, einen vorhandenen SSH-Socket oder eine zwischengespeicherte Browsersitzung ausweichen. Wenn die Aktion erfolgreich ist, untersuche zuerst den verwendeten Pfad, bevor du weitere Aufforderungen oder Richtlinien hinzufügst. Führe denselben Test durch, nachdem sich ein Entwickler abgemeldet und ein anderer angemeldet hat. Teste anschließend den Zustand nach dem Ruhezustand und dem Aufwachen des Rechners, weil lokale Helferverbindungen und SSH-Agents manchmal Annahmen offenlegen, die erst nach einem langen Arbeitstag sichtbar werden. Halte die Ergebnisse kurz fest, einschließlich der genauen Prozessidentität und der getesteten Aktion. Die wichtigste erste Änderung ist kein größerer Geheimnismanager und keine längere Freigabe-Checkliste. Entferne eine weitreichende Zugangsinformation aus der Reichweite eines Agents, ersetze sie durch einen engen Aktionspfad und beweise, dass der Widerruf einen noch laufenden Prozess stoppt. Dieser Test zeigt, ob das Team den Zugriff tatsächlich kontrolliert oder nur dokumentiert.