Trust Pack für Sicherheitsprüfungen

Diese Seite sammelt an einem Ort, was eine Sicherheits-, Datenschutz- oder KI-Governance-Prüfung von kanman üblicherweise fragt. Jeder Abschnitt verweist auf die Seite mit den Details. Braucht Ihre Prüfung etwas, das hier fehlt, schreiben Sie an [email protected].

Was kanman ist und was nicht

kanman ist ein KI-Teammitglied für Engineering-Teams. kanman übernimmt Stories aus Ihrem Tracker, arbeitet in isolierten Runs daran, lässt jede Änderung von Ihrer CI und von einem unabhängigen Reviewer gegen die Akzeptanzkriterien der Story prüfen und öffnet dafür einen Pull- oder Merge-Request. kanman spricht mit Ihrem Team in der App, in Slack und in Microsoft Teams.

kanman kann:

• Stories aus Anforderungen entwerfen und nachfragen, wenn etwas unklar ist;
• Code in den Repositories ändern, die die Richtlinie Ihres Teams erlaubt, auf einem eigenen Branch;
• Ihre Tests ausführen, Pull- oder Merge-Requests öffnen und sie mergen, wenn Ihre CI und ein unabhängiges Review bestanden sind;
• Änderungen prüfen und Fragen zu Ihrem Code und Ihrer Arbeit beantworten.

kanman kann nicht:

• Repositories, Branches oder Pfade erreichen, die Ihre Richtlinie nicht erlaubt;
• auf geschützte Branches pushen oder an den Merge- und Freigaberegeln Ihres Code-Hosts vorbei mergen;
• mehr ausgeben, als das Budget seines Teams erlaubt;
• die Werte von Secrets in seinen Logs oder Datensätzen sehen;
• ein Modell mit Ihren Daten trainieren: kanman trainiert und betreibt kein eigenes Modell.

kanman ist nicht dafür gemacht, Menschen zu bewerten. Seine Berichte beschreiben, wie ein Team liefert, nie, wie eine einzelne Person arbeitet.

Wie die Kontrolle erhalten bleibt

Wie weit kanman selbst geht, legen Menschen fest, und es steht im Audit-Log:

• Die Richtlinie legt fest, welche Repositorys und Pfade kanman ändern und wie viel es ausgeben darf. Siehe Richtlinien.
• Mergen braucht eine grüne CI und die Freigabe eines Reviewers, der die Änderung nicht geschrieben hat, durchgesetzt außerhalb des Modells. Die geschützten Branches und Freigaberegeln Ihres Code-Hosts gelten zusätzlich; ein Team, das jeden Merge von einem Menschen freigeben lassen will, stellt das am Code-Host ein. Siehe Mergen.
• Fragen gehen nur an Menschen, wenn kanman etwas nicht selbst herausfinden kann: Absicht, Entscheidungen und Zugänge. Siehe Fragen von kanman.

Datenflüsse und Regionen

Modellaufrufe gehen an den Anbieter, den der Weg Ihres Teams nennt. Mit Verarbeitung nur in der EU nutzt kanman nur EU-Wege und lehnt jeden anderen Weg ab, bevor eine Anfrage hinausgeht. Jeder Modellaufruf und jeder Run hält die Region fest, in der sein Modell lief.

Details: Hosting und Datenresidenz, Alles auf Ihren Runnern ausführen, Was Modellanbieter sehen.

Unterauftragsverarbeiter

kanman nutzt wenige Unterauftragsverarbeiter. Die aktuelle Liste mit Firmennamen, Standorten, Zwecken und Garantien ist Anlage 2 des AVV (Deutsch, Englisch).

Mit Ihrem eigenen Schlüssel (Anthropic, OpenAI, Amazon Bedrock, Azure OpenAI, Google Vertex AI auf Ihren Runnern oder das KI-Gateway Ihres Unternehmens) arbeitet der Anbieter unter Ihrem Vertrag und ist kein Unterauftragsverarbeiter von kanman. Slack und Microsoft Teams speichern die Nachrichten dort unter der Vereinbarung Ihres Unternehmens mit ihnen. Siehe AVV und Unterauftragsverarbeiter.

Protokollierung und Aufbewahrung

• Audit-Log. Jede Änderung einer Richtlinie, jede Antwort, jeder Stopp und jedes Fortsetzen und jede Aktion, die kanman für Sie ausführt, ist ein nur ergänzbarer Eintrag mit wer und wann. Owner und Admins exportieren es als CSV oder JSON. Die Aufbewahrung ist eine Workspace-Einstellung von 90 Tagen bis 5 Jahren, standardmäßig 365 Tage. Siehe Audit-Exportformat.
• Run-Datensätze. Jeder Run behält seine Phasen, Fortschrittszeilen, Kosten, Richtlinienentscheidungen sowie das genutzte Modell und seine Region.
• Datensätze der Modellaufrufe. kanman hält jeden Modellaufruf fest, den es macht: welcher Schritt aufrief, das Modell, die Region, Token-Zahlen, Dauer und Kosten. Es speichert keine Prompts und keine Antworten, nur einen Fingerabdruck der Eingabe.
• Ein Trace pro Run. Jeder Run trägt eine Trace-ID, die kanman Cloud, den Runner und den Coding-Agenten verbindet. Runner können den Trace jedes Runs an Ihren eigenen OpenTelemetry-Collector senden; siehe kanman im eigenen Monitoring sehen.
• Prüfung der Modellqualität. Einmal am Tag stellt kanman jedem Modellweg, den es selbst bezahlt, eine kleine feste Reihe bewerteter Fragen. Werden die Antworten schlechter als im üblichen Bereich des Wegs, werden kanmans Betreiber alarmiert, und kanman nutzt diesen Weg für seine eigenen Schritte nicht mehr, bis er sich erholt hat. Das geschieht nur mit kanmans eigenen Konten, nie mit Ihren.
• Löschung. Ein gelöschtes Team oder ein gelöschter Workspace wird nach 30 Tagen vollständig und automatisch gelöscht. Siehe Aufbewahrung und Löschung.

Menschliche Aufsicht

Die Sicherheitsgrundlage

Diese Regeln gelten in jedem Team und lassen sich nicht abschalten:

• Anweisungen sind keine Kontrollen. Jede Grenze, die zählt (Pfade, Branches, Produktion, Ausgaben, Netzwerk), wird außerhalb des Modells durchgesetzt: von kanmans Maschine für den Run, von den geschützten Branches Ihres Git-Hosts und von der Merge-Regel (grüne CI und ein unabhängiges Review). Eine Grenze, die nur als Anweisung an das Modell existiert, zählt nicht als Grenze.
• Nur Menschen mit Zugang können kanman Anweisungen geben. Text von Menschen ohne Schreibzugriff auf das Repository oder das Team, zum Beispiel Kommentare zu einem öffentlichen Issue oder Nachrichten in einem geteilten Kanal, wird nie zu einer Anweisung für kanman. Höchstens wird daraus ein Befund, den sich ein Mensch ansieht.
• Der Agent schlägt vor, kanmans Maschine schreibt. Der Coding-Agent hält nie ein Token Ihres Git-Hosts. Nur kanmans Maschine für den Run pusht und öffnet den Pull- oder Merge-Request, nachdem sie die Änderung auf Zugangsdaten durchsucht hat.
• Schwärzen, bevor etwas gespeichert wird. Text aus Runs, von Agenten und Modellen durchläuft eine Schwärzung, bevor kanman ihn speichert, und die genauen Secret-Werte eines Runs werden aus allem entfernt, was der Run meldet.
• Jeder Run ist isoliert. Eine neue Maschine pro Run, nur erlaubte Repositories, ein Token, das nur für diesen einen Run gilt. Siehe Sandbox und Secrets.
• Text von außen ist Daten. Issue-Texte, Review-Kommentare, CI-Logs und die Dokumentation von Abhängigkeiten erreichen ein Modell als Daten markiert und mit ihrer Herkunft, und kanmans eigene Schritte, die sie lesen, antworten nur in geprüften Feldern. Siehe Text von außerhalb Ihres Teams.
• Monitoring-Tools bleiben wie freigegeben. Ändert ein MCP-Server für das Monitoring seine Tools, nachdem kanman zum ersten Mal von ihm gelesen hat, nutzt kanman ihn nicht weiter, bis Inhaber oder Admins die neuen Tools freigeben. Siehe Monitoring-Tools bleiben wie freigegeben.

Zusätzlich zu diesen Regeln ist der Internetzugang des Coding-Agenten auf das beschränkt, was die Arbeit braucht, außer ein Team öffnet ihn: den Git-Host, die Paket-Repositories, kanman, das Modell und die Hosts, die das Team einträgt. Das wird auf der Netzwerkebene der Maschine des Runs durchgesetzt, auch auf Self-hosted Runnern, wo Produktionsnetze aus einem Run unerreichbar bleiben. Siehe Internetzugang während der Arbeit des Agenten.

Umgang mit Vorfällen und Schwachstellen

• Melden. Senden Sie Sicherheitsprobleme an [email protected], mit einer Beschreibung und den Schritten, sie nachzustellen. Bitte veröffentlichen Sie sie nicht, bevor sie behoben sind. Jede Meldung bekommt eine Antwort.
• Einordnen. kanman bewertet jede Meldung und jeden erkannten Vorfall nach Schwere und betroffenen Workspaces und beginnt zuerst mit der Eindämmung; Alle Runs stoppen und kanmans eigene Stopps für einen Modellweg oder eine Version der Run-Maschinen sind die Werkzeuge dafür.
• Benachrichtigen. Bei einer aktiv ausgenutzten Schwachstelle oder einem schweren Vorfall folgt kanman dem EU-Meldeweg mit einer Frühwarnung innerhalb von 24 Stunden und einer Meldung innerhalb von 72 Stunden und informiert betroffene Kunden. Verletzungen des Schutzes personenbezogener Daten meldet kanman Ihnen als Verantwortlichem unverzüglich, wie im AVV festgelegt.
• Schrittweise Updates der Run-Maschinen. Eine neue Version der Run-Maschinen von kanman übernimmt zuerst ein Viertel der Runs und wird daran gemessen, wie diese Runs enden, verglichen mit der Version davor. Schneidet sie schlechter ab, kehrt kanman automatisch zur vorherigen Version zurück, und die Runs auf der neuen Version laufen auf der vorherigen weiter. Wenn Sie einen Self-hosted-Runner aktualisieren, werden seine ersten Runs ebenso mit der Version davor verglichen, und kanman meldet sich bei Ihnen, wenn die neue Version schlechter abschneidet.
• Tägliche Prüfung der Modellqualität. kanman prüft die Qualität der Modellanbieter, die es selbst bezahlt, jeden Tag mit festen Aufgaben, getrennt von Ihren Runs, und seine Betreiber werden alarmiert, sobald die Antworten eines Anbieters schlechter geworden sind; sie können diesen Anbieter dann für alle Teams auf einmal stoppen.
• Software-Stückliste. Eine Stückliste (SBOM) für das Image des Self-hosted-Runners gibt es auf Anfrage.

KI-Kennzeichnung

Alles, was kanman in Ihre Repositories und Ihren Tracker schreibt, ist als KI-Arbeit gekennzeichnet: ein Trailer an jedem Commit, ein Label und eine Hinweiszeile an jedem Pull- oder Merge-Request und dieselbe Zeile an Tracker-Kommentaren. Siehe Wie kanman seine Arbeit kennzeichnet.

Ausrichtung an ISO/IEC 42001

kanman richtet seine Praxis an ISO/IEC 42001 (Managementsysteme für KI) aus. kanman ist nicht zertifiziert; die Zertifizierung ist geplant. Die Tabelle ordnet die Bereiche aus Anhang A den Stellen zu, an denen kanman sie abdeckt.

Ausrichtung am NIST AI RMF

Verwandte Seiten

• Hosting und Datenresidenz
• Verarbeitung nur in der EU
• Sandbox und Secrets
• Was Modellanbieter sehen
• Aufbewahrung und Löschung
• AVV und Unterauftragsverarbeiter