Cette documentation concerne les déploiements fédéraux de Devin. Retour à la documentation de Devin
Emplacement des fichiers
Fichiers que vous créez
Il s’agit des entrées appliquées à l’échelle de la machine. Chacune possède un chemin par défaut, qu’une variable d’environnement permet de remplacer ; cette variable doit être définie dans l’environnement à partir duquel l’agent démarre (voir Variables d’environnement des clés d’API pour savoir comment procéder avec Desktop).
Les valeurs par défaut sont identiques sous macOS et Linux. Sous Windows, la licence, le fichier des modèles et le fichier d’authentification se trouvent par défaut dans
C:\ProgramData\Devin\ (license.devin-onprem-license, models.json, auth.json), le fichier de politique à l’échelle de la machine est C:\ProgramData\Devin\system.json, et les variables de dérogation restent les mêmes ; verrouillez le dossier avant d’y placer des fichiers. La CLI lit ces fichiers sans jamais y écrire : vous pouvez donc les gérer avec vos outils de gestion de configuration et les passer en lecture seule.
État par utilisateur écrit par la CLI
La CLI suit la structure de répertoires de base XDG sous macOS comme sous Linux (elle n’utilise pas~/Library pour son propre état). Les variables XDG_CONFIG_HOME et XDG_DATA_HOME sont prises en compte lorsqu’elles sont définies.
cli-federal est le sous-répertoire produit utilisé par le build en air gap ; il isole cet état de toute installation standard de la Devin CLI présente sur la même machine, laquelle utilise cli.
Sous Windows, la CLI ne lit pas les variables XDG_*. Elle conserve les mêmes fichiers dans %APPDATA%\devin\, et son cache dans %LOCALAPPDATA%\devin\ :
État spécifique à Desktop
L’application Desktop est isolée de toute autre installation de Devin Desktop ou de Windsurf sur la même machine :
Le lien symbolique n’est créé au démarrage de Desktop que si rien n’existe encore à l’emplacement
~/.devin-airgap-config/devin/config.json. Si un fichier ordinaire s’y trouve déjà, Desktop le laisse tel quel et l’agent intégré utilise ce fichier à la place du fichier partagé ; le canal de sortie Devin ACP consigne alors une ligne WARNING: … is a regular file, not a symlink. Supprimez le fichier et redémarrez Desktop pour rétablir le lien.
Sous Windows, il n’y a pas de lien symbolique. L’agent intégré de Desktop et la CLI partagent directement %APPDATA%\devin\config.json, et Desktop ne charge pas le fichier %APPDATA%\devin\mcp_config.json de l’utilisateur. Les données utilisateur de Desktop se trouvent dans %APPDATA%\Devin - Airgap\.
Pour repartir de zéro lors d’une réinstallation, seuls ~/.devin-airgap-config/ et ~/.devin-airgap/ peuvent être supprimés sans risque. ~/.config/devin/ et ~/.local/share/devin/ sont également utilisés par la CLI autonome.
Journal d’audit
La CLI en air gap écrit un journal d’audit local, structuré et en ajout seul (append-only). Il est toujours actif (aucune option ne permet de le désactiver), n’existe dans aucun autre build de Devin et est enregistré sur le poste de travail pour votre propre revue et pour l’ingestion dans votre SIEM.Emplacement et rotation
Si vous avez besoin d’une rétention illimitée, transférez les fichiers archivés par rotation vers votre SIEM avant leur suppression. Comme la CLI se contente d’ajouter des lignes sans jamais réécrire les lignes existantes, un collecteur standard de suivi de fichiers suffit ; consultez Transférer le journal d’audit vers votre SIEM.
Garanties de masquage
Les événements ne contiennent que des chemins et des métadonnées. Le journal ne contient jamais de prompts, de réponses du modèle, de code, de contenu de fichiers, de valeurs secrètes, de clés API ni de lignes de commande shell complètes : pour les outils shell, seul le nom du programme (le premier token) est enregistré.Enveloppe (version de schéma 1)
Chaque ligne contient cette enveloppe ; les champs propres à chaque événement figurent au même niveau, à plat.
Configurez votre analyseur pour qu’il ignore les champs inconnus et les valeurs
event inconnues : de nouveaux champs et types d’événements peuvent être ajoutés sans que schema_version soit incrémenté.
Types d’événements
session_start
Émis au démarrage d’une session d’agent (session racine nouvelle ou reprise).
session_end
Émis lorsque la session se termine ou que l’agent s’arrête.
session_start est associé à exactement un session_end pour le même session_id en cas de sortie propre. La CLI exécute l’agent dans un processus enfant qu’elle arrête lors de la phase de nettoyage ; c’est donc le processus parent qui consigne le session_end de la session enfant (motif other) à la fin de la session. Une session interrompue par SIGKILL ou par une coupure de courant ne peut pas écrire d’événement final ; considérez tout session_start sans session_end correspondant comme une terminaison anormale.
tool_call
Émis après chaque exécution d’un outil par l’agent.
file_read et file_write
Émis en plus de tool_call, une fois pour chaque chemin compris dans le périmètre d’autorisation déterminé de l’outil. Ils décrivent l’accès auquel l’outil était limité, et non des E/S vérifiées : un outil approuvé avec un périmètre d’autorisation en lecture sur plusieurs chemins émet un file_read par chemin, même s’il n’a accédé qu’à certains d’entre eux, et ces événements sont émis, que l’appel d’outil ait réussi ou non.
model_call
Émis après chaque requête d’inférence envoyée à un endpoint de modèle défini dans votre fichier de modèles.
Les champs de tokens sont omis lorsque l’endpoint ne communique pas l’utilisation.
auth
Objet actor
L’attribution de l’identité repose sur l’utilisateur du système d’exploitation, l’identité Git locale et (lorsque le SSO est configuré) l’identité issue du token d’ID validé. Les champs sont omis lorsqu’ils ne sont pas disponibles.
Les champs SSO figurent dans chaque événement
auth pour lequel un token validé est disponible (sso_login, sso_refresh, sso_logout, sso_login_denied), dans sso_revalidation_failed pour la connexion validée par le processus (ou, s’il n’en a validé aucune, pour la connexion encore présente dans le cache de tokens), ainsi que dans session_start et identity_resolved pour la connexion validée au démarrage par le processus en cours d’exécution. tool_call, file_read, file_write et model_call ne comportent pas d’actor ; rattachez-les à leur session_start via session_id.
sso_groups enregistre les appartenances aux groupes IdP de chaque utilisateur sur la machine locale. Le répertoire et les fichiers d’audit ne sont accessibles qu’à leur propriétaire ; incluez-les dans votre revue de traitement des données si les noms de groupes sont sensibles dans votre environnement.Transférer le journal d’audit vers votre SIEM
Devin n’envoie les enregistrements d’audit nulle part. Pour agréger l’utilisation de l’ensemble des postes de travail, configurez l’agent de collecte de journaux déjà utilisé par votre SIEM (par exemple un Splunk universal forwarder ou Elastic Agent) pour qu’il lise le répertoire d’audit de chaque poste. Aucun paramètre Devin n’entre en jeu. Configurez l’entrée de fichiers de l’agent avec les paramètres suivants :
Le poste de travail de chaque utilisateur conserve le fichier actif ainsi qu’au plus 10 fichiers archivés par rotation de 10 MiB chacun, soit environ 110 MiB au total. Au-delà, les enregistrements les plus anciens sont supprimés : un poste qui produit davantage entre deux collectes perd donc ses enregistrements les plus anciens.
Pour vérifier que la collecte fonctionne, démarrez puis terminez une session Devin sur un poste de travail, et recherchez ensuite dans votre SIEM un enregistrement
session_start et un enregistrement session_end ayant le même session_id.
Exemple : Splunk Universal Forwarder
Déployez ces deux fichiers dans une application sur chaque forwarder (par exemple$SPLUNK_HOME/etc/apps/devin_audit/local/). N’utilisez que la stanza monitor correspondant au système d’exploitation du poste de travail, et remplacez devin par l’index de votre choix.
inputs.conf
props.conf
props.conf doit se trouver sur le forwarder, et pas uniquement sur les indexeurs, car INDEXED_EXTRACTIONS s’applique là où le fichier est lu. Laissez crcSalt non défini : le forwarder reconnaît alors un fichier archivé par rotation à son contenu et ne le relit pas sous son nouveau nom. Chaque répertoire du chemin avec caractères génériques doit être accessible en lecture au compte sous lequel s’exécute le forwarder ; un forwarder installé sous un compte de service non root ne peut pas lire les répertoires d’audit réservés à leur propriétaire.
Les champs arrivent sous forme de champs indexés portant leurs noms JSON, si bien que actor.sso_user, model et input_tokens sont directement interrogeables :
Exemple : Elastic (Filebeat ou Elastic Agent)
Ajoutez cette entréefilestream au fichier filebeat.yml. Ne conservez que le chemin correspondant au système d’exploitation du poste de travail.
filebeat.yml
ndjson place chaque enregistrement sous un préfixe devin. (devin.event, devin.session_id, devin.actor.sso_user). Ne définissez pas target: "" : le champ event de l’enregistrement est une chaîne de caractères, ce qui entre en conflit avec l’objet event de l’Elastic Common Schema et amène Elasticsearch à rejeter les documents. Le processeur timestamp copie ts dans @timestamp ; Elastic considère ce processeur comme étant en version bêta. Si vous le préférez, supprimez-le et définissez plutôt @timestamp à partir de devin.ts dans un pipeline d’ingestion. L’id doit être unique parmi vos entrées filestream. Par défaut, Filebeat identifie un fichier par une empreinte de son début, qui permet de suivre le fichier lorsque la rotation le renomme : aucun paramètre de rotation n’est donc nécessaire. La longueur de l’empreinte passe de 1024 octets (valeur par défaut) à 64, car les versions 9.0 à 9.4 de Filebeat ignorent un fichier tant qu’il n’atteint pas cette taille, ce qui laisserait de côté un poste de travail ne comptant que quelques enregistrements. Les 64 premiers octets d’un fichier d’audit contiennent le ts et le pid du premier enregistrement, ce qui garantit des empreintes distinctes. Si vous modifiez cette longueur ultérieurement, Filebeat relira tous les fichiers.
Avec Elastic Agent, ajoutez l’intégration Custom Logs (Filestream) à la politique de l’agent, saisissez les mêmes chemins, puis placez les blocs parsers et processors ci-dessus dans le champ de configuration personnalisée de l’intégration.
Cognition n’a pas testé ces exemples sur un déploiement Splunk ou Elastic. Validez-les dans votre environnement et consultez la documentation du fournisseur correspondant à votre version installée avant de les déployer sur les postes de travail.
Seuls les enregistrements
session_start et auth identifient l’utilisateur. Pour attribuer les enregistrements tool_call, file_read, file_write et model_call à un utilisateur, joignez-les à l’enregistrement session_start ayant le même session_id.
Rapport de diagnostic
devin diagnostics génère un rapport expurgé en texte brut, que vous pouvez relire avant de l’envoyer au support Cognition. Il contient uniquement les versions, la structure de la configuration (présence de chaque fichier et validité de son analyse), les noms des modèles, l’indication pour chaque variable de clé d’API de sa définition ou non, ainsi que des statistiques sur le journal d’audit. Il ne contient jamais de prompts, de code, de contenu de fichiers, de valeurs secrètes, d’URL d’endpoint ni de valeurs de variables d’environnement.
--output <path> pour choisir le nom du fichier. Le rapport est enregistré avec des droits d’accès réservés au propriétaire (0600). Consultez la section Dépannage pour savoir quels éléments joindre à une requête d’assistance.