Prévention active

Détectif vs préventif

L'application détective — observer, expliquer, produire un verdict — est en service dès maintenant sur tous les connecteurs. L'application préventive agit chez le fournisseur et s'active à la demande par connecteur : activer la prévention définit l'opt-in par connecteur (et, en mode fictif, simule l'octroi de la portée d'écriture élevée afin que toute la boucle soit démontrable dès aujourd'hui).

Cinq actions de remédiation

Chaque proposition correspond à l'un des cinq types d'action, chacun portant ses préconditions, l'appel d'API fournisseur exact qu'il effectuerait, et l'état antérieur qu'il enregistre pour l'annulation :

• Supprimer le lien public — retirer un partage anonyme ou web public.
• Révoquer le partage — retirer un octroi externe ou invité spécifique.
• Rétrograder l'accès — réduire une autorisation trop large (par exemple, éditeur → lecteur).
• Suspendre le principal — désactiver une identité malveillante ou compromise.
• Révoquer la portée d'un agent — retirer le consentement trop large d'un agent d'IA ou d'une application.

Les quatre niveaux de remédiation

Vous choisissez jusqu'où 8200.dev va pour corriger un signalement. Définissez un paramètre par défaut à l'échelle de l'organisation et remplacez-le par règle dans les Politiques de sécurité. Les niveaux forment une échelle stricte — chacun ajoute une capacité et, avec elle, un rayon d'impact.

8200.dev est en lecture seule par défaut. L'accès en écriture ne provient que d'une autorisation distincte que vous approuvez — par dépôt pour Fix-PR, par connecteur pour Auto — et jamais depuis la connexion de surveillance centrale.

1. 1Notifier (tous les forfaits) — une alerte accompagnée d'un playbook de remédiation. Rien n'est modifié. Il s'agit du paramètre par défaut.
2. 2Correction guidée (forfaits payants) — les commandes exactes, un lien direct vers les paramètres du fournisseur pour cette ressource, et les étapes. Vous les exécutez de votre côté ; aucun accès en écriture n'est requis.
3. 3Fix-PR (Business et supérieur) — 8200.dev ouvre une pull request de remédiation dans votre dépôt ; un humain la révise et la fusionne. Rien ne change sans approbation, et cela nécessite une autorisation d'écriture distincte, révocable et par dépôt.
4. 4Auto (Business et supérieur) — pour les règles que vous choisissez, 8200.dev applique la correction automatiquement dans le cadre des garde-fous d'auto-guard existants (coupe-circuit, liste d'autorisation, consentement par connecteur).

Manuel ou AUTO-GUARD

La remédiation manuelle se fait en un clic : Simuler toujours, Exécuter avec confirmation explicite lorsque la prévention est active. AUTO-GUARD agit éventuellement de manière automatique uniquement sur les violations déterministes à forte confiance — désactivé par défaut et disponible à partir du palier Business.

AUTO-GUARD est fail-closed par conception : un verdict reposant uniquement sur le modèle ne peut jamais déclencher une exécution automatique, seule une liste d'autorisation prudente de types d'actions est éligible, et un coupe-circuit global l'emporte sur toutes les barrières et rétrograde toute application en mode simulation seule.

Simulé jusqu'à autorisation

Tant que la portée d'écriture OAuth n'est pas accordée et évaluée, chaque action s'exécute en mode simulation et est étiquetée comme telle — rien ne prétend à une modification réelle chez le fournisseur qui n'a pas eu lieu. L'application via le connecteur fictif est réelle et réversible sur le graphe de démonstration, signalée comme données de démonstration.

Chaque action — simulée ou réelle — inscrit une piste d'audit complète et réversible : qui, quoi, quand, avant → après, et résultat.