Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Sicherheitsrichtlinie

Unterstützte Versionen

Nur die neueste Minor-Linie erhält Sicherheitspatches. Aktualisieren Sie auf die aktuelle Minor-Version, bevor Sie eine Schwachstelle gegen eine ältere Linie melden.

Eine Schwachstelle melden

Wir nehmen Sicherheit ernst. Wenn Sie eine Schwachstelle entdecken, melden Sie sie bitte verantwortungsvoll:

1. Privater Kontakt: Nutzen Sie den Kontaktkanal von AutomatosX, um einen vertraulichen Weg für Sicherheitsmeldungen anzufordern. Fügen Sie in öffentlichen Community-Nachrichten keine Exploit-Details und keine Zugangsdaten ein.
2. Discord: Melden Sie sie in unserem Discord: https://discord.gg/gf9UyPxaN2

Wir bestätigen Ihre Meldung innerhalb von 6 Geschäftstagen und halten Sie über den Fortschritt zu einer Behebung auf dem Laufenden.

Hinweis: Wir nehmen keine von KI erzeugten Sicherheitsmeldungen an. Das Einreichen einer solchen Meldung führt zu einem Ausschluss aus dem Projekt. Stellen Sie sicher, dass Ihre Meldung konkrete Schritte zur Reproduktion enthält und eine reale Auswirkung zeigt.

Bedrohungsmodell

Überblick

ax-code ist ein KI-gestützter Programmierassistent, der lokal auf Ihrem Rechner läuft. Er bietet ein Agentensystem mit Zugang zu leistungsfähigen Werkzeugen, darunter Shell-Ausführung, Dateioperationen und Webzugriff.

Die Voreinstellung der Laufzeitisolation ist full-access (Sandbox aus), mit uneingeschränkten Schreibzugriffen auf das Dateisystem und mit Netzwerkzugriff. Das ist eine Bequemlichkeitshaltung für vertrauenswürdige lokale Projekte, keine Sicherheitsgrenze. Wählen Sie workspace-write oder read-only, bevor Sie AX Code mit nicht vertrauenswürdigen Repositorys oder unbeaufsichtigten Arbeitslasten verwenden.

Sandbox zur Ausführungsisolation

ax-code enthält eine eingebaute Sandbox zur Ausführungsisolation, die einschränkt, worauf der KI-Agent zugreifen kann. Drei Modi stehen zur Verfügung:

Wichtige Eigenschaften:

• Voreingestelltes Verhalten — AX Code startet in full-access, sofern nicht --sandbox, AX_CODE_ISOLATION_MODE oder die Konfiguration einen anderen Modus setzt
• Empfohlener eingeschränkter Modus — verwenden Sie workspace-write für nicht vertrauenswürdige Repositorys oder Team-Repositorys; er begrenzt Schreibvorgänge auf den Arbeitsbereich und deaktiviert das Netzwerk standardmäßig
• Durchsetzung auf Werkzeugebene — alle ändernden Werkzeuge (bash, edit, write, apply_patch) und Netzwerkwerkzeuge (webfetch, websearch, codesearch) prüfen die Isolationsrichtlinie vor der Ausführung
• Geschützte Pfade — die Verzeichnisse .git und .ax-code sind auch im Modus Schreiben im Arbeitsbereich immer vor Schreibvorgängen geschützt
• Rückfragen zur Ausweitung — in eingeschränkten Modi zeigen Isolationsverletzungen einen Genehmigungsdialog, statt still zu scheitern; Benutzer können einen blockierten Vorgang einmal zulassen, ohne ihre Konfiguration zu ändern
• CLI-Steuerung — --sandbox read-only, --sandbox workspace-write, --sandbox full-access
• Umgebungsvariable — AX_CODE_ISOLATION_MODE

Isolations-Backends

{
  "isolation": {
    "mode": "workspace-write",
    "network": false,
    "backend": "auto"
  }
}

Oder setzen Sie AX_CODE_ISOLATION_BACKEND=os|auto|app.

Die Betriebssystemisolation für Bash verweigert Schreibvorgänge außerhalb der Wurzeln des Arbeitsbereichs und verweigert das Netzwerk, wenn network: false gilt. Prüfungen auf Anwendungsebene laufen weiterhin immer. Auf Plattformen ohne Seatbelt oder bubblewrap verwenden Sie backend: "app" oder einen Container bzw. eine VM.

Serversicherheit

• Standardmäßig nur Localhost — der Server bindet an 127.0.0.1 und ist aus dem Netzwerk nicht erreichbar
• Passwort für Netzwerkzugriff erforderlich — das Binden an 0.0.0.0 oder an eine andere Adresse als Localhost verlangt, dass AX_CODE_SERVER_PASSWORD gesetzt ist; ohne dieses verweigert der Server den Start
• Basic Auth wird erzwungen — wenn AX_CODE_SERVER_PASSWORD gesetzt ist, ist HTTP Basic Auth an allen API-Endpunkten erforderlich
• CORS ist konfigurierbar — zusätzliche erlaubte Origins können über --cors angegeben werden

Speicherung von Zugangsdaten

API-Schlüssel von Anbietern werden im Ruhezustand mit AES-256-GCM und einer PBKDF2-Schlüsselableitung verschlüsselt und im lokalen Datenverzeichnis von AX Code (~/.local/share/ax-code/) mit nur für den Benutzer geltenden Dateirechten (0600) gespeichert.

Der Verschlüsselungsschlüssel wird aus lokalen Rechnerattributen abgeleitet (Hostname, Plattform, Architektur). Das schützt vor beiläufiger Offenlegung ohne laufendes System (z. B. versehentliches Teilen einer Datei), schützt aber nicht vor einem entschlossenen Angreifer mit Zugang zum Host. Es entspricht nicht dem Schlüsselbund des Betriebssystems oder einer hardwaregestützten Speicherung von Geheimnissen.

OAuth-Tokens für MCP, Client-Geheimnisse sowie Zugriffs- und Aktualisierungstokens von Konten werden mit demselben Verfahren ebenfalls im Ruhezustand verschlüsselt. Nicht sensible Metadaten (Server-URLs, Ablaufzeitpunkte, E-Mail, Kontokennungen) bleiben im Klartext.

Prüfung von Release-Artefakten

Sowohl das Bash-Installationsprogramm (install) als auch das Windows-PowerShell-Installationsprogramm (install.ps1) prüfen heruntergeladene GitHub-Release-Archive mit Minisign vor dem Entpacken. Release-Archive und das PowerShell-Installationsskript selbst tragen abgetrennte Signaturen. Der festgelegte öffentliche Release-Schlüssel von AX Code lautet:

RWSlDu++afxCz01OqhYWhfo8+L8pVbSYXJBEb2zoWBuK0WACIzbGVZRO

Jedes Installationsprogramm lädt das passende Asset .minisig für das gewählte Archiv herunter und sperrt, wenn die Prüfung scheitert. Wenn minisign noch nicht im PATH liegt, laden die Installationsprogramme die festgelegten offiziellen Minisign-0.12-Archive von https://download.ax-code.com/vendor/minisign/0.12/ herunter, prüfen den SHA-256 des Archivs und prüfen die entpackte ausführbare Datei erneut, bevor sie sie zwischenspeichern. Eine bereits im PATH liegende Binärdatei minisign ist das Werkzeug der bedienenden Person und wird nicht erneut gehasht. Setzen Sie AX_CODE_SKIP_MINISIGN_VERIFY=1 nur, wenn Sie einen nicht prüfbaren Release-Download bewusst akzeptieren.

Der bequeme Einzeiler irm …/install.ps1 | iex prüft das Installationsskript nicht vor der Ausführung. Für sicherheitsempfindliche Installationen laden Sie install.ps1 und install.ps1.minisig herunter, prüfen das Skript mit Minisign und führen es dann lokal aus (siehe Installation und Laufzeitkanäle).

Betreuende sollten den geheimen Minisign-Schlüssel verschlüsselt aufbewahren. Für das lokale Signieren von Releases unter macOS speichern Sie die Passphrase im Keychain statt in einer Klartextdatei:

security add-generic-password -U -a ax-release -s ax-minisign -w

Die Release-Werkzeuge lesen diesen Keychain-Eintrag automatisch, wenn AX_CODE_MINISIGN_PASSWORD nicht gesetzt ist.

Der über Tags gesteuerte GitHub-Release-Workflow signiert Archive vor dem Hochladen. Er benötigt diese Repository-Geheimnisse:

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 muss der base64-kodierte Inhalt des verschlüsselten geheimen Minisign-Schlüssels ax.minisign.key sein (der lokale Pfad darf eine symbolische Verknüpfung auf ax.sec sein). Der Workflow schreibt ihn in eine temporäre Schlüsseldatei 0600, prüft den festgelegten öffentlichen Schlüssel, signiert jedes Release- Archiv und lädt die passenden Assets .minisig zusammen mit den Archiven hoch.

Für macOS-CLI-Archive verlangt und importiert der Workflow das Zertifikat Apple Developer ID über diese Repository-Geheimnisse:

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_TEAM_ID
APPLE_API_KEY_B64
APPLE_API_KEY_ID
APPLE_API_ISSUER

Auf diesem Weg werden gebündelte native Bibliotheken mit der importierten Identität Developer ID Application signiert, das macOS-ZIP wird an den Notariatsdienst von Apple übermittelt, und das unveränderte ZIP wird danach durch die abgetrennte Minisign-Signatur geschützt. ZIP- Archive lassen sich nicht mit einem Notar-Ticket versehen, daher muss die Notarisierung vor dem Hochladen der Artefakte und vor der Erzeugung von .minisig erfolgen. Release-Builds sperren im Fehlerfall, wenn Zugangsdaten für die Signierung oder Notarisierung bei Apple fehlen.

Verlauf des Release-Signaturschlüssels

Der Release-Signaturschlüssel wurde zuletzt am 2026-07-19 rotiert. Das Installationsprogramm und der Release-Workflow legen nur den aktuellen Schlüssel fest, sodass mit einem ausgemusterten Schlüssel signierte Archive die Signaturprüfung nicht bestehen. Nach einer Rotation müssen Betreuende historische Release-Archive mit script/resign-release-assets.ts neu signieren, damit jede veröffentlichte Version gegen den festgelegten Schlüssel prüfbar ist, ohne ausgemusterten Schlüsseln zu vertrauen.

So signieren Sie die Assets .minisig einer bestehenden Veröffentlichung mit dem aktuellen Schlüssel neu und laden sie erneut hoch:

tsx script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/signkey

Umfang

Im Umfang

Außerhalb des Umfangs

Sicherheitsfähigkeiten für Unternehmen

AX Code ist für den Unternehmenseinsatz ausgelegt und bietet die folgenden Härtungsmerkmale:

• Feingranulare Berechtigungen: Agentenspezifische und musterbasierte Regelsätze (allow/deny/ask). Der Sicherheitsagent ist standardmäßig nur lesend. Regeln werden über Projekt, Agent und genehmigte Listen hinweg ausgewertet.
• Prüfpfade der Sitzung: Jeder Werkzeugaufruf, jede Berechtigungsentscheidung und jede Dateiänderung wird in SQLite mit Snapshots aufgezeichnet. Unterstützt Wiedergabe, Fork und Export für Compliance-Prüfungen.
• Deterministisches Refactoring (DRE): impact_analyze, refactor_plan und refactor_apply (Schatten-Worktree plus Lint, Typprüfung und Tests) liefern prüfbare, umkehrbare Änderungen.
• Verwaltung von Zugangsdaten: Verschlüsselung mit AES-256-GCM für alle Schlüssel und Tokens. Isolation je Verzeichnis über InstanceState.
• Optionale Durchsetzung der Sandbox: Isolation auf Anwendungsebene mit Analyse von Bash-Befehlen (tree-sitter). Wählen Sie workspace-write oder read-only, um Sandbox-Grenzen durchzusetzen; geschützte Pfade (.git, .ax-code) gelten in Sandbox-Modi.
• Härtung des Servers: Standardmäßig nur Localhost; passwortgeschützter Fernzugriff mit Basic Auth.
• Codeanalyse und Prüfung: Eingebaute Erkennung von Geheimnissen und fest hinterlegten Werten sowie Analyse der Auswirkungen von Abhängigkeiten.

Programmierungsfeedback mit CodeQL

Das Repository führt CodeQL als Hintergrundschicht der Sicherheitsanalyse für Pull Requests, Pushes nach dev, geplante Prüfungen und manuelle Starts aus. CodeQL gehört nicht zum laufenden LSP- oder Codeanalysepfad; es ist eine langsamere, tiefere Nachweisquelle für Befunde zu Datenfluss, Taint und Sicherheitsqualität, die sich besser behandeln lassen, nachdem sich Quelländerungen stabilisiert haben.

Der aktuelle Workflow analysiert:

• Laufzeit, TUI, SDK, Integration und Skriptcode in JavaScript und TypeScript.
• Workflows von GitHub Actions und lokale zusammengesetzte Actions.
• Rust-Crates unter crates/ mit einem manuellen Cargo-Build, damit Native-Addon- und TUI-Code einheitlich extrahiert wird.

Die beabsichtigte Erfahrung für Entwickelnde ist:

1. Autorinnen und Autoren von Pull Requests erhalten CodeQL-Hinweise in der Codeprüfung von GitHub, neben bestehender Typprüfung, deterministischen Tests, der Abhängigkeitsprüfung mit OSV und Schutzregeln für die Repository-Struktur.
2. Betreuende sichten erste Ergebnisse, bevor CodeQL als harte Schranke für das Zusammenführen gilt, damit neue Befunde nützlich und nicht nur störend sind.
3. Künftige Prüfungs- und Debug-Abläufe von AX Code können SARIF von CodeQL oder Hinweise der Codeprüfung von GitHub als ausdrückliche Sicherheitsnachweise aufnehmen, mit Herkunftsfeldern wie source: "codeql", Regelkennung, Schweregrad, Datei, Zeile, Datenflussspur und analysiertem Commit-SHA.
4. Nachweise von CodeQL sollten neben lokalem security_scan, hardcode_scan, LSP-Diagnosen und graphgestützter Auswirkungsanalyse stehen, nicht als verborgener Ersatz für eines davon.

Wenn Sie eigene CodeQL-Abfragen hinzufügen, bevorzugen Sie repositoryspezifische Sicherheitsgrenzen gegenüber breiten Prüfungen im Stil von Lint. Wertvolle Ziele sind Ausbruchswege aus der Sandbox, Befehlsausführung mit nicht bereinigten Argumenten, Pfadüberschreitung an der Eingrenzung des Arbeitsbereichs, Weitergabe von Geheimnissen oder Umgebungsvariablen an Kindprozesse und fehlende Prüfung von Serverrouten.

Für eine vollständige Unternehmenssteuerung (RBAC, Policy-as-Code, SIEM-Export, kryptografische Prüfung) integrieren Sie AX Trust (Punkt auf der Roadmap).

Siehe docs/guides/sandbox.md zur Konfiguration der Isolation und zum Verhalten der Laufzeit.