Configurer ClineCore pour des sessions de codage respectueuses de la confidentialité

Configurez la session avant d’envoyer du code privé

ClineCore permet à une application de créer un environnement d’exécution et de démarrer des sessions avec une configuration de modèle et d’environnement d’exécution. Le choix à faire en matière de confidentialité ne se limite pas au fournisseur : il faut aussi déterminer quelles données la session reçoit, quels outils peuvent intervenir et quelles informations votre application conserve ou expose ensuite.

Les exemples ci-dessous sont donnés à titre indicatif ; il ne s’agit pas d’intégrations testées. La référence ClineCore décrit la structure de l’API, mais ne garantit pas que tous les fournisseurs acceptent les mêmes paramètres de modèle ou réglages de point de terminaison. Consultez la documentation de votre fournisseur avant d’utiliser des options qui lui sont propres.

Distinguez les paramètres partagés de ceux de la session

Les options de ClineCore.create couvrent des choix tels que le nom du client, le mode backend, les règles applicables aux outils, les capacités et l’activation ou non de l’automatisation. L’appel start nécessite un config contenant les paramètres du modèle et de l’environnement d’exécution de la session. L’exemple documenté inclut providerId, modelId, apiKey, systemPrompt, cwd, workspaceRoot, ainsi que des indicateurs pour les outils et les agents.

Voici un exemple minimal côté serveur :

import { ClineCore } from "@cline/sdk"

const cline = await ClineCore.create({
  clientName: "private-code-review",
  backendMode: "auto",
  toolPolicies: {
    // Set policies for the tools your application exposes.
  },
})

const session = await cline.start({
  prompt: "Review the selected files for risky input handling.",
  config: {
    providerId: process.env.CLINE_PROVIDER_ID!,
    modelId: process.env.CLINE_MODEL_ID!,
    apiKey: process.env.CLINE_API_KEY!,
    systemPrompt: "Review only the supplied code. Do not request secrets.",
    cwd: process.cwd(),
    workspaceRoot: process.cwd(),
    enableTools: false,
    enableSpawnAgent: false,
    enableAgentTeams: false,
  },
})

Cet exemple utilise des variables d’environnement comme pratique de gestion des identifiants ; la référence ne recommande aucun gestionnaire de secrets et ne définit pas ces noms de variables d’environnement. Conservez la clé sur un serveur de confiance, ne la transmettez pas au code du navigateur et évitez d’imprimer la configuration de session dans les journaux de l’application. Si le fournisseur exige un point de terminaison ou des paramètres supplémentaires, configurez-les uniquement selon ses instructions et vérifiez que ClineCore prend en charge les champs requis.

Prenez des décisions explicites en matière de confidentialité

Avant de démarrer une session, déterminez ce dont l’agent a besoin. Lorsque la tâche le permet, privilégiez un espace de travail restreint ou une sélection de fichiers plutôt que l’ensemble du dépôt. Excluez des éléments fournis à l’agent les secrets, les données personnelles et les fichiers sans rapport avec la tâche. Un prompt système peut préciser les attentes en matière de traitement des données, mais il ne remplace ni les contrôles d’accès ni la minimisation des données.

Examinez les accès aux outils avec autant d’attention que le contenu des prompts. ClineCore accepte des règles par défaut et par session pour les outils, et les capacités de l’environnement d’exécution peuvent inclure des exécuteurs d’outils gérés par le client ainsi que des fonctions de validation. Laissez les outils désactivés lorsque la tâche ne les nécessite pas ; s’ils sont indispensables, appliquez des règles et des validations adaptées à leurs effets. La référence décrit ces mécanismes de configuration, mais ne précise pas le comportement de chaque outil et ne garantit pas qu’une règle particulière empêchera toute action sensible.

Considérez les enregistrements de session comme potentiellement sensibles. L’API peut lister les sessions, récupérer leurs métadonnées et leurs messages, consulter l’utilisation cumulée, mettre à jour les enregistrements et supprimer des sessions. Votre application doit donc déterminer qui peut appeler ces méthodes et quelles règles de conservation appliquer. Évitez d’inclure des secrets ou des données personnelles superflues dans sessionMetadata, les messages initiaux ou les prompts : les métadonnées et les messages sont des données de session, pas un stockage sécurisé des secrets.

L’option distinctId est présentée comme un identifiant stable de télémétrie ou d’utilisateur. Si vous l’utilisez, demandez-vous si votre application a besoin d’un identifiant stable et s’il pourrait permettre d’identifier une personne. La référence ne précise pas la collecte, la durée de conservation ou l’anonymisation de la télémétrie. Ne supposez donc ni que cet identifiant est anonyme, ni que sa définition contrôle l’ensemble de la télémétrie.

Résolvez les problèmes de configuration courants

• La création de session rejette la configuration : vérifiez la présence de config et assurez-vous que les identifiants du fournisseur et du modèle correspondent aux valeurs acceptées par le fournisseur. La référence fournie donne un exemple, pas un catalogue complet des fournisseurs.
• L’authentification échoue : vérifiez que le processus serveur a accès à la clé, qu’elle correspond au fournisseur sélectionné et qu’elle n’a pas été tronquée ou remplacée par erreur. N’incluez jamais la clé dans un prompt de diagnostic et ne la copiez pas dans un ticket.
• Une option propre au fournisseur est ignorée ou rejetée : la référence ClineCore ne documente pas de compatibilité universelle des points de terminaison ou des paramètres. Consultez la documentation du fournisseur et du SDK au lieu de supposer que les réglages d’un fournisseur sont valables pour un autre.
• Une session peut effectuer plus d’actions que prévu : examinez enableTools, les règles applicables aux outils et les capacités fournies. Commencez par désactiver les outils lorsqu’ils ne sont pas nécessaires, puis n’activez que ceux dont le flux de travail a besoin.
• Du contenu sensible apparaît dans l’historique : vérifiez quels parcours de l’application appellent readMessages, list et les API de session associées, puis appliquez des contrôles d’autorisation et de conservation adaptés. La référence expose ces API, mais ne précise pas les protections de stockage ou d’accès de votre application.
• Le travail se poursuit de manière inattendue : utilisez la méthode documentée abort ou stop pour la session et libérez les ressources de l’environnement d’exécution lorsque l’application n’en a plus besoin.

Liste de vérification avant lancement

Avant d’activer un flux de travail ClineCore, vérifiez que les identifiants restent côté serveur ; que l’espace de travail ne contient que les fichiers nécessaires ; que les prompts et les métadonnées ne contiennent aucun secret ; que les accès aux outils sont limités et examinés ; que l’historique des sessions a un responsable et une règle de conservation ; et que les paramètres propres au fournisseur ont été vérifiés dans sa documentation à jour. Pour le débogage, consignez des informations non sensibles, comme le fait qu’une session a démarré et l’identifiant interne de la requête concernée, mais pas les identifiants, les prompts complets ni les fichiers source.

La référence ClineCore décrit des mécanismes de configuration et de gestion des sessions ; elle ne garantit pas la confidentialité de manière générale. Le respect de la confidentialité dépend de la façon dont votre application fournit les données, contrôle l’accès aux outils, protège les enregistrements de session et gère les identifiants.

Source

• Référence de l’API ClineCore — options de l’API, configuration des sessions, méthodes de gestion des sessions et présentation de l’automatisation.