Skip to main content
Diese Dokumentation gilt für föderale Deployments von Devin. Zurück zur Devin-Dokumentation
Die air-gapped Versionen von CLI und Desktop speichern ihren gesamten Zustand in einigen wenigen Dateien mit dokumentierten, stabilen Formaten. Auf dieser Seite erfahren Sie, wo die einzelnen Dateien liegen, welche davon Sie selbst erstellen und wie das Schema des Audit-Protokolls genau aufgebaut ist, damit Sie es an Ihr SIEM weiterleiten können.

Dateispeicherorte

Von Ihnen erstellte Dateien

Dies sind die machine-wide Eingaben. Für jede gibt es einen Standardpfad und eine Umgebungsvariable, die diesen überschreibt. Die Variable muss in der Umgebung gesetzt sein, aus der der Agent gestartet wird (wie Sie dies für Desktop einrichten, erfahren Sie unter Umgebungsvariablen für API-Schlüssel). Die Standardwerte sind unter macOS und Linux identisch. Unter Windows liegen Lizenz, Modelldatei und Auth-Datei standardmäßig in C:\ProgramData\Devin\ (license.devin-onprem-license, models.json, auth.json), die machine-wide Richtliniendatei ist C:\ProgramData\Devin\system.json, und die Variablen zur Überschreibung sind dieselben. Sperren Sie den Ordner ab, bevor Sie Dateien darin ablegen. Die CLI liest diese Dateien nur und schreibt nie in sie. Sie können sie daher mit Ihren Tools für das Konfigurationsmanagement verwalten und schreibgeschützt ablegen.

Von der CLI geschriebener Zustand pro Nutzer

Die CLI folgt sowohl unter macOS als auch unter Linux dem Aufbau der XDG-Basisverzeichnisse (für ihren eigenen Zustand verwendet sie ~/Library nicht). XDG_CONFIG_HOME und XDG_DATA_HOME werden berücksichtigt, sofern sie gesetzt sind. cli-federal ist das Produktunterverzeichnis des air-gapped build. Es hält diesen Zustand getrennt von einer etwaigen Standardinstallation der Devin CLI auf derselben Maschine, die cli verwendet. Unter Windows liest die CLI keine XDG_*-Variablen. Sie legt dieselben Dateien unter %APPDATA%\devin\ und ihren Cache unter %LOCALAPPDATA%\devin\ ab:

Desktop-spezifischer Zustand

Die Desktop-Anwendung ist von allen anderen Devin Desktop- oder Windsurf-Installationen auf derselben Maschine isoliert: Die symbolische Verknüpfung wird beim Start von Desktop nur erstellt, wenn unter ~/.devin-airgap-config/devin/config.json noch nichts vorhanden ist. Liegt dort bereits eine reguläre Datei, lässt Desktop sie unverändert, und der mitgelieferte Agent verwendet diese Datei statt der gemeinsamen. Im Ausgabe-Channel Devin ACP wird dann die Zeile WARNING: … is a regular file, not a symlink protokolliert. Löschen Sie die Datei und starten Sie Desktop neu, um die Verknüpfung wiederherzustellen. Unter Windows gibt es keine symbolische Verknüpfung. Der mitgelieferte Agent von Desktop und die CLI nutzen %APPDATA%\devin\config.json direkt gemeinsam, und Desktop lädt die %APPDATA%\devin\mcp_config.json des Nutzers nicht. Die Desktop-Nutzerdaten befinden sich in %APPDATA%\Devin - Airgap\. Für eine vollständig saubere Neuinstallation können nur ~/.devin-airgap-config/ und ~/.devin-airgap/ gefahrlos gelöscht werden. ~/.config/devin/ und ~/.local/share/devin/ werden zusätzlich von der eigenständigen CLI genutzt.

Audit-Protokoll

Die air-gapped CLI schreibt ein lokales, strukturiertes Audit-Protokoll, das nur fortlaufend ergänzt werden kann (append-only). Es ist immer aktiv (es gibt keinen Schalter), existiert in keinem anderen Devin-Build und wird auf der Workstation gespeichert – für Ihr eigenes Review und die Datenaufnahme in Ihr SIEM.

Speicherort und Rotation

Wenn Sie eine unbegrenzte Aufbewahrung benötigen, übertragen Sie rotierte Dateien an Ihr SIEM, bevor sie gelöscht werden. Da die CLI ausschließlich Zeilen anhängt und bestehende Zeilen nie überschreibt, genügt ein Standard-Collector, der Dateien fortlaufend ausliest; siehe Audit-Protokoll an Ihr SIEM weiterleiten.

Schwärzungsgarantien

Ereignisse enthalten ausschließlich Pfade und Metadaten. Das Protokoll enthält niemals Prompts, Modellantworten, Code, Dateiinhalte, geheime Werte, API-Schlüssel oder vollständige Shell-Befehlszeilen. Bei Shell-Tools wird lediglich der Programmname (das erste token) aufgezeichnet.

Envelope (Schema-Version 1)

Jede Zeile enthält dieses Envelope; die ereignisspezifischen Felder stehen flach auf derselben Ebene daneben. Konfigurieren Sie Ihren Parser so, dass er unbekannte Felder und unbekannte event-Werte ignoriert: Neue Felder und Ereignistypen können hinzukommen, ohne dass schema_version erhöht wird.

Ereignistypen

session_start

Wird ausgegeben, wenn eine Agentensitzung beginnt (neue oder wiederaufgenommene Root-Sitzung).

session_end

Wird ausgelöst, wenn die Sitzung endet oder der Agent heruntergefahren wird.
Bei einem ordnungsgemäßen Beenden folgt auf jedes session_start genau ein session_end mit derselben session_id. Die CLI führt den Agent in einem Kindprozess aus, den sie beim Herunterfahren beendet. Daher protokolliert der übergeordnete Prozess das session_end der Kind-Sitzung (Grund other), sobald die Sitzung endet. Eine Sitzung, die durch SIGKILL oder einen Stromausfall beendet wird, kann kein abschließendes Ereignis mehr schreiben. Werten Sie ein session_start ohne zugehöriges session_end daher als abnormale Beendigung.

tool_call

Wird nach jedem vom Agent ausgeführten Tool ausgegeben.

file_read und file_write

Werden zusätzlich zu tool_call ausgegeben, und zwar einmal pro Pfad im ermittelten Berechtigungs-Geltungsbereich des Tools. Sie beschreiben den Zugriff, auf den das Tool beschränkt war, nicht tatsächlich verifizierte I/O-Vorgänge: Ein Tool, das mit Lesezugriff auf mehrere Pfade genehmigt wurde, gibt für jeden Pfad ein file_read aus, auch wenn es nur auf einige davon zugegriffen hat. Zudem werden die Ereignisse unabhängig davon ausgegeben, ob der Tool-Aufruf erfolgreich war oder nicht.

model_call

Wird nach jeder Inferenzanfrage an einen Modell-Endpunkt aus Ihrer Modelldatei ausgegeben. Token-Felder entfallen, wenn der Endpunkt keine Nutzungsdaten meldet.

auth

actor-Objekt

Die Zuordnung der Identität umfasst den OS-Nutzer, die lokale Git-Identität und (sofern SSO konfiguriert ist) die Identität aus dem validierten ID-Token. Nicht verfügbare Felder werden weggelassen. Die SSO-Felder sind in jedem auth-Ereignis enthalten, für das ein validiertes Token vorliegt (sso_login, sso_refresh, sso_logout, sso_login_denied), in sso_revalidation_failed für die vom Prozess validierte Anmeldung (bzw., falls er keine validiert hat, für die Anmeldung, die sich noch im Token-Cache befindet) sowie in session_start und identity_resolved für die Anmeldung, die der laufende Prozess beim Start validiert hat. tool_call, file_read, file_write und model_call enthalten kein actor; ordnen Sie diese Ereignisse über die session_id dem zugehörigen session_start zu.
sso_groups zeichnet die IdP-Gruppenmitgliedschaften jedes Nutzers auf dem lokalen Rechner auf. Das Audit-Verzeichnis und die zugehörigen Dateien sind nur für den Eigentümer zugänglich. Beziehen Sie sie in Ihr Review zum Datenumgang ein, wenn Gruppennamen in Ihrer Umgebung sensibel sind.

Audit-Protokoll an Ihr SIEM weiterleiten

Devin sendet Audit-Einträge nicht selbst weiter. Um die Nutzung über mehrere Workstations hinweg zu aggregieren, richten Sie den Agent zur Protokollerfassung, den Ihr SIEM bereits verwendet (zum Beispiel einen Splunk Universal Forwarder oder Elastic Agent), auf das Audit-Verzeichnis jeder Workstation aus. Eine Devin-Einstellung ist dafür nicht erforderlich. Konfigurieren Sie die Dateieingabe des Agents mit diesen Einstellungen:
Das Audit-Verzeichnis und die Dateien sind nur für den Nutzer lesbar, dem sie gehören, und Devin setzt diese Berechtigungen bei jedem Öffnen des Protokolls zurück. Führen Sie den Erfassungs-Agent als root oder als dieser Nutzer aus. Ändern Sie die Dateiberechtigungen nicht, um einem anderen Konto Zugriff zu gewähren – die Änderung wird nicht beibehalten.
Auf der Workstation jedes Nutzers werden die aktive Datei sowie höchstens 10 rotierte Dateien zu je 10 MiB aufbewahrt, insgesamt etwa 110 MiB. Ältere Einträge werden gelöscht. Eine Workstation, die zwischen zwei Erfassungen mehr Daten erzeugt, verliert daher ihre ältesten Einträge. Um zu prüfen, ob die Erfassung funktioniert, starten und beenden Sie eine Devin-Sitzung auf einer Workstation und suchen Sie anschließend in Ihrem SIEM nach einem session_start- und einem session_end-Eintrag mit derselben session_id.

Beispiel: Splunk Universal Forwarder

Stellen Sie diese beiden Dateien in einer App auf jedem Forwarder bereit (zum Beispiel unter $SPLUNK_HOME/etc/apps/devin_audit/local/). Verwenden Sie nur die monitor-Stanza, die zum Betriebssystem der Workstation passt, und ersetzen Sie devin durch den gewünschten Index.
inputs.conf
props.conf
props.conf muss auf dem Forwarder liegen, nicht nur auf den Indexern, da INDEXED_EXTRACTIONS dort angewendet wird, wo die Datei gelesen wird. Setzen Sie crcSalt nicht: Der Forwarder erkennt eine rotierte Datei dann anhand ihres Inhalts und liest sie unter ihrem neuen Namen nicht erneut ein. Jedes Verzeichnis im Wildcard-Pfad muss für das Konto lesbar sein, unter dem der Forwarder läuft; ein Forwarder, der unter einem Dienstkonto ohne Root-Rechte installiert ist, kann die Audit-Verzeichnisse nicht lesen, auf die nur der Eigentümer Lesezugriff hat. Die Felder kommen als indizierte Felder mit ihren JSON-Namen an, sodass Sie direkt nach actor.sso_user, model und input_tokens suchen können:

Beispiel: Elastic (Filebeat oder Elastic Agent)

Fügen Sie diesen filestream-Input in filebeat.yml hinzu. Behalten Sie nur den Pfad für das Betriebssystem der Workstation bei.
filebeat.yml
Der ndjson-Parser legt jeden Datensatz unter dem Präfix devin. ab (devin.event, devin.session_id, devin.actor.sso_user). Setzen Sie nicht target: "": Das Feld event des Datensatzes ist eine Zeichenfolge, was mit dem Objekt event im Elastic Common Schema kollidiert und dazu führt, dass Elasticsearch die Dokumente ablehnt. Der Prozessor timestamp kopiert ts nach @timestamp. Elastic kennzeichnet diesen Prozessor als Beta. Sie können ihn daher auch weglassen und @timestamp stattdessen in einer Ingest-Pipeline aus devin.ts setzen. Die id muss unter Ihren filestream-Inputs eindeutig sein. Standardmäßig identifiziert Filebeat Dateien über einen Fingerabdruck des Dateianfangs. Dieser bleibt auch bei der Umbenennung im Zuge der Rotation erhalten, sodass keine Rotationseinstellung erforderlich ist. Die Länge des Fingerabdrucks wird vom Standardwert 1024 Byte auf 64 Byte reduziert, da Filebeat 9.0 bis 9.4 eine Datei ignoriert, solange sie diese Länge nicht erreicht hat. Dadurch würde eine Workstation mit nur wenigen Datensätzen übersprungen. Die ersten 64 Byte einer Audit-Datei enthalten ts und pid des ersten Datensatzes, sodass die Fingerabdrücke eindeutig bleiben. Wenn Sie die Länge später ändern, liest Filebeat alle Dateien erneut ein. Wenn Sie Elastic Agent verwenden, fügen Sie der Agent-Richtlinie die Integration Custom Logs (Filestream) hinzu, geben Sie dieselben Pfade ein und tragen Sie die obigen Blöcke parsers und processors in das Feld für die benutzerdefinierte Konfiguration der Integration ein.
Cognition hat diese Beispiele nicht mit einer Splunk- oder Elastic-Bereitstellung getestet. Validieren Sie sie in Ihrer Umgebung und prüfen Sie die Herstellerdokumentation für Ihre installierte Version, bevor Sie sie auf Workstations bereitstellen.
Nützliche Felder zum Indizieren oder Durchsuchen: Nur Datensätze vom Typ session_start und auth enthalten den Nutzer. Um Datensätze vom Typ tool_call, file_read, file_write und model_call einem Nutzer zuzuordnen, verknüpfen Sie sie mit dem session_start-Datensatz, der dieselbe session_id hat.

Diagnosebericht

devin diagnostics erstellt einen bereinigten Klartextbericht, den Sie prüfen können, bevor Sie ihn an den Cognition-Support senden. Er enthält ausschließlich Versionen, die Struktur der Konfiguration (ob die einzelnen Dateien vorhanden sind und sich parsen lassen), Modellnamen, ob die einzelnen API-Schlüssel-Variablen gesetzt sind, sowie Statistiken zum Audit-Protokoll. Prompts, Code, Dateiinhalte, geheime Werte, Endpunkt-URLs oder Werte von Umgebungsvariablen enthält er dagegen niemals.
Verwenden Sie --output <path>, um den Dateinamen festzulegen. Der Bericht wird mit Leserechten nur für den Eigentümer (0600) gespeichert. Unter Fehlerbehebung erfahren Sie, welche Angaben eine Support-Anfrage enthalten sollte.