kanman arbeitet in deinen Repositories, deinem Tracker und dem Chat deines Teams. Diese Seite zeigt, was diese Arbeit absichert, wohin dein Code und deine Daten gehen und wer sonst damit in Berührung kommt. Alles hier beschreibt, was heute läuft. Wenn etwas erst geplant ist, sagen wir das dazu.
Code und Daten bleiben, wo du willst
Du entscheidest, wo die Arbeit passiert. Die Regeln, die Prüfungen vor einem Merge und das Audit-Log sind in jedem Modus gleich.
| kanman Cloud | Eigene Runner | Alles auf euren Runnern | Self-hosted Edition | |
|---|---|---|---|---|
| Pläne | Alle Pläne | Enterprise | Enterprise | Enterprise |
| Checkout des Repositorys und Coding-Tool | Eine frische Maschine pro Run in Frankfurt | Dein Netz | Dein Netz | Dein Netz |
| Modellaufrufe des Coding-Tools | Der Modellzugang, den dein Team gewählt hat | Dein Runner, auf Wunsch mit deinem Modellzugang | Dein Runner, mit deinem Modellzugang | Dein Runner, mit deinem Modellzugang |
| kanmans eigene Modellaufrufe (Entwürfe, Review, Antworten) | kanmans Cloud, über die Route deines Teams | kanmans Cloud, über die Route deines Teams | Dein Runner | Dein Runner |
| Board, Entscheidungen, Audit-Log | EU (Stockholm, Schweden) | EU (Stockholm, Schweden) | EU (Stockholm, Schweden) | Deine Server |
Runner-only und self-hosted: Mit „Alles auf unseren Runnern“ ruft kanmans Cloud nie einen Modellanbieter auf und liest oder schreibt nie in deine Repositories. Pushes, Merge Requests, Reviews und Entwürfe laufen auf deinen Runnern, mit deinem Modellzugang und deinen Tokens für den Code-Host. Transkript und Tool-Ausgaben des Coding-Tools bleiben auf dem Runner; kanman bekommt nur Status, Zusammenfassungen, Dateinamen und Links. Ist kein Runner online, wartet die Arbeit. Nichts weicht auf die Cloud aus.
Die Self-hosted Edition betreibt die ganze Anwendung auf deinen Servern, mit Docker Compose oder auf Kubernetes. Modellaufrufe gehen nur über deine Runner, E-Mails über dein eigenes Mail-Relay, und eine öffentliche Registrierung gibt es nicht. Updates kommen aus kanmans Registry oder, mit Self-hosted Plus, als Offline-Paket.
Runner bauen die Verbindung selbst per HTTPS auf und melden sich mit einem Workspace-Token an. Sie brauchen keine eingehenden Ports und keine Datenbank-Zugangsdaten.
Zugangsdaten erreichen den Agenten nie
Das Coding-Tool schlägt Änderungen vor; kanmans Host schreibt sie.
- Keine Tokens in der Umgebung des Agenten. Das Coding-Tool hält nie dein Token für den Code-Host, einen Modell-Key oder den Wert eines Run-Secrets. Es erreicht Modell und Repository über einen Proxy auf dem Host des Runs, der die Zugangsdaten erst auf dem Weg nach draußen ergänzt.
- Scan nach Zugangsdaten vor jedem Push. Nur der Host pusht und öffnet den Merge Request, nachdem er den Diff nach Zugangsdaten durchsucht hat. Ein Treffer stoppt den Push.
- Kurzlebige Zugänge. Jeder Run bekommt ein Token, das nur für diesen Run gilt. Mit der kanman GitHub App gelten Repository-Tokens für ein Repository und laufen nach einer Stunde ab.
- Die Konfiguration deines Repositorys bleibt aus. Aus dem Repository lädt der Agent nur Anweisungen: keine Projekt-Hooks, Umgebungsdateien oder Tool-Server, außer dein Team erlaubt sie.
- Gespeicherte Keys sind verschlüsselt. Modell-Keys und Tokens von Verbindungen werden verschlüsselt gespeichert. API-Tokens speichern wir nur als Hash, sie werden nie wieder angezeigt.
Schwärzen, bevor etwas gespeichert wird
Text aus Runs, Coding-Tools und Modellen läuft durch einen Schwärzungsschritt, bevor kanman ihn speichert, und die exakten Secret-Werte eines Runs werden aus allem entfernt, was der Run meldet. Deine Datenschutzregeln (Begriffe und Muster pro Workspace, Team oder Verbindung) maskieren außerdem personenbezogene und Kundendaten vor jedem Modellaufruf, in kanmans Cloud und auf deinen Runnern.
Text, den niemand aus deinem Team geschrieben hat, etwa Issue-Kommentare, Beschreibungen von Merge Requests, CI-Logs oder Doku von Abhängigkeiten, erreicht ein Modell nur als markierte Daten mit Quelle. Er wird nie zu einer Anweisung an kanman. Text von Leuten ohne Schreibrechte auf Repository oder Team wird höchstens zu einem Hinweis, den sich ein Mensch ansieht.
Grenzen liegen außerhalb des Modells
Eine Grenze, die nur im Prompt steht, ist keine Grenze. Was kanman ändern, ausgeben und mergen darf, setzen kanmans Host, die geschützten Branches deines Code-Hosts und die Merge-Regel durch:
- kanman mergt nur, wenn deine CI grün ist und eine eigene Review-Session, die die Änderung nicht geschrieben hat, genau diesen Commit freigegeben hat. Die Freigaberegeln deines Code-Hosts gelten zusätzlich.
- Erlaubte Repositories, gesperrte Pfade und Größengrenzen für Änderungen werden geprüft, während das Coding-Tool arbeitet, und noch einmal am fertigen Diff.
- Der Internetzugang eines Runs ist auf das beschränkt, was die Arbeit braucht: Code-Host, Paket-Registries, kanman, das Modell und die Hosts, die dein Team freigibt. Netze, die dein Team als Produktion markiert, bleiben unerreichbar.
- Budgets pro Run, Tag und Monat stoppen die Arbeit, wenn sie aufgebraucht sind. Alle Runs stoppen hält jeden Run eines Workspace innerhalb einer Minute an, in der Cloud und auf deinen Runnern.
Zugriffsrechte und Single Sign-on
- Workspaces sind voneinander abgeschottet. Jede Tabelle in kanmans Datenbank prüft bei jeder Zeile die Mitgliedschaft im Workspace. Eine Abfrage liefert also nur Daten aus Workspaces, in denen du Mitglied bist, auch wenn ein Fehler in der App mehr verlangt.
- Rollen. Owner, Admin, Mitglied und Betrachter. Nur Owner und Admins ändern Modellzugang, Richtlinien, Mitglieder, Tokens und Runner.
- Single Sign-on (Enterprise) mit Microsoft Entra ID, Okta, Google oder jedem SAML- oder OIDC-Anbieter. Erzwingen lässt es sich erst nach einem erfolgreichen Anmeldetest. Anmeldungen stehen im Audit-Log. Verzeichnisabgleich (SCIM) kommt.
- Wer ein Mitglied entfernt, beendet dessen Zugang sofort.
Audit-Log und Export
Jede Änderung an Richtlinien, jede Antwort, jeder Stopp und jede Fortsetzung und jede Aktion, die kanman für dich ausführt, ist ein Eintrag, der nur angehängt wird, mit wer und wann. Einträge lassen sich nicht von Hand ändern oder löschen. Owner und Admins exportieren das Log als CSV oder JSON. Die Aufbewahrung ist eine Workspace-Einstellung von 90 Tagen bis 5 Jahren; mehr als ein Jahr gehört zu Enterprise. kanman protokolliert außerdem jeden eigenen Modellaufruf (Schritt, Modell, Region, Tokens, Kosten), ohne Prompts oder Antworten.
Datenstandort
- Anwendungsdaten (Konten, Storys, Runs, Entscheidungen, Audit-Log) liegen in der EU, in Stockholm, Schweden.
- Cloud-Runs laufen auf frischen Maschinen in Frankfurt, die nach dem Run verworfen werden. kanman behält keine Kopie deines Repositorys.
- Modellaufrufe gehen an den Anbieter, den die Route deines Teams nennt. Mit Nur-EU-Verarbeitung nutzt kanman ausschließlich EU-Routen, etwa Amazon Bedrock in einer EU-Region, und lehnt jede andere Route ab, bevor eine Anfrage rausgeht. Jeder Run hält fest, in welcher Region sein Modell lief.
Gelöschte Teams und Workspaces werden 30 Tage nach dem Löschen vollständig entfernt. Details: Aufbewahrung und Löschung.
Verschlüsselung
- Alle Verbindungen zu kanman nutzen TLS.
- Gespeicherte Daten verschlüsselt unser Hosting-Anbieter im Ruhezustand.
- Modell-Keys, Tokens von Verbindungen und Secret-Werte verschlüsseln wir vor dem Speichern zusätzlich; API-Tokens speichern wir nur als Hash.
Unterauftragsverarbeiter
kanman nutzt wenige Dienstleister. Die verbindliche Liste mit Datenkategorien und Garantien für Übermittlungen steht auf der Seite zu den Unterauftragsverarbeitern, Anlage 2 des AVV.
| Anbieter | Zweck | Standort |
|---|---|---|
| Supabase | Datenbank, Anmeldung, Dateiablage und Serverfunktionen | Stockholm, Schweden |
| Fly.io | Maschinen für Cloud-Runs (nicht bei eigenen Runnern) | Frankfurt am Main |
| Cloudflare | Auslieferung von Website, App und Doku, DNS, Angriffsschutz, E-Mail-Weiterleitung | Globales Netz |
| Resend | E-Mail-Versand | Irland |
| Stripe | Zahlungen und Rechnungen | Irland |
| Support-Postfach | EU und USA | |
| Anthropic | KI-Unterstützung in Betrieb und Support | USA |
| Anthropic, OpenAI | Modellaufrufe, nur wenn ein Team den Modellzugang über kanman bezahlt | USA |
Mit deinem eigenen Key, deinem KI-Gateway oder dem Modellzugang deiner Runner arbeitet der Modellanbieter unter deinem Vertrag und ist nicht unser Unterauftragsverarbeiter. Einen neuen Unterauftragsverarbeiter kündigen wir den Ownern der Workspaces mindestens 14 Tage vorher an. Wir trainieren keine Modelle mit deinen Inhalten und nutzen Modellzugänge nur zu Bedingungen, die dem Anbieter das Training damit verbieten.
Sicherheitsunterlagen
- Security-Whitepaper: Architektur, Datenflüsse und Kontrollen in einem Dokument. Mit Drucken oder als PDF speichern legst du es ab.
- Richtlinien: Zugriff, Änderungen, Vorfälle, Dienstleister und Backups.
- Auftragsverarbeitungsvertrag mit den technischen und organisatorischen Maßnahmen.
- Antworten auf gängige Sicherheitsfragebögen bekommst du auf Anfrage: schreib an [email protected].
- Die Sicherheitsseiten der Doku erklären jede Kontrolle mit den Einstellungen dahinter.
Status und Verfügbarkeit
status.kanman.ai zeigt den Live-Status jeder Komponente, ihre Verfügbarkeit der letzten 90 Tage und die Vorfälle der letzten zwei Wochen.
Sicherheitslücken melden
Du hast eine Lücke gefunden? Schreib an [email protected]. Erzähl uns, was du gefunden hast, wie wir es nachstellen können und was ein Angreifer damit anfangen könnte. Deutsch oder Englisch, beides passt.
Jede Meldung liest ein Mensch, bestätigt sie dir und hält dich auf dem Laufenden, bis der Fix draußen ist. Teste bitte nur gegen deinen eigenen Workspace, lass fremde Daten in Ruhe und gib uns eine faire Chance, das Problem zu beheben, bevor du es veröffentlichst. Ein bezahltes Bug-Bounty-Programm gibt es nicht. Unseren maschinenlesbaren Kontakt findest du unter /.well-known/security.txt.