Separate Unix-Konten für KI-Coding-Agenten sicher einrichten

Ein KI-Coding-Agent mit deinem eigenen Unix-Login zu versehen, ist eine Abkürzung mit langem Nachspiel. Der Agent übernimmt Dateien, von denen du vergessen hattest, dass es sie gibt, Zugangsdaten, die Tools vor Jahren zwischengespeichert haben, eine großzügige SSH-Konfiguration, Deployment-Skripte und die Möglichkeit, eine schlechte Änderung wie deine normale Arbeit aussehen zu lassen. Ein eigenes entferntes Konto macht einen Agenten nicht harmlos, aber seine Befugnisse werden sichtbar und lassen sich begrenzen.

Betrachte das Konto als Grenze um eine konkrete Aufgabe. Wenn der Agent ein Repository bearbeiten, dessen Tests ausführen und einen Branch pushen muss, erstelle eine Identität, die genau das kann. Beginne nicht mit deinem Entwicklerkonto, um Berechtigungen später wieder abzuziehen. Unix-Berechtigungen sammeln sich über Gruppen, eingebundene Verzeichnisse, Shell-Konfigurationen und Tools an, die davon ausgehen, dass ein Mensch das Kommando hat.

Ein separates Unix-Konto gibt dem Agenten eine andere Identität

Ein eigenes Konto bietet eine separate UID, einen eigenen Prozessbesitzer, ein eigenes Home-Verzeichnis, eigene SSH-Autorisierungen und eine eigene Audit-Spur. Diese fünf Eigenschaften sind wichtiger als ein ausgeklügelter Prompt, der den Agenten auffordert, in einem Repository zu bleiben.

Wenn ein Agent als alex läuft, gehört jeder von ihm gestartete Prozess alex. Der Prozess kann alles lesen, was alex lesen kann. Er kann den SSH-Agenten von alex verwenden, wenn Weiterleitung oder Sockets ihn zugänglich machen. Er kann Shell-Historie, Git-Zugangsdaten, Cloud-Konfiguration, Paketmanager-Caches sowie Projektverzeichnisse prüfen, die alex gehören oder für alex lesbar sind. Selbst wenn sich der Agent heute tadellos verhält, hängen seine künftigen Berechtigungen damit von jeder Bequemlichkeit ab, die du deinem eigenen Konto hinzufügst.

Ein Konto wie agentbuild macht den Ausgangspunkt überprüfbar:

id agentbuild
getent passwd agentbuild
sudo -u agentbuild sh -lc 'umask; pwd; env | sort'

Auf einem typischen Linux-Host sollte der erste Befehl eine UID und eine kurze Gruppenliste anzeigen. Der zweite sollte ein Home-Verzeichnis wie /srv/agentbuild oder /home/agentbuild zeigen, nicht das Home-Verzeichnis eines menschlichen Entwicklers. Der letzte Befehl entdeckt ein oft übersehenes Problem: Übernommene Umgebungsvariablen können auf Zugangsdaten-Dateien, Proxys, Token-Caches oder ungewöhnliche ausführbare Pfade zeigen.

Diese Unterscheidung wird oft verwischt: Ein eigener SSH-Schlüssel ist kein eigenes Konto. Ein neuer Schlüssel, der sich in deinem bestehenden Konto anmeldet, ändert nur die Authentifizierung. Dateien, Befehle oder Netzwerkkonfigurationen nach dem Login werden dadurch nicht eingeschränkt. Getrennte Authentifizierung und getrennte Autorisierung lösen unterschiedliche Probleme.

Verwende ein stabiles Konto für eine stabile Aufgabe. Wenn ein Agent Pull Requests erstellt und ein anderer Release-Artefakte deployt, gib ihnen unterschiedliche Identitäten. So kannst du eine unangenehme Betriebsfrage ohne Rätselraten beantworten: Welches Konto hat diese Datei geändert, diese Netzwerkverbindung geöffnet oder diesen Prozess erstellt?

Die Kontogrenze verhindert nicht jede Art von Schaden

Ein Unix-Konto begrenzt Zugriffe, die über Eigentümer, Gruppen, Access Control Lists und Berechtigungen gesteuert werden. Es beschränkt nicht automatisch Netzwerkziele, CPU-Nutzung, das Füllen der Festplatte, Kernel-Schwachstellen, weltweit lesbare Dateien oder Zugriffe über gemeinsame Service-Zugangsdaten.

Trotzdem lohnt sich diese Grenze. Ein Coding-Agent kann oft Quellcode ändern, Paketskripte ausführen, Konfigurationen lesen und Git verwenden. Paketskripte können beliebige Shell-Befehle ausführen. Build-Systeme können Umgebungsvariablen lesen. Eine kompromittierte Abhängigkeit kann dasselbe tun. Gehe davon aus, dass jeder Code, den der Agent den Host ausführen lässt, die Berechtigungen des Kontos erhält, unter dem er läuft.

Verwechsle Kontentrennung nicht mit einem Container, einer virtuellen Maschine oder einer Netzwerk-Firewall. Diese Mittel haben unterschiedliche Aufgaben:

• Ein Unix-Konto trennt lokale Dateien, Prozessbesitz und gewöhnliche Befehlsberechtigungen.
• Ein Container kann Dateisystemansichten und Ressourcennutzung begrenzen, aber ein falsch eingebundenes Host-Verzeichnis macht diesen Vorteil zunichte.
• Eine virtuelle Maschine bietet eine stärkere Betriebssystemgrenze, wenn die Arbeitslast das rechtfertigt.
• Netzwerkkontrollen bestimmen, wohin das Konto Verbindungen aufbauen kann und was den Host verlassen darf.

Wähle die kleinste Kombination, die zur möglichen Schadensfolge passt. Für einen kurzlebigen Test-Checkout kann ein eigenes Konto auf einem isolierten Worker genügen. Verwende auf einem Produktions-Deployment-Host die Kontogrenze zusammen mit eingeschränktem SSH, engen Deployment-Zugangsdaten, Logging und einer Egress-Regel. Wenn der Agent Produktionsdatenbanken oder Signiermaterial erreichen kann, reicht eine eigene UID offensichtlich nicht aus.

Eine verbreitete, aber falsche Empfehlung lautet, ein Konto anzulegen und es denselben operativen Gruppen wie den Entwickler hinzuzufügen, «damit die Builds funktionieren». Damit entsteht das ursprüngliche Problem unter einem anderen Benutzernamen. Gruppen wie docker, libvirt, Backup-Gruppen, Gerätegruppen und privilegierte Log-Gruppen können weit mehr Befugnisse verleihen, als ihre freundlichen Namen vermuten lassen. Auf vielen Systemen erlaubt die Mitgliedschaft in docker praktisch die Kontrolle über den Host, weil ein Mitglied einen Container mit eingebundenem Host-Dateisystem starten kann.

Ein Konto ohne geerbte Altlasten anlegen

Erstelle das entfernte Konto ohne Passwort-Login, ohne Administratorgruppe und mit einem Home-Verzeichnis, das nur absichtlich dort abgelegte Dateien enthält. Beginne leer, denn kopierte Dotfiles sind eine häufige Quelle versehentlicher Befugnisse.

Die genauen Befehle unterscheiden sich je nach Betriebssystem. Auf einem Debian- oder Ubuntu-ähnlichen Host kann ein Administrator ein lokales Konto mit eigenem Home-Verzeichnis so anlegen:

sudo adduser --disabled-password --gecos '' --home /srv/agentbuild agentbuild
sudo passwd -l agentbuild
sudo install -d -m 700 -o agentbuild -g agentbuild /srv/agentbuild/.ssh
sudo -u agentbuild touch /srv/agentbuild/.hushlogin

--disabled-password verhindert die normale Passwortauthentifizierung für das neue Konto. passwd -l macht diese Absicht auf Systemen mit Passwortsperre ausdrücklich sichtbar. Behandle keine dieser Einstellungen als einzige SSH-Kontrolle: Der SSH-Server hat eigene Einstellungen für die Passwortauthentifizierung, und ein bereits installierter Schlüssel kann weiterhin zur Anmeldung berechtigen.

Verwende auf Systemen mit useradd Optionen, die das Home-Verzeichnis und eine private Gruppe anlegen, und prüfe das Ergebnis anschließend, statt dich auf dein Gedächtnis zu verlassen. BSD und macOS verwenden andere Werkzeuge für die Kontoverwaltung. Konsultiere dort die lokale Dokumentation zu dscl, sysadminctl oder der Systemverwaltung, statt Linux-Befehle auf einen anderen Host zu übertragen.

Prüfe den Besitz sofort:

namei -l /srv/agentbuild/.ssh
sudo -u agentbuild sh -lc 'touch ~/permission-test && ls -ln ~/permission-test'
sudo rm /srv/agentbuild/permission-test

Die Ausgabe von namei geht jeden Bestandteil des Pfads durch. Kein übergeordnetes Verzeichnis sollte einer fremden Gruppe Schreibzugriff geben, denn damit könnte jemand das .ssh-Verzeichnis ersetzen oder Dateien darunter manipulieren. Die Testdatei sollte die numerische UID und die primäre GID des Kontos zeigen.

Kopiere deine .bashrc, .zshrc, .gitconfig oder dein Editor-Verzeichnis nicht «aus Zeitersparnis» in dieses Home. Solche Dateien enthalten oft private Paket-Registries, Hilfs-Aliase, SSH-Einstellungen, Zugangsdaten-Manager und Shell-Hooks. Füge einzelne Einstellungen erst hinzu, wenn du erklären kannst, warum der Agent sie braucht. Eine einfache nichtinteraktive Shell sollte für entfernte Automatisierung ohnehin der Standard sein.

Setze in der Ausführungsumgebung des Agenten eine vorsichtige Erstellungsmaske. Ein umask von 077 macht neue reguläre Dateien für das Konto privat, sofern ein Befehl nicht ausdrücklich andere Berechtigungen wählt. Dadurch wird gelegentlich eine Annahme im Build sichtbar. Das ist gut. Behebe die gemeinsame Nutzung des Builds gezielt, statt jede erzeugte Datei für alle lokalen Benutzer lesbar zu machen.

Gemeinsame Repositories brauchen eine geplante Besitzregel

Der Agent sollte in einem Checkout arbeiten, der ihm gehört, oder in einem Projektverzeichnis mit einer Gruppen- und Berechtigungsstruktur, die du erklären kannst. Ein Verzeichnis, in dem Entwickler, Deployment-Tools und Agenten als voneinander unabhängige Benutzer schreiben, wird nach der ersten hastigen Berechtigungsänderung kaum noch nachvollziehbar.

Am saubersten ist ein Checkout, der vollständig dem Agentenkonto gehört. Ein Mensch prüft Änderungen über die Versionsverwaltung oder liest Dateien über kontrollierten Gruppenzugriff. Das beseitigt die meisten lokalen Konflikte bei der Zusammenarbeit, und Git liefert den Übergabemechanismus, auf den es ankommt.

Manchmal muss der Agent in einen gemeinsamen Build-Baum schreiben. Lege dann eine eigene Projektgruppe an und setze das Gruppen-ID-Bit auf dem gemeinsamen Verzeichnis, damit neue Dateien die Gruppe erben:

sudo groupadd projectbuild
sudo usermod -aG projectbuild agentbuild
sudo install -d -m 2770 -o releasebot -g projectbuild /srv/project-build
sudo setfacl -m u:agentbuild:rwx /srv/project-build
sudo setfacl -d -m g:projectbuild:rwx /srv/project-build

Dieses Beispiel muss an dein Besitzmodell angepasst werden. Der Punkt ist nicht, dass Access Control Lists besonders modern wären. Du solltest die gemeinsame Arbeitsfläche benennen und den Schreibzugriff auf diese Fläche begrenzen. Reagiere auf einen Berechtigungsfehler nicht mit chmod -R 777 oder indem du einen ganzen Quellbaum einer gemeinsamen Administratorgruppe übergibst. Beide Lösungen verbergen das Problem, bis jemand an einer Stelle schreibt, an der er es nicht sollte.

Ein subtiler Fehler entsteht, wenn ein Build-Verzeichnis symbolische Links enthält. Der Agent kann Schreibzugriff auf /srv/project-build haben, während ein darin liegender Link auf /etc, ein Release-Verzeichnis oder ein Benutzer-Home zeigt. Prüfe Setup-Skripte und erzeugte Verzeichnisse, bevor du weitreichenden rekursiven Zugriff gewährst. Die Kontogrenze schützt nur Pfade, deren Berechtigungen das Dateisystem tatsächlich unter diesem Konto auswertet.

Git hat eine verwandte Besitzprüfung. Moderne Git-Versionen können ein Repository ablehnen, das scheinbar einem anderen Benutzer gehört, und es als «dubious ownership» melden. Löse das nicht, indem du beliebige Verzeichnisse in die globalen safe.directory-Einstellungen des Agenten aufnimmst. Der Checkout sollte dem Konto gehören, das Git ausführt. Falls ein gemeinsamer Checkout unvermeidbar ist, dokumentiere seinen Besitz und füge erst dann genau diesen Pfad hinzu, wenn du verstanden hast, warum Git ihn abgelehnt hat.

SSH sollte den Controller identifizieren und die Sitzung begrenzen

Verwende einen eigenen öffentlichen SSH-Schlüssel für den Agenten-Controller und binde Einschränkungen an diesen Schlüssel in authorized_keys, sofern es der Ablauf erlaubt. Ein eigenes Konto mit einer uneingeschränkten interaktiven Shell ist besser als ein geteiltes Entwickler-Login, bietet einem autonomen Prozess aber weiterhin eine große Befehlsfläche.

OpenSSH dokumentiert die verfügbaren Kontrollen in sshd_config(5) und authorized_keys. PasswordAuthentication no deaktiviert Passwort-Logins auf Serverebene. AllowUsers kann festlegen, wer sich anmelden darf. Optionen pro Schlüssel können Port-Weiterleitung, Agent-Weiterleitung, X11-Weiterleitung und die Zuweisung eines Pseudo-Terminals deaktivieren. Das sind normale Kontrollen und keine exotische SSH-Konfiguration.

Für einen Agenten, der nur einen Git-Befehl empfangen oder einen festen Wrapper ausführen muss, kann ein authorized_keys-Eintrag so aussehen:

restrict,command="/usr/local/libexec/agent-git-wrapper" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-controller

Die Option restrict ist eine OpenSSH-Kurzform, die mehrere Weiterleitungs- und Sitzungsfunktionen deaktiviert, abhängig von Serverversion und Handbuch. Mit command erzwingt der Server den Wrapper, statt den vom Client angeforderten Befehl zu akzeptieren. Prüfe deine installierte OpenSSH-Version, bevor du dich auf eine Option verlässt, denn ältere Hosts unterstützen möglicherweise nicht jede Einschränkung.

Der Wrapper muss seine Eingaben selbst prüfen. Ein erzwungener Befehl macht aus einem nachlässigen Skript keine Sicherheitsgrenze. Wenn er einen vom Client gelieferten Befehl ungequotet an sh -c übergibt, kann der Client oft wieder beliebige Befehle ausführen. Halte den Wrapper klein, verwende feste Pfade, lehne unerwartete Argumente ab und protokolliere die Anfrage.

Für einen allgemeinen Coding-Agenten, der eine Shell zum Prüfen, Bearbeiten, Bauen und Testen braucht, können erzwungene Befehle zu eng sein. Behalte den eigenen Schlüssel und das eigene Konto, deaktiviere nicht benötigte Weiterleitungen und begrenze, wo die Netzwerktopologie es erlaubt, die Quelladressen. Das entfernte Konto darf niemals deinen persönlichen SSH-Schlüssel akzeptieren, nur weil er bereits auf deinem Laptop liegt.

Prüfe die tatsächlich wirksame SSH-Konfiguration und nicht nur die bearbeitete Datei:

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|allowusers|allowgroups'
ssh -vvv agentbuild@build-host true

Der erste Befehl gibt die wirksamen Einstellungen des Servers aus. Der zweite zeigt auf Clientseite den Authentifizierungsweg und abgelehnte Methoden. Teste mit dem tatsächlichen Agentenschlüssel. Ein Test mit deinem eigenen Schlüssel beweist nur sehr wenig.

Sudo-Regeln machen den gerade aufgebauten Schutz oft wieder zunichte

Gewähre dem Agentenkonto kein uneingeschränktes sudo. agentbuild ALL=(ALL) NOPASSWD: ALL macht die separate UID weitgehend kosmetisch, weil jeder Befehl oder jedes Skript des Agenten zu root werden kann.

Eine solche Regel wird oft hinzugefügt, wenn ein Build eine privilegierte Aktion braucht, und bleibt bestehen, weil der Build danach endlich funktioniert. So wird aus einer engen Ausnahme dauerhafte Hostkontrolle. Wenn eine Aufgabe tatsächlich erhöhte Rechte braucht, frage zuerst, ob stattdessen ein root-eigener Dienst, ein Deployment-Worker oder eine separate Administratoraktion sie übernehmen sollte.

Das Handbuch sudoers(5) weist auf Grenzen der Befehlsprüfung hin. Argumente spielen eine Rolle. Platzhalter können mehr abdecken, als Administratoren erwarten. Ein Editor, Interpreter, Paketmanager, ein vom Agenten beschreibbares Shell-Skript oder ein Befehl, der Konfiguration aus einem beschreibbaren Verzeichnis lädt, kann direkt wieder zur beliebigen Ausführung als root führen.

Ein sichereres Muster verwendet einen root-eigenen Wrapper mit festem Verhalten. Angenommen, ein Agent muss nach dem Ablegen eines bereits geprüften Artefakts in einem festen Verzeichnis genau einen bekannten Dienst neu starten. Der Wrapper sollte absolute Befehlspfade verwenden, Argumente ablehnen, Besitz und Berechtigungen seiner Eingaben prüfen und nur diesen Neustart ausführen. Dann nennt die sudo-Regel genau diesen Wrapper:

Cmnd_Alias AGENT_RELEASE = /usr/local/sbin/restart-project-service
agentbuild ALL=(root) NOPASSWD: AGENT_RELEASE

Lege die Regel in einer mit visudo verwalteten Datei ab. Sowohl der Wrapper als auch sein übergeordnetes Verzeichnis müssen root gehören und für agentbuild nicht beschreibbar sein. Das garantiert keine Sicherheit. Es macht die enge Aussage überprüfbar: Das Konto kann ein einziges root-eigenes Programm ausführen, ohne eine vom Aufrufer kontrollierte Befehlszeichenkette.

Wenn du die erlaubte privilegierte Aktion nicht in einem Satz beschreiben kannst, erteile noch kein sudo. Teile die Arbeit auf, bis das möglich ist. Die Unbequemlichkeit ist ein Signal für das Design und kein Grund, eine weitreichende Regel einzufügen.

Zugangsdaten brauchen eine eigene Grenze gegenüber dem Login-Konto

Ein eingeschränktes Konto wird gefährlich, wenn sein Home-Verzeichnis eine Cloud-Zugangsdaten-Datei, ein weitreichendes Deployment-Token oder einen SSH-Privatschlüssel enthält, der jeden Host erreicht. Verschiebe nicht einfach deine Sammlung von Zugangsdaten aus deinem persönlichen Home in das Agenten-Home und betrachte die Aufgabe als erledigt.

Stelle Zugangsdaten für genau die Aktion, den Umfang und die Umgebung aus, die der Agent benötigt. Eine Quellcode-Zugangsdaten, die in ein Repository pushen darf, unterscheidet sich von einer Zugangsdaten für eine Produktions-Registry. Ein Deployment-Schlüssel für einen einzigen Host unterscheidet sich von einem privaten Schlüssel, der im gesamten Bestand akzeptiert wird. Halte diese Unterschiede in Kontonamen, Kommentaren und Widerrufsaufzeichnungen sichtbar.

Vermeide langlebige Geheimnisse in Shell-Umgebungsvariablen. Umgebungsvariablen können leicht über Diagnoseausgaben, Kindprozesse, Absturzberichte und je nach Betriebssystem unterschiedliche Regeln zur Prozessinspektion durchsickern. Manchmal sind sie unvermeidbar, dann brauchen sie eine kurze Lebensdauer und einen streng kontrollierten Startweg.

Sallyport bewahrt HTTP- und SSH-Zugangsdaten in seinem verschlüsselten Tresor auf und führt die angeforderte Aktion aus, ohne einem MCP-fähigen Agenten den Klartext der Zugangsdaten zu geben. Das ist hilfreich, wenn der Agent einen authentifizierten Aufruf benötigt, aber keine Token-Datei oder keinen privaten Schlüssel in seinem entfernten Konto erhalten soll.

Damit entstehen zwei unabhängige Prüfungen. Das entfernte Unix-Konto bestimmt, was der Prozess auf diesem Rechner tun kann. Das Aktions-Gateway bestimmt, ob ein Agentenprozess eine Zugangsdaten tragende HTTP- oder SSH-Aktion anfordern darf. Fasse diese Kontrollen nicht zusammen: Ein Zugangsdaten-Gateway kann ein entferntes Konto, das Produktionsdateien lesen kann, nicht reparieren, und ein eingeschränktes Konto kann einen Agenten nicht davon abhalten, ein Token zu verwenden, das ihm übergeben wurde.

Kopiere für SSH-Automatisierung deinen persönlichen privaten Schlüssel nicht nach /srv/agentbuild/.ssh. Erstelle eigene Zugangsdaten und beschränke den Server, der sie akzeptiert. Wenn das entfernte Ziel erzwungene Befehle oder Quellbeschränkungen unterstützt, nutze sie. Wenn nicht, beschränke das Konto auf diesem Ziel. Ein Widerruf sollte bedeuten, genau eine Agenten-Zugangsdaten zu entfernen, nicht den Schlüssel zu ändern, den du für normale Administration verwendest.

Logs müssen Absicht und Ausführung unterscheidbar machen

Zeichne die Agentensitzung, nach Möglichkeit die Befehle des Kontos und die von ihm vorgenommenen Änderungen auf. Logs mit der einzigen Aussage agentbuild logged in helfen nicht, wenn du später klären musst, ob ein Mensch eine Aktion angefordert, ein Agent sie vorgeschlagen oder ein entferntes Skript sie ausgeführt hat.

Unix liefert bereits nützliche Hinweise. SSH-Authentifizierungslogs nennen den akzeptierten Schlüssel und die Quelladresse. Prozessabrechnung oder Audit-Funktionen können je nach Host die Ausführung verfolgen. Die Versionsverwaltung erfasst Commits und geänderte Dateien. Build-Logs halten Befehle und Artefakte fest. Synchronisiere die Zeitstempel, damit sich diese Aufzeichnungen vergleichen lassen.

Verlasse dich nicht allein auf die Shell-Historie. Nichtinteraktive Befehle landen möglicherweise nicht dort, Benutzer können sie bearbeiten, und ein Agent kann Tools ausführen, die eigene Befehle starten. Shell-Historie ist beim Debugging praktisch, aber kein vertrauenswürdiger Nachweis.

Eine sinnvolle Prüfung stellt nach einem Lauf vier konkrete Fragen:

1. Welcher Controller hat sich als Agentenkonto authentifiziert?
2. Welche Befehle oder Build-Jobs liefen unter dieser UID?
3. Welche Dateien außerhalb des vorgesehenen Arbeitsbereichs wurden geändert?
4. Welche entfernten Systeme und authentifizierten Dienste hat der Prozess kontaktiert?

Die Antwort auf die dritte Frage entdeckt ausufernde Berechtigungen früh. Vergleiche die beschreibbaren Pfade des Kontos mit dem vorgesehenen Arbeitsbereich, bevor ein Vorfall diese Bestandsaufnahme erzwingt. Auch eine Prozessliste kann Überraschungen zeigen: Wenn ein angeblich kurzer Build-Agent Hintergrundprozesse hinterlässt, behalten diese Prozesse die Berechtigungen des Kontos, nachdem die Orchestrierungssitzung beendet ist.

Sallyport zeichnet Agentensitzungen und einzelne Aktionen in einem verschlüsselten, hashverketteten Audit-Log auf. Mit sp audit verify lässt sich die Kette offline ohne Tresorschlüssel prüfen. Dieser Nachweis ist am stärksten, wenn du zusätzlich die Belege des entfernten Hosts aufbewahrst, die zeigen, was die autorisierte SSH-Aktion nach ihrer Ankunft ausgeführt hat.

Ein gemeinsames Entwickler-Login scheitert auf vorhersehbare Weise

Das Muster beginnt meist mit einer vernünftigen Bitte: Der Agent soll dieselben Tests ausführen dürfen wie du. Der Entwickler richtet den Agenten auf einem bestehenden entfernten Host ein und autorisiert seinen normalen SSH-Schlüssel, weil Checkout, Paket-Caches und Build-Abhängigkeiten bereits funktionieren.

Der Agent führt einen Testbefehl aus. Das Test-Setup liest die Umgebung des Entwicklers und findet ein Registry-Token. Eine Abhängigkeitsinstallation führt ein Postinstall-Skript aus. Dieses Skript kann das Home-Verzeichnis des Entwicklers lesen, die SSH-Konfiguration prüfen, jeden erreichbaren Zugangsdaten-Helper verwenden und sich mit der bestehenden Netzwerkreichweite des Entwicklers verbinden. Niemand muss eine Kernel-Schwachstelle ausnutzen. Der Prozess besitzt einfach dieselben Befugnisse wie der Entwickler.

Später scheitert ein Deployment-Skript, weil es einen beschreibbaren Artefaktpfad erwartet. Jemand behebt das mit einer weitreichenden Gruppenänderung. Das Konto kann nun in ein Release-Verzeichnis schreiben. Eine zweite Korrektur fügt passwortloses sudo hinzu, weil ein Dienstneustart blockiert ist. Zu diesem Zeitpunkt hat das vermeintliche Agenten-Setup eine Entwickleridentität, weitreichenden Dateisystem-Schreibzugriff, wiederverwendbare Zugangsdaten und eine Eskalation zu root geerbt.

Ein separates Konto verändert den Verlauf dieses Fehlers. Der erste Test kann scheitern, weil das Konto keine Registry-Konfiguration lesen oder in einen alten gemeinsamen Cache schreiben darf. Dieser Fehler ist nützlich. Er zeigt, dass du eine eingeschränkte Registry-Zugangsdaten ausstellen, ein eigenes Cache-Verzeichnis anlegen oder den Build neu gestalten solltest. Jede Reparatur wird zu einer ausdrücklichen Freigabe, die du prüfen kannst.

Rechne mit anfänglicher Reibung. Wenn das neue Konto beim ersten Versuch mit einer ausgereiften Entwicklerumgebung vollkommen funktioniert, prüfe es genauer. Das kann bedeuten, dass der Host bereits zu viele Daten und Befugnisse für jeden lokalen Benutzer verfügbar macht.

Die Grenze als Agent testen und Überraschungen anschließend entfernen

Teste das Konto über eine separate Administratorsitzung, bevor du unbeaufsichtigte Arbeit zulässt. Teste nicht nur durch einen Wechsel des Shell-Prompts und die Annahme, dass sich die Identität sauber geändert hat. Authentifiziere dich mit dem eigenen Schlüssel, verwende den tatsächlichen Startbefehl und beobachte das Ergebnis von außerhalb der Sitzung.

Führe nach jeder wesentlichen Änderung der Zugriffsrechte diese kompakte Abnahmeprüfung aus:

ssh -i ./agentbuild_key agentbuild@build-host 'id; umask; pwd; find ~ -maxdepth 1 -printf "%M %u %g %p\n"'
ssh -i ./agentbuild_key agentbuild@build-host 'sudo -n true; echo sudo_status=$?'
ssh -i ./agentbuild_key agentbuild@build-host 'find /srv/project-build -xdev -type f -perm -0002 -print'

Die erste Zeile bestätigt Identität, Arbeitsverzeichnis, Erstellungsmaske und Home-Berechtigungen. Die zweite sollte normalerweise einen Status ungleich null zurückgeben, weil das Konto kein allgemeines sudo haben sollte. Die dritte sucht im gemeinsamen Projektverzeichnis nach weltweit beschreibbaren regulären Dateien. Wenn find auf deinem System kein GNU--printf unterstützt, verwende stattdessen ls -ld und stat.

Teste anschließend absichtlich verweigerte Aktionen. Versuche, das Home-Verzeichnis eines Menschen zu lesen, außerhalb des Arbeitsbereichs zu schreiben, einen persönlichen Deployment-Schlüsselpfad zu verwenden und eine SSH-Weiterleitungssitzung zu öffnen, wenn Weiterleitung deaktiviert sein sollte. Eine Einschränkung, die du nie testest, ist nur eine Absicht in einer Konfiguration.

Prüfe das Konto auch nach echten Jobs. Entferne veraltete autorisierte Schlüssel, Gruppenmitgliedschaften, Caches, temporäre ACLs und Deployment-Berechtigungen, sobald die Aufgabe sie nicht mehr benötigt. Unter Zeitdruck räumt kaum jemand Berechtigungen auf. Mache die Bereinigung zu einem Abschlusskriterium des Jobs.

Beginne damit, das Konto ohne Zugriff über das eigene Home-Verzeichnis und einen Test-Checkout hinaus anzulegen. Füge eine Fähigkeit erst hinzu, wenn ein echter Befehl scheitert und du die benötigte Berechtigung genau benennen kannst. Das wirkt beim Einrichten langsamer. Es ist deutlich schneller, als später herauszufinden, welche Teile eines Entwickler-Logins ein autonomer Prozess kopiert, verwendet oder beschädigt hat.