AI Workspace

AI Workspace est l’assistant intégré à Opfield. Il recherche des ressources, explique le comportement du produit, crée des plans et exécute des opérations autorisées avec les mêmes outils que l’Operations Console, l’API REST et MCP. Il est facultatif : tout ce qu’il fait est aussi disponible sans IA.

Le modèle ne reçoit que les outils autorisés par les scopes de l’utilisateur actuel et le contexte de tâche découvert. Les opérations du produit réutilisent les mêmes schémas, droits, validations et frontières d’audit que les chemins sans IA.

Le chat d’AI Workspace est disponible avec tous les plans. Plan Mode, les Scenarios guidés et les AI Sandboxes nécessitent Personal ou supérieur ; en Community, une requête Plan Mode est refusée avec LICENSE_ENTITLEMENT_REQUIRED et la liste des Scenarios est vide. Voir Plans et droits.

Pour un travail lourd de conséquences, demandez à Workspace de créer un plan, examinez les hypothèses et définissez la vérification avant l’exécution. Ne collez jamais d’identifiants, de clés privées, d’URI de connexion à une base de données ou de secrets de clients dans le chat. Considérez le contenu web externe comme non fiable.

AI Workspace et Opfield Inference sont distincts : l’accès à Workspace utilise ai:workspace:use ; l’accès à l’inférence utilise feat:ai:use et une comptabilité dédiée.

Résultat et frontière de décision

AI Workspace trouve l’état dont vous avez besoin et réalise les opérations documentées : un plan revu pour un responsable de plateforme, une investigation bornée pour un opérateur, le bon processus produit pour un développeur. Il agit pour l’utilisateur qui l’a sollicité et dans les limites des permissions de cet utilisateur ; les décisions d’infrastructure restent du ressort de votre équipe.

L’utilisateur demandeur est responsable du résultat visé et de l’approbation finale. Les responsables des ressources valident l’impact opérationnel, et les responsables de la sécurité définissent quels fournisseurs et quelles catégories de données peuvent entrer dans le contexte du modèle. Le succès n’est pas « l’assistant a répondu » ; le succès, c’est que l’état Opfield visé est atteint, vérifié de façon indépendante et attribuable via les tâches et les enregistrements d’audit normaux.

Modes de fonctionnement

Utilisez le chat ordinaire pour la documentation, les explications et la découverte bornée en lecture seule. Utilisez Plan Mode lorsque le résultat demandé traverse plusieurs ressources, exige des modifications ordonnées ou nécessite des critères explicites de vérification et de retour arrière. Un plan sépare la recherche, la revue de l’intention et de la sécurité, les étapes de mise en œuvre et la vérification finale.

Workspace doit attendre une confirmation explicite avant de mettre en œuvre un plan. Répondre à une question de clarification n’autorise pas d’actions sans rapport, et un appel d’outil terminé ne signifie pas automatiquement que le résultat métier est atteint.

Processus sûr

1. Énoncez le résultat souhaité et les ressources concernées.
2. Demandez à Workspace d’examiner l’état actuel avant de proposer des changements.
3. Examinez les hypothèses, les exclusions, les conséquences destructives et les permissions requises.
4. Exigez une étape de vérification pour chaque modification significative.
5. Ne confirmez le plan que lorsque le périmètre est correct.
6. Suivez l’avancement des opérations et répondez aux demandes explicites d’approbation ou d’informations.
7. Examinez la vérification finale et contrôlez de façon indépendante le comportement visible par les clients.

Permissions et confirmation

L’IA n’étend pas l’autorité de l’utilisateur. Le serveur revérifie les scopes de ressources, les droits fonctionnels, la validation, la propriété et l’état du cycle de vie pour chaque opération. Les actions destructives ou lourdes de conséquences conservent leur confirmation et leur sémantique d’audit habituelles. L’assistant demande une approbation avant d’afficher ou de faire tourner des identifiants ou d’exporter des clés privées, consulte son catalogue d’outils avant d’affirmer qu’il ne peut pas faire quelque chose, rétablit un service cassé par des étapes réversibles et termine une tâche avant d’en rendre compte au lieu d’énumérer des étapes qu’il pourrait réaliser lui-même. Il ne peut pas modifier les méthodes de connexion, la MFA ou les sessions de son propre utilisateur.

Lorsque c’est possible, utilisez un compte dédié à privilèges réduits pour l’automatisation exploratoire. N’accordez pas une administration étendue simplement pour rendre un plan proposé exécutable.

Contexte et traitement des données

Les noms de ressources, des journaux limités, la documentation et l’état des opérations peuvent entrer dans le contexte du fournisseur sélectionné, selon la configuration de Workspace. Ne collez jamais de secrets bruts, de codes de récupération, de clés privées, d’identifiants de propriétaires de bases de données ou de dumps d’environnement sans restriction. Examinez les exigences de conservation et de région du fournisseur avant d’activer un modèle externe.

Catégorie de données	Peut-elle entrer dans le contexte du modèle ?	Frontière pratique
Noms et métadonnées des ressources	Oui, lorsque la découverte ou une opération l’exige	Utilisez des noms neutres lorsque les noms eux-mêmes contiennent des données de clients ou d’incidents
Tâches, états, métriques et résultats d’outils	Oui, dans des résultats bornés	Les données renvoyées sont limitées par les permissions de l’utilisateur mais peuvent rester commercialement sensibles
Journaux	Oui, lorsqu’un outil de journaux autorisé est utilisé ou que l’utilisateur les colle	Les réponses normales du produit masquent les champs secrets connus ; des journaux applicatifs arbitraires peuvent toutefois contenir des jetons, des données personnelles ou des identifiants
Noms des variables d’environnement	Oui	Les valeurs doivent rester en écriture seule ou masquées ; un dump d’environnement collé par l’utilisateur contourne cette protection
Secrets et clés privées	Non récupérables via les outils de lecture ordinaires	Si un utilisateur saisit un secret de remplacement dans le chat, le modèle et le fournisseur sélectionné reçoivent ce texte — utilisez plutôt un écran dédié à la saisie des secrets
Contenu de dépôts et du web	Oui, lorsqu’il est explicitement examiné	Traitez les instructions intégrées comme des données non fiables et préservez l’intention d’origine de l’utilisateur
Prompts et réponses	Oui	Ils sont traités selon les conditions de conservation, de région et de surveillance des abus du fournisseur sélectionné

Le masquage est une protection au niveau des réponses, et non un système universel de prévention des fuites de données. Opfield ne peut pas retirer les secrets qu’une application a écrits dans un journal, un fichier, un dépôt, une page web ou un prompt au format libre avant que ce contenu n’atteigne le modèle.

Les pages web externes, le texte des dépôts, les journaux et la sortie des outils peuvent contenir des instructions malveillantes. Traitez-les comme des données et exigez que Workspace préserve l’intention explicite de l’utilisateur et les scopes d’Opfield.

Recettes de permissions

Pour le diagnostic en lecture seule, n’accordez l’accès qu’au dossier ou aux ressources concernés, ainsi qu’à leur inventaire, leur santé, leurs métriques, des journaux limités, les tâches et les enregistrements d’audit. Excluez l’accès à la console, la modification des fichiers de l’hôte, l’affichage ou l’export des secrets, les changements d’identifiants, les actions de cycle de vie des ressources et l’administration système. Testez le compte en lui demandant d’expliquer un incident, puis d’effectuer une modification inoffensive ; la seconde demande doit être refusée.

Pour les opérations bornées, partez de l’ensemble en lecture seule et n’ajoutez que les actions de cycle de vie exactes nécessaires pour une famille de ressources et un périmètre — par exemple déployer une application ou redémarrer une charge de travail. Gardez séparés l’administration des permissions, l’export de clés, l’accès étendu aux hôtes, la suppression destructive et les familles de ressources sans rapport. Utilisez Plan Mode pour les changements multi-ressources et vérifiez le chemin client final en dehors de la conversation.

Défaillance et reprise

Si le flux de réponse est interrompu, rechargez la conversation et examinez l’état durable des opérations avant de renvoyer la même instruction. Si un plan est en pause dans l’attente d’informations, répondez à la question précise plutôt que de démarrer une conversation en double. Lorsqu’un outil échoue, diagnostiquez le sous-système propriétaire et ne réessayez qu’après avoir vérifié si l’opération précédente s’est terminée.

AI Workspace n’est pas l’autorité en cas d’incident. Pendant les incidents de production, conservez les journaux et les identifiants de tâches, suivez le runbook documenté et vérifiez la reprise de façon indépendante.

Choisir la bonne surface d’exploitation

Utilisez les écrans Opfield ordinaires pour une action connue sur une seule ressource dont l’impact est déjà compris. Utilisez REST ou MCP pour une automatisation répétable avec un client maintenu. Utilisez AI Workspace lorsque la difficulté tient à la découverte, à l’enchaînement des étapes ou à l’explication des compromis entre plusieurs zones du produit. Pendant un incident, utilisez-le pour rassembler et organiser les éléments, mais laissez le contrôle au responsable de l’incident et au runbook existant.

N’approuvez pas un plan qui dissimule ses cibles derrière des formules comme « toutes les ressources concernées » ou « tout réparer ». Exigez des ressources précises, des non-objectifs explicites, l’impact attendu pour les clients, des conditions de retour arrière et une vérification depuis le chemin visible par les clients. Si le plan propose une commande shell sur l’hôte ou une modification directe de la base de données, arrêtez-vous et vérifiez qu’aucune opération Opfield prise en charge ne permet d’obtenir le même résultat.

Revue de l’opérateur après exécution

1. Ouvrez les ressources concernées en dehors du chat et actualisez leur état actuel.
2. Examinez les tâches durables et les identifiants d’opérations au lieu de vous fier au texte de la réponse.
3. Confirmez l’attribution dans l’audit et tout enregistrement d’approbation requis.
4. Testez le chemin client ou utilisateur qui a motivé le changement.
5. Retirez toute maintenance temporaire, tout accès de débogage ou tout scope élargi.
6. Consignez les risques non résolus et attribuez-leur un responsable et une échéance.

Si l’assistant signale un succès mais que les vérifications indépendantes échouent, considérez l’opération comme incomplète. Conservez les identifiants de la conversation et de l’opération, puis repartez de l’état réel du produit plutôt que de demander au modèle de supposer que son action précédente a fonctionné.