Sandbox und Secrets

kanman lässt einen Coding-Agenten an Ihren Repositories arbeiten. Diese Seite beschreibt die Grenzen dieser Arbeit: die Sandbox jedes Runs, die Limits Ihrer Richtlinie und den Umgang mit Secrets.

Eine Sandbox pro Run

Jeder Run startet in einer frischen, isolierten Umgebung:

• Frische Maschine. Ein Run nutzt nie den Arbeitsbereich eines anderen Runs. Nach dem Run werden Maschine und Checkout verworfen.
• Nur erlaubte Repositories. Der Run kann nur die Repositories und Branches klonen, die in der Richtlinie Ihres Teams stehen (allowed_repos).
• Git-Zugang für das Repository des Runs. Der Run klont und pusht mit dem Token Ihrer Git-Verbindung. Es wird git als Header übergeben, nie in URLs geschrieben und aus Logs entfernt.
• Kein Zugang zu kanman-Interna. Der Run spricht mit kanman nur über die kanman MCP-Tools, mit einem Token, das nur für diesen einen Run gilt und mit dem Ende des Runs ungültig wird.
• Ein schmaler Werkzeugsatz. Der Coding-Agent kann in seinem Checkout Dateien lesen, durchsuchen und bearbeiten und Befehle ausführen. Claude Code läuft ohne Websuche und Web-Abruf; Codex läuft in seiner Workspace-Sandbox.

Die Sandbox gehört zur Sicherheitsuntergrenze. Sie ist für jedes Team und jedes Preset aktiv und lässt sich nicht abschalten.

Was der Coding-Agent anfassen darf

Die Richtlinie Ihres Teams legt den Rahmen jedes Runs fest. kanman setzt sie zweimal durch: während der Agent arbeitet (Claude Code wird gestoppt, bevor es in einen gesperrten Pfad schreibt, und jeder Agent kann vorher mit check_policy nachfragen) und noch einmal am fertigen Diff jedes Versuchs.

Ein Pfad ist immer gesperrt, egal was Ihre Richtlinie sagt: .kanman/acceptance/**. Dort liegen die Akzeptanz-Specs, die belegen, dass eine Story fertig ist. Berührt ein Commit des Coding-Agenten diesen Pfad, stoppt der Diff-Wächter den Run. Siehe Das Outcome-Gate und Nachweise.

Eine Änderung außerhalb dieser Grenzen geht nicht still durch. Der Run hält an und kanman fragt im Entscheidungseingang nach, zum Beispiel “Pfad infra/alarms.tf ist durch die Richtlinie Ausgewogen nicht erlaubt” mit den Optionen Einmal erlauben und Ablehnen.

Secrets: nur Namen

kanman speichert nie Secret-Werte und gibt sie nie an den Coding-Agenten weiter.

• In der Richtlinie stehen nur die Namen der Secrets, die ein Run nutzen darf (secret_names).
• In .kanman/verify.json stehen nur die Namen der CI-Variablen (ci_var_keys), die die lokale Prüfung braucht. Die Werte bleiben in Ihrem CI-System.
• Im Nachweispaket und in Logs gibt kanman keine Secret-Werte aus.

Brauchen Ihre Tests Zugangsdaten, lassen Sie diese in den CI-Einstellungen und die Tests in der CI laufen. Das Outcome-Gate liest das CI-Ergebnis als eines seiner Signale.

Commits und Urheberschaft

kanman setzt die Commit-Urheberschaft selbst. Jeder Commit aus einem Run ist damit kanman und dem jeweiligen Run zuzuordnen. Der Coding-Agent committet als kanman <[email protected]>; Akzeptanz-Specs werden als [email protected] committet. Zusammen mit dem Diff-Wächter, der die Spec auch mit der bei Ready freigegebenen Fassung vergleicht, sieht ein Reviewer genau, welche Änderungen der Coding-Agent gemacht hat, und kann prüfen, dass die Akzeptanz-Spec nicht von der Implementierung verändert wurde.

Produktionsdaten und Sicherheitseinstellungen

Drei Arten von Entscheidungen gehen immer an einen Menschen, egal wie Ihre Richtlinie eingestellt ist:

• Zugriff auf Produktionsdaten,
• Änderungen an Sicherheitseinstellungen (zum Beispiel Berechtigungen, Authentifizierung oder Netzwerkregeln),
• Ausgaben über das Budget hinaus.

kanman hält an und fragt im Entscheidungseingang, mit einer Empfehlung und zwei bis vier Optionen. Diese Stufe lässt sich nicht auf automatisch absenken. Siehe Richtlinien, Presets und Befugnisstufen.

Self-hosted Runner

Mit einem Self-hosted Runner gelten dieselben Regeln für den Coding-Agenten, auf Ihrer Hardware. Der Runner verbindet sich ausgehend mit kanman über ein Workspace-API-Token und braucht keine eingehenden Ports. Behandeln Sie dieses Token wie jede andere Zugangsinformation: eigener Name, regelmäßig erneuern, und unter Einstellungen > API widerrufen, wenn ein Runner-Host stillgelegt wird. Runs auf einem Runner teilen sich dessen Host, nutzen Sie dafür also einen eigenen Host oder eine eigene VM. Siehe Den Self-hosted Runner betreiben.

Verwandte Seiten

• Hosting und Datenresidenz
• Richtlinien-Einstellungen
• .kanman/verify.json