DeepSeek Harness GitHub Actions: sicher integrieren

Ein Agent verändert Dateien, aber der Workflow kann nicht unterscheiden, ob der Patch geprüft, reproduzierbar oder nur zufällig erfolgreich war.
Die schnellste sichere Lösung ist: Starten Sie DeepSeek Harness zunächst im Headless-Modus, manuell über workflow_dispatch, mit einem festen Repository, schreibgeschützter Aufgabenstellung und einem prüfbaren Artefakt; öffnen Sie Schreibrechte erst nach unabhängiger Diff- und Testprüfung.

Diese Anleitung ist für Sie geeignet, wenn Sie als Einzelentwickler Repository-Zusammenfassungen oder statische Prüfungen automatisieren möchten, als kleines Team eine kontrollierte PR-Unterstützung planen oder als Plattform- und Sicherheitsteam Runner, Secrets und parallele Ausführung voneinander trennen müssen.

Zuletzt aktualisiert am 18.08.2026; die Befehle und Sicherheitsangaben wurden anhand der offiziellen DeepSeek-Harness-Dokumentation sowie der aktuellen GitHub-Actions-Dokumentation geprüft.

DeepSeek Harness GitHub Actions: Was Sie vor dem ersten Lauf festlegen müssen

DeepSeek Harness befindet sich laut offizieller Repository-Dokumentation weiterhin in der Developer Preview. Die Maintainer weisen auf mögliche inkompatible Änderungen hin. Deshalb sollten Sie es in GitHub Actions nicht wie eine stabile, fertige CI-Action behandeln. Es gibt keine Grundlage dafür, eine bereits vorhandene offizielle „DeepSeek Harness Action“ vorauszusetzen. Stattdessen führen Sie die aktuelle CLI aus einem reproduzierbaren Arbeitsbereich heraus auf einem von Ihnen gewählten Runner aus. Die offizielle Repository-Dokumentation zu DeepSeek Harness beschreibt den Developer-Preview-Status und die verfügbaren Startvarianten.

Die wichtigsten Grenzen liegen nicht beim Aufruf selbst, sondern bei der Umgebung:

• Der Agent kann mehr als Text erzeugen. Agentische Werkzeuge können Dateioperationen, Befehlsausführung und Bearbeitung des Arbeitsbereichs ermöglichen. Ein Prompt wie „Analysieren Sie das Repository“ ist daher nicht automatisch schreibgeschützt.
• Ein Arbeitsverzeichnis kann Zustand enthalten. Caches, .env-Dateien, temporäre Dateien, Git-Referenzen oder Sitzungsdaten können einen späteren Lauf beeinflussen.
• Ein Secret ist keine vollständige Sicherheitsgrenze. Ein Prozess, der den Schlüssel verwenden darf, kann ihn bei einer kompromittierten Ausführung unter Umständen auch exfiltrieren.
• Ein erfolgreicher Agent-Lauf ist kein erfolgreicher Build. Die Agent-Ausgabe muss getrennt von Build, Tests, Linter und Code-Review bewertet werden.
• Ein selbstgehosteter Runner ist nicht automatisch sicherer. Er bietet mehr Kontrolle über Abhängigkeiten und Netzwerke, bleibt aber dauerhaft mit Ihrer Umgebung verbunden und verlangt eigene Aktualisierung, Bereinigung und Überwachung.

Für die erste Ausbaustufe sollte das akzeptierte Ergebnis deshalb nicht „Code wurde automatisch gemergt“ lauten, sondern beispielsweise:

1. eine Repository-Zusammenfassung als Markdown-Datei,
2. eine Liste erkannter Probleme mit Dateipfaden,
3. eine Kandidaten-Differenz ohne direkten Push,
4. ein klarer Exit-Status,
5. ein Artefakt mit Laufkennung, Commit und verwendeter Konfiguration.

Erste Stufe: Einzelne Repositorys manuell und schreibgeschützt prüfen

Für persönliche Repositorys ist ein manueller Start der niedrigste Risikopunkt. GitHub Actions stellt bei workflow_dispatch eine manuelle Ausführung über die Actions-Oberfläche, die CLI oder die REST-API bereit. Die offizielle Anleitung für manuell gestartete Workflows beschreibt diesen Trigger.

Beginnen Sie nicht mit push, pull_request_target oder einem automatisch ausgelösten Workflow, der beliebige Eingaben an den Agent weiterreicht. Verwenden Sie zunächst einen festen Branch, ein festes Arbeitsverzeichnis und eine Aufgabenstellung, die keine Dateiänderung verlangt.

Die aktuelle offizielle Entwicklungsdokumentation nennt für den Headless-Demolauf den Aufruf pnpm dsh --profile headless "summarize this workspace". Sie verlangt außerdem einen gesetzten DEEPSEEK_API_KEY; DEEPSEEK_BASE_URL wird als optionale Variable genannt. Da sich das Projekt in der Developer Preview befindet, sollten Sie den Befehl am Tag der Einrichtung erneut gegen die offizielle Dokumentation prüfen. Die aktuelle Headless-Entwicklungsanleitung enthält die dafür relevante Kommando- und Variablendefinition.

Ein bewusst begrenztes Workflow-Skelett kann so aussehen:

name: DeepSeek Harness Analyse

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  analyse:
    runs-on: ubuntu-latest
    env:
      DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
    steps:
      - name: Repository auschecken
        uses: actions/checkout@v6

      - name: Abhängigkeiten und Headless-Lauf
        run: |
          corepack enable
          pnpm install
          pnpm run build
          pnpm dsh --profile headless \
            "Erstelle eine schreibgeschützte Zusammenfassung dieses Arbeitsbereichs und speichere sie unter agent-output/summary.md"

      - name: Ergebnis als Artefakt speichern
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: deepseek-harness-output
          path: agent-output/

Das Beispiel ist kein Ersatz für eine offizielle DeepSeek-Harness-Action. Es zeigt nur die Verantwortungsgrenze: GitHub Actions checkt den Code aus, installiert die aktuelle Projektversion, setzt das Secret als Umgebungsvariable, startet den Headless-Modus und speichert die Ausgabe.

Die offizielle DeepSeek-Dokumentation nennt derzeit Node.js 22.19 oder höher sowie Node.js 24 als unterstützte Entwicklungsbasis, pnpm@11.7.0 im Repository und Git 2.26 oder neuer. Diese Angaben können sich mit der Preview ändern und sollten vor jeder Versionsfixierung erneut geprüft werden. Fixieren Sie die verwendeten Versionen deshalb in einer überprüften Toolchain-Datei oder in einem reproduzierbaren Setup, statt bei jedem Lauf unkontrolliert die neueste Version zu installieren.

Prüfen Sie nach dem Lauf mindestens:

• Ist der Exit-Status des Headless-Prozesses eindeutig?
• Wurde außerhalb von agent-output/ eine Datei verändert?
• Enthält das Artefakt nur die erwartete Textausgabe?
• Sind Commit-SHA, Workflow-Name und Lauf-ID dokumentiert?
• Kann dieselbe Aufgabe mit demselben Commit erneut ausgeführt werden?
• Bricht der Workflow ab, wenn DEEPSEEK_API_KEY fehlt?
• Wird der Schlüssel weder in der Befehlszeile noch in einer selbst erzeugten Debug-Datei sichtbar?

GitHub empfiehlt, Secrets über den secrets-Kontext als Eingabe oder Umgebungsvariable bereitzustellen. Bei fehlendem Secret liefert der Ausdruck einen leeren Wert; das sollten Sie durch eine explizite Vorprüfung in Ihrem Workflow behandeln. Verwenden Sie das Secret außerdem nur auf Job-Ebene und nicht global für jeden Schritt des Workflows.

Zweite Stufe: Agent-Ergebnisse außerhalb der Test- und Merge-Schranke halten

Sobald DeepSeek Harness nicht nur zusammenfasst, sondern Vorschläge oder Patches erzeugt, müssen Sie den Agent-Job von der eigentlichen Qualitätsprüfung trennen. Der Agent darf eine Kandidaten-Differenz erstellen; ein nachgelagerter Job entscheidet, ob diese Differenz überhaupt getestet werden darf.

Ein belastbarer Ablauf besteht aus vier getrennten Zuständen:

1. Analyse: Der Agent erhält eine klar begrenzte Aufgabe und erzeugt Text oder einen Patch.
2. Persistenz: Die Ausgabe wird als Artefakt gespeichert, nicht automatisch in den Zielbranch geschrieben.
3. Validierung: Ein unabhängiger Job prüft Format, Diff-Größe, erlaubte Pfade, Build und Tests.
4. Freigabe: Ein Mensch oder eine bestehende Branch-Regel entscheidet über die Übernahme.

GitHub-Actions-Artefakte können Dateien oder Verzeichnisse aus einem Lauf speichern und für spätere Jobs bereitstellen. Dazu gehören Testausgaben, Fehlerberichte, Logs und Coverage-Dateien. Die offizielle Dokumentation zum Speichern und Teilen von Artefakten beschreibt diesen Austausch zwischen Jobs.

Für automatisch erzeugte Änderungen sollten Sie zusätzlich Regeln festlegen:

• Nur bestimmte Verzeichnisse dürfen verändert werden.
• Änderungen an Workflow-Dateien, Berechtigungsdateien und Deployment-Konfigurationen werden standardmäßig abgelehnt.
• Ein leerer oder ungewöhnlich großer Diff gilt als Fehler.
• Der Agent-Job erhält nur contents: read, solange kein kontrollierter Schreibschritt notwendig ist.
• Build und Tests laufen mit einer neu ausgecheckten Arbeitskopie oder einem separat erzeugten Patch.
• Der Agent darf keinen Merge-Button, keine Branch-Regel und keinen Teststatus selbst freigeben.

Ein einfacher Prüfjob kann beispielsweise vor dem Testlauf kontrollieren, ob der erzeugte Diff nur erlaubte Pfade enthält:

set -euo pipefail

git diff --name-only > changed-files.txt

if grep -E '(^|/)(\.github/workflows|infra|deploy|secrets)(/|$)' changed-files.txt; then
  echo "Nicht erlaubter Pfad im Agent-Diff erkannt."
  exit 1
fi

Diese Prüfung ersetzt keine Sicherheitsanalyse. Sie verhindert aber, dass ein Agent-Patch unbemerkt Workflow-, Infrastruktur- oder Secret-Dateien verändert.

Vermeiden Sie privilegierte Trigger mit nicht vertrauenswürdigem Code. Besonders kritisch ist eine Kombination aus Fork-Inhalten, erhöhten Token-Rechten und einem selbstgehosteten Runner. Ein Pull Request kann manipulierte Build-Skripte, Testbefehle oder Prompt-Inhalte enthalten. Wenn der Lauf zusätzlich Zugriff auf private Netzwerkdienste oder Secrets besitzt, wird aus einer Codeprüfung ein potenzieller Zugriffspfad in Ihre Infrastruktur.

Wann brauchen Sie einen selbstgehosteten Mac-Runner?

Ein selbstgehosteter Mac-Runner ist nicht die Standardantwort auf jede DeepSeek-Harness-Aufgabe. Für kurze Repository-Zusammenfassungen oder unabhängige statische Prüfungen ist ein verwalteter Runner meist der bessere Anfang: Sie müssen den Host nicht dauerhaft warten, haben weniger Restzustand und können leichter mit einer frischen Umgebung testen.

Ein selbstgehosteter Mac-Runner wird interessant, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

• Ihre Analyse benötigt macOS-spezifische Werkzeuge oder Apple-SDKs.
• Private Paketquellen oder interne Dienste sind nur über Ihr Netzwerk erreichbar.
• Abhängigkeiten müssen dauerhaft vorinstalliert und reproduzierbar versioniert werden.
• Ein festes Arbeitsverzeichnis spart regelmäßig Installations- oder Indexierungszeit.
• Sie benötigen einen kontrollierten Host, den Sie nach internen Datenschutzvorgaben dokumentieren können.

GitHub dokumentiert macOS 11.0 oder neuer als unterstütztes Betriebssystem für selbstgehostete Runner. Unterstützt werden außerdem x64 sowie ARM64, wobei ARM64 in der aktuellen Dokumentation als Public Preview gekennzeichnet ist. Ein Runner benötigt eine laufende Runner-Anwendung, Netzwerkzugriff und ausreichende Ressourcen für die Workflows. Die offizielle Dokumentation zu selbstgehosteten Runnern beschreibt Betriebssysteme, Architekturen, Registrierung und Wartung.

Die versteckten Kosten eines dauerhaften Hosts sind jedoch beträchtlich:

• Sie müssen Node, pnpm, Git, DeepSeek Harness und alle Systemabhängigkeiten aktualisieren.
• Nach einem Agent-Lauf müssen Arbeitsbereich, temporäre Dateien und lokale Credential-Dateien bereinigt werden.
• Ein gemeinsam genutzter Host kann Daten zwischen Repositorys oder parallelen Jobs preisgeben.
• Netzwerkfreigaben für private Dienste erweitern die Angriffsfläche.
• Ein veralteter Runner kann neue GitHub-Actions-Funktionen oder Anforderungen nicht mehr zuverlässig verarbeiten.
• Bei Hardware- oder Netzwerkproblemen tragen Sie die Wiederherstellung selbst.

Die Frage lautet deshalb nicht „Mac oder kein Mac?“, sondern: Erzeugt die stabile Umgebung genug operativen Nutzen, um die zusätzliche Verantwortung zu rechtfertigen?

Dritte Stufe: Runner nach Aufgabe, Repository und Vertrauensniveau trennen

Für Plattformteams reicht eine einzelne Kennzeichnung wie self-hosted nicht aus. Verwenden Sie Runner-Gruppen und kumulative Labels, damit ein Job nur dann geeignet ist, wenn alle Bedingungen erfüllt sind. GitHub beschreibt Standardlabels wie self-hosted, macOS und ARM64 sowie eigene Labels für bestimmte Hardware- oder Softwareeigenschaften. Die offizielle Anleitung zur Auswahl eines selbstgehosteten Runners erklärt die Kombination aus Labels und Gruppen.

Eine sinnvolle Trennung kann beispielsweise so aussehen:

• agent-readonly: Repository-Analyse ohne Schreibziel
• agent-patch: Kandidaten-Patches in isolierter Umgebung
• macos-private: Zugriff auf freigegebene private Abhängigkeiten
• sensitive-repo: ausschließlich für besonders geschützte Repositorys
• single-job: nur ein Auftrag pro Host oder pro sauber zurückgesetztem Arbeitsbereich

Die Labels müssen zusammenpassen:

runs-on:
  - self-hosted
  - macOS
  - ARM64
  - agent-readonly

GitHub prüft bei eigenen Labels nicht automatisch, ob ein Host tatsächlich die behauptete Plattform oder Architektur besitzt. Ein falsch gesetztes Label ist daher keine technische Garantie. Die Eigenschaften müssen durch Ihre eigene Registrierung, Inventarisierung und regelmäßige Prüfung belegt werden.

Mehrere Repositorys können denselben Mac-Runner verwenden, aber nur unter klaren Bedingungen:

• Jeder Job erhält ein eigenes temporäres Arbeitsverzeichnis.
• Vor dem Start wird der Zustand geprüft; nach dem Ende werden Dateien, Caches und Sitzungsdaten entfernt.
• Secrets sind repositorybezogen oder auf eine kleine Organisationsgruppe begrenzt.
• Jobs mit unterschiedlichen Vertrauensstufen teilen weder Verzeichnis noch Benutzerkonto.
• Parallelität wird so begrenzt, dass kein Agent-Prozess auf eine fremde Sitzung zugreifen kann.
• Ein Fork-Pull-Request darf nicht automatisch auf denselben privilegierten Pool zugreifen.

Für besonders sensible Aufgaben sind ephemere Runner eine bessere Grenze. GitHub beschreibt, dass ein mit --ephemeral registrierter Runner nach genau einem Job automatisch aus der Registrierung entfernt wird. Die eigentliche Bereinigung des Hosts und die externe Aufbewahrung der Logs bleiben jedoch Ihre Verantwortung.

Sicherheitsprüfung für Secrets und externe Eingaben

Der DEEPSEEK_API_KEY gehört ausschließlich in GitHub Secrets. Er darf nicht im Repository, in Beispielkonfigurationen, in einer .env-Datei unter Versionskontrolle oder in einer Prompt-Datei stehen. GitHub übergibt Secrets mit Ausnahme des GITHUB_TOKEN standardmäßig nicht an Workflows, die durch einen Fork ausgelöst werden. Diese Schutzwirkung dürfen Sie nicht durch pauschale Sondertrigger umgehen. Die GitHub-Dokumentation zum sicheren Umgang mit Secrets beschreibt die vorgesehenen Übergabemethoden.

Behandeln Sie jede externe Eingabe als potenziell manipuliert:

• Issue-Titel, Pull-Request-Beschreibungen und Commit-Nachrichten können Prompt-Injection enthalten.
• Ein Agent kann Anweisungen aus README-Dateien, Kommentaren oder generierten Dateien übernehmen.
• Ein Test- oder Build-Skript kann bei unberechtigtem Checkout beliebige Befehle ausführen.
• Ein Tool-Aufruf mit Netzwerk-, Datei- oder GitHub-Schreibrechten kann die ursprüngliche Aufgabenstellung überschreiten.

Für einen sicheren ersten Workflow empfehle ich diese Begrenzung:

• Prompt aus einer versionierten, reviewten Datei laden.
• Repository-Inhalte als Daten behandeln, nicht als vertrauenswürdige Anweisungen.
• Netzwerkzugriff nur freigeben, wenn die Aufgabe ihn wirklich benötigt.
• Keine Schreibrechte für GITHUB_TOKEN, solange nur Analyse verlangt wird.
• Aktionsreferenzen, die Sie einsetzen, nach Möglichkeit auf vollständige Commit-SHAs pinnen; GitHub beschreibt das Pinnen auf unveränderliche Referenzen als robustere Variante gegenüber beweglichen Tags.
• Bei jedem benötigten Privileg zunächst einen manuellen Freigabeschritt einbauen.

Für Ihre Datenschutzdokumentation sollten Sie festhalten, welche Repository-Inhalte an die Modell-API übertragen werden, welche Logs gespeichert werden und wie lange Artefakte verfügbar bleiben. Prüfen Sie außerdem, ob vertrauliche Quelldateien, Zugangsdaten oder personenbezogene Daten vor der Analyse ausgeschlossen werden müssen. Eine passende Ergänzung für die organisatorische Prüfung finden Sie in der Datenschutzerklärung von KVMFLUX.

FAQ: Betrieb ohne interaktive Oberfläche

Kann DeepSeek Harness in GitHub Actions ohne Benutzeroberfläche laufen?

Ja. Die offizielle Entwicklungsdokumentation beschreibt einen einmaligen Headless-Aufruf über pnpm dsh --profile headless und nennt die erforderliche Umgebungsvariable DEEPSEEK_API_KEY. Das bedeutet jedoch nicht, dass jede Aufgabe gefahrlos unbeaufsichtigt ist. Unbeaufsichtigt sollte zunächst nur eine reproduzierbare, schreibgeschützte Analyse mit gespeichertem Textartefakt laufen.

Wie übergeben Sie den API-Schlüssel?

Setzen Sie das Secret nur auf Job-Ebene:

env:
  DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}

Vermeiden Sie echo, Debug-Ausgaben und Befehlszeilenargumente mit dem Schlüssel. Nach einem versehentlichen Log-Eintrag muss der Schlüssel sofort ersetzt werden. Verwenden Sie außerdem keine globale Secret-Injektion für sämtliche Jobs, wenn nur ein einzelner Agent-Schritt die API benötigt.

Was passiert mit einem erzeugten Patch?

Speichern Sie ihn zunächst als Artefakt oder als separate Kandidaten-Differenz. Ein unabhängiger Job checkt den Zielstand erneut aus, wendet den Patch kontrolliert an und führt die vorgesehenen Prüfungen aus. Erst wenn Diff, Build und Tests erfolgreich sind und die Branch-Regeln erfüllt werden, darf ein Mensch oder ein separater Freigabeschritt die Änderung übernehmen.

Entscheidungsbedingungen für die passende Ausbaustufe

Wählen Sie nicht nach dem maximal möglichen Agent-Zugriff, sondern nach dem kleinsten Zugriff, der die Aufgabe erfüllt:

• Wenn Sie nur Repository-Struktur, Abhängigkeiten oder statische Hinweise benötigen, dann verwenden Sie workflow_dispatch, einen verwalteten Runner und contents: read.
• Wenn Sie zusätzlich einen Patch benötigen, dann erzeugen Sie nur eine Kandidaten-Differenz und validieren sie in einem separaten Job.
• Wenn Sie macOS-spezifische Werkzeuge oder private Netzwerkdienste benötigen, dann wählen Sie einen isolierten selbstgehosteten Mac-Runner mit eigenem Label und begrenztem Repository-Zugriff.
• Wenn mehrere Vertrauensstufen auf einem Host zusammentreffen, dann trennen Sie Runner-Gruppen oder verwenden Sie ephemere Runner.
• Wenn ein Workflow automatisch auf Fork-Inhalte reagiert und Secrets oder Schreibrechte benötigt, dann stoppen Sie die Automatisierung und entwerfen Sie einen manuellen oder privilegierten Freigabeschritt.
• Wenn ein Task nicht reproduzierbar, nicht bereinigbar oder nicht rückrollbar ist, dann erhöhen Sie weder Parallelität noch Repository-Anzahl.

Welche Variante passt zu Ihrer CI/CD-Verantwortung?

Vor einer Erweiterung sollten Sie drei Basistasks messen: Repository-Zusammenfassung, Erklärung eines bekannten Testfehlers und kontrollierter Patch. Erfassen Sie pro Lauf mindestens Erfolg oder Misserfolg, Laufzeit, Fehlerklasse, benötigte manuelle Nacharbeit, Artefaktvollständigkeit und Zustand des Arbeitsverzeichnisses. Ohne reale Laufaufzeichnungen sollten Sie keine Kapazitätsentscheidung für zusätzliche Parallelität treffen.

Wenn Ihre bisherige Lösung auf einem dauerhaft laufenden lokalen Rechner basiert, entstehen häufig drei Nachteile: Der Host bleibt mit alten Abhängigkeiten und Sitzungsdaten belastet, die Wartung liegt vollständig bei Ihnen und die Trennung zwischen mehreren Repositorys wird schnell unübersichtlich. Ein ungeprüfter allgemeiner Cloud-Runner löst dagegen private Netzwerk- oder macOS-Abhängigkeiten nicht zuverlässig. Für einen festen, kontrollierten Mac-Unterbau kann das Mieten eines isolierten Mac-Systems von KVMFLUX deshalb die bessere operative Lösung sein, sofern Sie den Zugriff zunächst mit einem Repository und einem parallelen Task abnehmen. Die verfügbaren Mac-Use-Cases von KVMFLUX helfen Ihnen dabei, den benötigten Umgebungstyp vor dem Ausbau einzugrenzen.

Für die eigentliche Abnahme sollten Sie anschließend die Bestellung eines Mac-Systems bei KVMFLUX erst dann in Betracht ziehen, wenn Arbeitsbereich-Bereinigung, Secret-Scope, Runner-Labels, Artefaktablage und unabhängige Testgates dokumentiert sind. So kaufen Sie nicht einfach Rechenzeit, sondern eine CI-Umgebung, deren Grenzen Sie im Fehlerfall nachweisen können.

Häufige Fragen