Regeln für Agenten-Setups
Lege deine eigenen Regeln für KI-Agenten-Setups fest. kanman prüft jedes Repository dagegen, hält seine eigene Arbeit an die Regeln, die du durchsetzt, und berichtet in klaren Worten.
Deine Organisation entscheidet, wie KI-Agenten eingerichtet und genutzt werden. kanman gibt dir eine Reihe von Prüfungen, mit denen du diese Entscheidungen als Konfiguration ausdrückst. Du schaltest die Prüfungen ein, die du willst, legst ihre Parameter fest und wählst für jede, ob kanman nur berichtet oder sie auch durchsetzt.
- Berichten: kanman prüft und sagt dir, was es gefunden hat. An der Arbeitsweise deines Teams ändert sich nichts.
- Durchsetzen: kanman hält zusätzlich seine eigene Arbeit an die Prüfung, dort, wo es handelt (beim Push, beim Netzwerkzugriff, beim Merge). Die Arbeit von Menschen wird nur berichtet, nie blockiert.
Voreinstellungen
Ab Werk sind nur die Prüfungen zu kanmans eigener Sicherheit an, im Modus „Berichten“: kein Zugriff von kanmans Agenten auf Produktivsysteme, Kennzeichnung von kanmans Commits, unveränderte Quality Gates, Review in einer eigenen Sitzung, keine echten Personendaten in Testdaten und Maskierung vor Modellaufrufen. Alle anderen Prüfungen stehen bereit und sind aus, bis du sie einschaltest.
Ein Team kann die Konfiguration des Workspace verschärfen, nie lockern.
So richtest du es ein
Sag kanman im Chat in deinen eigenen Worten, was du willst, oder teile die Richtlinien deiner Organisation als Text oder als Screenshot. kanman schlägt eine Konfiguration als eine Karte vor, zeigt, was sich ändern würde, und eine Lead oder ein Admin übernimmt sie mit einem Tipp. Genauso machst du es rückgängig.
Ein neutrales Beispiel: „Sperre unser Produktivnetz 10.20.0.0/16 für alle Agenten, durchgesetzt. Hänge an kanmans Commits den Trailer AI-Assisted: yes. Melde Repositories ohne Linter in der CI.“
Die Prüfungen
| Prüfung | Was kanman ansieht | Beim Durchsetzen |
|---|---|---|
| Sperrliste für Produktion | Hosts und Netze, die du einträgst. kanmans Agenten erreichen sie nicht, auch dann nicht, wenn ein Hostname in ein eingetragenes Netz auflöst. Optional tragen Repositories einen Hook, der dieselben Ziele auf Entwicklerrechnern sperrt. | Für kanmans Agenten immer gesperrt. |
| Commit-Kennzeichnung | Jeder Commit, den kanman pusht, trägt seinen KI-Trailer. Du kannst einen eigenen Trailer ergänzen. | Dein Trailer kommt an jeden Commit, den kanman pusht. |
| Quality Gates bleiben | CI-Konfiguration, Test-, Lint- und Coverage-Einstellungen, die du einträgst, werden nicht entfernt oder abgeschwächt. kanmans Review weist auch in Merge Requests von Menschen darauf hin. | kanman pusht so eine Änderung nicht und fragt stattdessen einen Menschen. |
| Getrenntes Review | Entwicklung und Review laufen in getrennten Sitzungen; kanman mergt nie auf das Review des eigenen Autors hin. | Für kanmans Arbeit immer so. |
| Keine echten Daten in Tests | Testdaten-Dateien, die du einträgst, werden auf echt wirkende Personen- oder Kundendaten geprüft. | kanman pusht solche Daten nicht. |
| Maskierung vor Modellaufrufen | Zugangsdaten, Personen- und Kundendaten werden vor jedem Modellaufruf maskiert. Siehe Maskierung. | Immer an. |
| Agenten-Konfiguration im Repository | Das Repository hat eine eingecheckte Agenten-Konfiguration an den Pfaden deiner Wahl. | kanman schlägt eine schlanke als Merge Request vor, über den dein Team entscheidet. |
| Entscheidungsdokumente | Entscheidungen haben einen Ort (Pfade deiner Wahl). kanmans Review vermerkt Architekturänderungen ohne Eintrag. | kanman bietet an, den Eintrag zu entwerfen. |
| Zustand der Repositories | Ein regelmäßiger Blick auf jedes Repository aus Code-Analyse, Dependency-Tracker und CI. | kanman benennt die Lücken und bietet an, die zu schließen, die es schließen kann. |
| Ausweich-Modell | Welche Modellanbieter eingerichtet sind und ob es eine getestete Ausweichmöglichkeit gibt. | kanman warnt bei nur einem Anbieter. |
| Verantwortliche Person | Jede Änderung, die kanman mergt, nennt eine Person: die zugewiesene, wer den Plan freigegeben hat oder wer darum gebeten hat, in der Reihenfolge deiner Wahl. | Eine Änderung ohne so eine Person wird nicht gemergt. |
| Grundausstattung der Repositories | Eine Liste deiner Wahl: Linter in der CI, SBOM-Uploads an deinen Dependency-Tracker, statische Analyse, dynamische Sicherheitstests, eine Agenten-Konfiguration. | kanman schlägt Merge Requests für Lücken vor, die es schließen kann. |
| Arbeitszeiten | Menschen hören von kanman nur in ihren Arbeitszeiten, außer bei dringenden Sicherheitsthemen. | Meldet Teams ohne Arbeitszeiten. |
| Persönliches Abwählen | Menschen können kanman sagen, welche Arbeit sie lieber selbst machen; kanman hält sie von ihnen fern. | Nur Berichten. |
| KI-Anteil im Merge Request | Merge Requests, die kanman öffnet, enden mit „AI-generated: N of M commits, ~X% of changed lines“. | Kommt an kanmans Merge Requests. |
| MCP-Freigabeliste | Die MCP-Server und Verbindungen, die du erlaubst. kanman prüft die Agenten-Konfiguration der Repositories dagegen. | kanman liest nur von Servern auf der Liste. |
Wo du die Ergebnisse siehst
- Im Chat: Nachdem kanman ein Repository geprüft hat, eine Zeile wie „billing erfüllt die KI-Regeln des Teams“, mit einem ruhigen Statuspunkt. Öffne sie für die Details.
- Im Wochenrückblick: ein Satz, nur wenn etwas offen ist oder eine Prüfung etwas zurückgehalten hat.
- Im Aktivitätsprotokoll: jede Prüfung, jeder zurückgehaltene Push und die verantwortliche Person jedes Merges, mit ihren Gründen, bereit für einen Audit-Export.
Verwandte Seiten
Zuletzt aktualisiert: January 1, 0001
kanman öffnen