Selbstgehosteter KI-Coding-Agent — Vollständiger Leitfaden

Ein KI-Coding-Agent ist erst dann wirklich selbstgehostet, wenn mehr als seine Desktop-Oberfläche auf Ihrer Hardware läuft. Damit Code in Ihrer Umgebung bleibt, müssen Anwendung, Modellinferenz, Embeddings, Logs, Tools und Repository sämtlich innerhalb Ihrer Grenze bleiben. Eine sichere Bereitstellung beginnt mit einem isolierten Test-Repository, einer Sandbox ohne Admin-Rechte, eingeschränktem ausgehendem Netzwerkverkehr, einem passend dimensionierten lokalen Modell und menschlicher Freigabe für jede folgenreiche Änderung.

Vier Bereitstellungszustände, die Menschen „selbstgehostet“ nennen

1. Lokale Anwendung mit einem gehosteten Modell

Die Agent-Oberfläche und die Tools laufen auf Ihrem Computer, aber ausgewählter Code und Prompts werden an einen API-Anbieter übertragen. Das ist lokale Ausführung, nicht vollständig lokale Inferenz.

2. Selbstgehostete Anwendung mit einem privaten Endpunkt

Ihr Team betreibt die Anwendung und verbindet sie mit einem Modellendpunkt in einer VPC, Private Cloud oder einem On-Premises-Gateway. Der Datenpfad kann streng kontrolliert werden, hängt aber weiterhin vom Hosting- und Logging-Design des Endpunkts ab.

3. Vollständig lokale Inferenz

Anwendung, Modellgewichte, Embeddings, Logs und Tools verbleiben auf eigener Hardware. Nur dieser Zustand rechtfertigt die Aussage „Code verlässt die Umgebung nicht“ — und auch dann erst nach Prüfung von Telemetrie, Absturzberichten, Paketmanagern, Connectors und Update-Diensten.

4. Air-Gap-Bereitstellung

Es gibt keine Netzwerkverbindung. Images, Pakete, Modelle, Schwachstellendaten und Updates gelangen über einen genehmigten Offline-Prozess hinein. Ein lokales Modell mit einer aktiven Netzwerkverbindung ist nicht air-gapped.

Referenzarchitektur

Developer
   ↓
Eigent / coding-agent harness
   ↓
Policy and approval gate
   ↓
Sandboxed repository tools ── Git, tests, linters, scanners
   ↓
Private model endpoint ── local logs and evaluation store

Das Anwendungs-Repository von Eigent steht unter Apache-2.0. Sein Source-Quickstart kann sich mit der Eigent cloud verbinden, während das Repository eigenständige Nutzer auf einen separaten Local-Deployment-Pfad verweist (Eigent-Repository). Verwenden und prüfen Sie den eigenständigen Pfad, wenn Datenisolation das Ziel ist.

Andere Harnesses passen möglicherweise besser zu anderen Workflows. OpenHands bietet einen MIT-lizenzierten Kern mit Docker-, VM-, lokalen und Cloud-Backends (OpenHands-Repository). Cline stellt einen Apache-2.0-IDE/CLI-Agenten mit Freigaben bereit (Cline-Repository). Aider bietet einen Apache-2.0-, Git-nativen Terminal-Loop (Aider-Repository).

Der Vergleich von Open-Source-KI-Coding-Agenten unterscheidet diese Harnesses nach Oberfläche, Wartungsstatus, Bereitstellungsmodell und Freigabedesign.

Einen KI-Coding-Agent-Harness auswählen

Wählen Sie nicht allein nach der Oberfläche. Prüfen Sie, wie das Tool Dateien begrenzt, Befehle ausführt, Prompts speichert, Telemetrie sendet, Secrets verwaltet und Tool-Aufrufe aufzeichnet.

Hardware nach der Arbeitslast dimensionieren, nicht nach einem Scheinminimum

Es gibt keine ehrliche universelle Regel, dass „8 GB genügen“. Die Hardware hängt vom Modellartefakt, der Quantisierung, der Kontextlänge, gleichzeitig arbeitenden Agenten, dem Repository-Index und der erforderlichen Latenz ab.

Ollama unterstützt NVIDIA-GPUs, Apple Metal und einen experimentellen Vulkan-Pfad. Sein Scheduler prüft verfügbaren VRAM, und seine Prozessansicht zeigt, ob ein Modell auf GPU, CPU oder aufgeteilt läuft (Ollama-GPU-Dokumentation, Ollama-FAQ). Für die Bereitstellung im Team ist vLLM eine produktionsorientierte Option, doch Accelerator- und Image-Support ändern sich; verwenden Sie die aktuelle vLLM-Installationsdokumentation.

Open Weights garantieren keine Bereitstellung auf einem Laptop. Die offizielle Modellkarte von Kimi K2 nennt eine Billion Parameter insgesamt und zeigt damit, dass ein herunterladbares Modell dennoch erhebliche Infrastruktur benötigen kann (Kimi-K2-Modellkarte).

Ein Sandbox-first-Bereitstellungsverfahren

1. Vor der Installation ein Threat Model erstellen

Klassifizieren Sie Source Code, Secrets, Kundendaten, Build-Artefakte und Logs. Legen Sie fest, wer eine Aufgabe starten darf, welche Aktionen der Agent ausführen darf und welches Versagen inakzeptabel wäre.

NIST SP 800-218A erweitert Leitlinien für sichere Softwareentwicklung um generative KI und richtet sich an Hersteller und Beschaffer von KI-Systemen (NIST). Nutzen Sie es als Governance-Referenz, nicht als Beleg dafür, dass ein Tool oder eine Bereitstellung „NIST-konform“ ist.

2. Eine isolierte Laufzeit erstellen

Führen Sie den Agenten unter einer dedizierten Identität ohne Admin-Rechte in einem Container oder einer VM aus. Verweigern Sie den Zugriff auf Home-Verzeichnis, SSH-Schlüssel, Cloud-Credentials, Browser-Profile, Passwortmanager und Produktions-Mounts.

OpenHands warnt ausdrücklich, dass ein nicht sandboxed lokaler Agent vollen Dateisystemzugriff besitzt (OpenHands-Repository). Dieses Risiko gilt konzeptionell für jeden Coding-Agenten mit Shell-Berechtigung.

3. Ein synthetisches Test-Repository klonen

Verwenden Sie Code ohne Kundendaten oder Secrets. Mounten Sie nur dieses Verzeichnis. Fügen Sie Canary-Dateien außerhalb des Mounts hinzu und verifizieren Sie, dass der Agent sie nicht lesen kann.

4. Den eigenständigen Anwendungspfad bereitstellen

Folgen Sie der aktuellen Eigent-Local-Deployment-Dokumentation, auf die das offizielle Repository verweist, und nicht einem Cloud-verbundenen Quickstart (Eigent-Repository). Erfassen Sie den genauen Commit, die Images, Abhängigkeiten und die verwendete Konfiguration.

5. Ein lokales Modell verbinden

Wählen Sie ein Modell, das zur gemessenen Hardware und Aufgabe passt. Bestätigen Sie Prozessplatzierung, Latenz, Kontextverarbeitung und Ausgabequalität. Behandeln Sie einen gehosteten Endpunkt als nicht lokale Qualitätsreferenz und kennzeichnen Sie ihn eindeutig.

6. Ausgehenden Netzwerkverkehr beschränken

Blockieren Sie ausgehenden Traffic und beobachten Sie dann, was fehlschlägt. Prüfen Sie DNS, Update-Prüfungen, Telemetrie, Absturzberichte, Paketmanager, Browser-Tools, MCP-Server und Modelldownloads. Dokumentieren Sie jede Ausnahme.

7. Begrenzte Tools erstellen

Beginnen Sie mit Lese-/Schreibzugriff auf das Repository und einer Allowlist von Build-, Test-, Lint- und Formatierungsbefehlen. Verweigern Sie Deployments, Änderungen von Identitäten, Cloud-Administration, beliebige Paketinstallation und externe Nachrichten.

8. Freigabeschranken hinzufügen

Fordern Sie eine Freigabe für Dateischreibvorgänge, Befehlsausführung, Abhängigkeiten, Netzwerkzugriff und jede Aktion außerhalb des Repositorys. Deterministische Richtlinien müssen verbotene Vorgänge blockieren, selbst wenn das Modell überzeugend darum bittet.

9. Eine Evaluierungsmenge ausführen

Verwenden Sie für jedes Modell und Harness dieselben Aufgaben: Bugfix, Refactoring über mehrere Dateien, Testerstellung, Abhängigkeitsupdate, Code-Erklärung und die Weigerung, Dateien außerhalb des Scopes zu ändern. Bewerten Sie Korrektheit, Test-Erfolgsquote, Review-Zeit, versuchte Grenzverletzungen, Latenz und Kosten.

10. Secrets über einen Broker einführen

Erst nachdem die synthetische Evaluierung bestanden ist, sollte der Agent eng begrenzte, kurzlebige Credentials erhalten. Halten Sie Secrets aus Prompts und Logs heraus. Bevorzugen Sie einen Broker, der eine einzelne Aktion gewährt, statt eines wiederverwendbaren Administrator-Tokens.

Sicherheitsrisiken, die für agentisches Coding einzigartig sind

Eine Sicherheitsanalyse von 2026 hebt indirekte Prompt-Injection, Confused-Deputy-Verhalten und kaskadierende Fehler in langlaufenden Agentensystemen hervor und empfiehlt Sandboxing sowie deterministische Kontrollen für Aktionen mit hohen Folgen (Research Paper). Coding-Agenten sind diesen Risiken durch Issues, README-Dateien, Kommentare, Abhängigkeitsmetadaten, Webseiten und Tool-Ausgaben ausgesetzt.

Kontrollen sollten Folgendes umfassen:

• Labels für nicht vertrauenswürdige Inhalte in Repository- und Webtexten;
• strikte Trennung zwischen dem Lesen von Anweisungen und dem Erteilen von Berechtigungen;
• Limits für Abfragen, Zeilen, Zeit und Ausgabe;
• zugelassene Paket-Registries und Abhängigkeitsprüfung;
• unveränderliche Logs von Prompts, Tool-Aufrufen, Diffs und Freigaben;
• menschliche Prüfung vor Merge, Release oder Deployment;
• Rollback über Git und reproduzierbare Umgebungen.

Self-Hosting reduziert eine externe Datengrenze. Es macht Ihr Team für Patching, Laufzeitsicherheit, Schlüsselverwaltung, Monitoring und Incident Response verantwortlich.

Die Bereitstellung auf ein Air Gap erweitern

Ein air-gapped Agent benötigt mehr als ein Kontrollkästchen für lokale Inferenz.

1. Spiegeln Sie genehmigte Container-Images, Pakete, Modellartefakte und Schwachstellendaten.
2. Verifizieren Sie Hashes und Signaturen vor dem Offline-Import.
3. Führen Sie ein Inventar und eine Software Bill of Materials.
4. Deaktivieren Sie automatische Updates, Telemetrie und Connectors, die Internetzugang voraussetzen.
5. Stellen Sie Offline-Paket- und Modell-Registries bereit.
6. Definieren Sie einen signierten Exportpfad für Patches und Reports.
7. Planen Sie Offline-Sicherheitsupdates und Verfahren für Notfallwiderrufe.
8. Testen Sie, dass die Umgebung keinen Weg über DNS, Proxies, Management-Schnittstellen oder Modell-Tooling hat.

Air Gaps erhöhen Update- und Betriebsaufwand. Sie beseitigen weder Insider-Risiken, bösartige Abhängigkeiten, unsichere importierte Dokumente noch Modellfehler.

Compliance und Nachweise

Kein selbstgehosteter Coding-Agent macht ein Team automatisch konform mit DSGVO, HIPAA, SOC 2, ISO 27001, Exportkontrollen oder vertraglicher Vertraulichkeit. Compliance hängt von Bereitstellung, Personen, Richtlinien, Verträgen und Nachweisen ab.

Dokumentieren Sie Modell- und Datensatzlizenzen, die SBOM, Zugriffsrichtlinie, Freigabematrix, Log-Aufbewahrung, Backups, Disaster Recovery, Schwachstellenreaktion und Rollback. Behandeln Sie Prompt- und Tool-Logs als potenziell sensibel, da sie Source-Fragmente und Secrets enthalten können.

Wann ein gehosteter Coding-Agent besser ist

Nutzen Sie einen gehosteten Agenten, wenn das Team keine Modellinfrastruktur betreiben kann, eine ausgereifte Remote-Umgebung benötigt, Hersteller-Support schätzt oder den erforderlichen Kontext rechtmäßig an den Anbieter senden kann. Ein gut kontrollierter gehosteter Service kann sicherer sein als eine vernachlässigte selbstgehostete Bereitstellung.

Nutzen Sie Self-Hosting, wenn Datengrenzen, Source-Inspektion, Modellwahl, Offline-Betrieb oder eine individuelle Richtlinie den Engineering- und Sicherheitsbesitz rechtfertigen.

Die Grenze des KI-Coding-Agenten betreiben, nicht nur das Modell

Eigent kann die überprüfbare Orchestrierungsschicht für einen privaten Coding-Workflow bereitstellen, aber Sandbox, Modelllaufzeit, Berechtigungen, Logs und Update-Prozess bestimmen, ob er wirklich selbstgehostet ist. Beginnen Sie mit dem Verständnis einer großen Codebasis in einem synthetischen Repository und erweitern Sie erst, wenn die Kontrollen halten. Eigent herunterladen, um die isolierte Evaluierung zu beginnen.