Den netzisolierten Triage-Agenten einrichten

Verbinden Sie Ihr geforktes VDP-Triage-Repo über einen geführten Stepper mit Kit — Beispiel-Repo forken, den Pipeline-Trigger verdrahten und mit einem echten Roundtrip prüfen.

Warum das zählt

Code-bewusste KI-Sichtung führt bei jeder eingehenden Meldung einen KI-Sicherheitsagenten in Ihrer CI aus. Diese Seite führt Sie durch die Verbindung Ihres Forks des Beispiel-Repos mit Kit. Die Einrichtung ist ein geführter Stepper im Vanta-Stil in Ihren CSiRT-Einstellungen — er markiert einen Schritt erst als erledigt, wenn er verifiziert ist, und der letzte Schritt wird nur grün, wenn ein echter Triage-Roundtrip abgeschlossen ist.

Sie benötigen einen selbstverwalteten GitLab Runner (die geteilten SaaS-Runner von gitlab.com lassen sich nicht auf Host-Netzwerkebene isolieren, was der Airgap voraussetzt — siehe Wie der Airgap funktioniert).

Was Sie brauchen

Ein Kit-Konto mit aktiviertem VDP-Add-on und einem aktiven CSiRT-Programm
Ein GitLab-Konto, das ein Repo forken und einen selbstverwalteten Runner erstellen kann
Ein Modell-Endpunkt, den Ihr Runner über den Egress-Proxy erreicht — standardmäßig DeepSeek (https://api.deepseek.com/anthropic) oder ein beliebiger Anthropic-kompatibler Endpunkt
Der Pipeline-Trigger-Token Ihres GitLab-Projekts (den Sie in Schritt 2 erstellen)

Der Stepper

Navigieren Sie zu VDP > Einstellungen > Code-bewusste Sichtung. Das Forken des Beispiel-Repos ist eine einmalige Voraussetzung; danach hat der Stepper zwei aktive Schritte — Pipeline verbinden, dann testen — und jeder verifizierte Schritt wird fixiert, bevor der nächste öffnet.

Das Beispiel-Repo forken

Forken Sie die Referenzimplementierung:

https://gitlab.com/startupkit/vdp-ai-triage-example

Der Stepper bietet Ihnen eine Schaltfläche Auf GitLab forken, die das Repo öffnet. Forken Sie es in ein GitLab-Projekt, das Sie besitzen und kontrollieren — Sie behalten das Modell, die Prompts und die Netzwerkrichtlinie, und Kit sieht Ihren Code nie. Bevor Sie weitergehen, führen Sie die Pipeline einmal im --dry-run-Modus gegen die mitgelieferte Fixture examples/sample-report aus — sie sollte grün werden und eine vorgefertigte Sichtung erzeugen, ganz ohne Kit-Verbindung und ohne Modell-Key. Das bestätigt, dass der Vertrag funktioniert, bevor Sie irgendetwas live verdrahten.

Schritt 1 — Ihre Pipeline verbinden

Kit muss Ihre Pipeline auslösen, wenn eine Meldung eingeht. In Ihrem geforkten GitLab-Projekt:

Gehen Sie zu Settings > CI/CD > Pipeline trigger tokens und wählen Sie Add new token.
Kopieren Sie den erzeugten Trigger-Token und die Trigger-URL Ihres Projekts.

Fügen Sie beides in das Formular Ihre Pipeline verbinden des Steppers ein — die GitLab-Pipeline-Trigger-URL und den Pipeline-Trigger-Token. Das Speichern aktiviert die Verbindung. Der Trigger-Token wird verschlüsselt gespeichert und maskiert mit einem Link Token ändern angezeigt.

Kit ruft dann beim Absenden einer Meldung die GitLab-Pipeline-Trigger-API auf und übergibt dabei drei CI-Variablen pro Lauf:

POST https://gitlab.com/api/v4/projects/<project_id>/trigger/pipeline
  --form token=<trigger_token>
  --form ref=main
  --form "variables[KIT_REPORT_ID]=rpt_..."
  --form "variables[KIT_TRIAGE_TOKEN]=<scoped, short-lived>"
  --form "variables[KIT_MCP_URL]=https://..."

Note

Kit übergibt die Meldungs-ID, einen kurzlebigen, eng begrenzten Triage-Token und die MCP-Callback-URL als CI-Variablen beim Trigger-Aufruf — nicht als etwas, das Sie in Ihr Repo einfügen. CI-Variablen haben in GitLab die höchste Priorität und treffen pro Lauf ein, sodass der begrenzte Token und die Callback-URL nie in Ihrem Repo oder in den Variableneinstellungen Ihres Projekts gespeichert werden.

Wie Ihr Agent zurückruft

Hier gibt es nichts von Hand zu konfigurieren — keine Callback-URL zum Einfügen, kein Signatur-Secret. Ihr Agent liest die Meldung und postet die Sichtung über einen eng begrenzten MCP-Endpunkt für eine einzige Meldung zurück. Die agent/mcp.json des Beispiel-Repos liest die CI-Variablen KIT_MCP_URL und KIT_TRIAGE_TOKEN, die Kit beim Trigger-Aufruf eingespeist hat, sodass die Verbindung für jeden Lauf automatisch verdrahtet ist.

Der KIT_TRIAGE_TOKEN ist ein Bearer-Token, den der Agent bei seinen MCP-Aufrufen zurück an Kit sendet. Kit löst ihn zu genau einer Meldung auf — er ist die einzige Autorisierung, die der Endpunkt benötigt.

Important

Der begrenzte Token gewährt Zugriff auf eine Meldung, für eine Stunde. Er ist kein kontoweiter API-Key. Für jede Meldung wird ein neuer Token erzeugt, der nach einer Stunde abläuft. Genau das verhindert, dass ein kompromittierter CI-Job an eine andere Meldung als die eine gelangt, die er gerade sichtet.

Schritt 2 — Jetzt testen

Die Schaltfläche Testmeldung senden des Steppers löst einen echten Roundtrip mit einer Beispielmeldung aus: Kit triggert Ihre Pipeline, Ihr Agent liest die Meldung über den begrenzten MCP-Token, läuft und postet eine Sichtung zurück.

Dieser Schritt wird nur grün, wenn tatsächlich eine echte Sichtung zurück in Kit eintrifft — nicht, wenn der Trigger nur ausgelöst wird. Wenn Ihre Pipeline fehlschlägt, in ein Timeout läuft oder einen ungültigen Blob postet, zeigt der Stepper den letzten Fehler an diesem Schritt an, sodass Sie ihn nach der Behebung erneut ausführen können.

Tip

Wenn der Test in „läuft“ hängt, prüfen Sie, ob Ihr selbstverwalteter Runner online ist und Jobs annimmt, und ob Ihr Egress-Proxy die zwei erlaubten Ziele tatsächlich zulässt (Ihren Modell-Endpunkt und Kits MCP-Host). Ein Deny-all, das zu aggressiv ist, blockiert auch den MCP-Callback — siehe Wie der Airgap funktioniert.

Fertig

Sobald der Test-Roundtrip eintrifft, bestätigt der Stepper, dass Ihr Agent verdrahtet ist. Ab hier löst jede neue Meldung automatisch Ihre Pipeline aus.

Wo die Karte lebt

Nach der Verbindung erscheint auf Ihrem Integrationen-Dashboard unter Incident Response — neben Vanta und PagerDuty — eine Karte Code-bewusste Sichtung. Sie zeigt den Status verbunden / getrennt und den Zeitpunkt Ihrer letzten Sichtung und verlinkt zurück auf diesen Stepper.

Auf einen Blick

VDP-Add-on aktiviert und CSiRT-Programm aktiv
vdp-ai-triage-example forken und im --dry-run gegen die Beispielmeldung ausführen (grün, ohne Kit, ohne Key)
Einen selbstverwalteten GitLab Runner einrichten — geteilte SaaS-Runner lassen sich nicht airgappen
Einen Pipeline-Trigger-Token erstellen und die Trigger-URL + den Token in den Stepper einfügen
Jetzt testen ausführen und bestätigen, dass es bei einer echten eintreffenden Sichtung grün wird
Eine aktuelle Meldung öffnen und bestätigen, dass das Panel „Code-bewusste Sichtung“ rendert

Wie es weitergeht

Wie der Airgap funktioniert — die Egress-Grenze richtig einrichten, bevor Sie live gehen
Triage-Prompt und Modell anpassen — den Agenten auf Ihr Modell richten und den Prompt feinjustieren
Code-bewusste KI-Sichtung — was das Panel zeigt und wie die Schleife funktioniert