Laissez l'agent travailler. Gardez le contrôle de l'effet final.

À qui il s'adresse

Trois surfaces, un principe

Les agents peuvent proposer. L'autorité reste hors de l'agent. La couverture se limite aux routes déclarées et testées : SecureStamp ne contrôle pas les opérations qui contournent cette frontière, et les nomme au lieu de les cacher.

Break the Mandate — le parcours guidé

La question d'entrée est simple : votre agent peut-il faire quelque chose en dehors de la tâche que vous avez approuvée ? Le scénario de référence y répond en cinq étapes, sur des fixtures synthétiques, sans compte et sans clé d'API de modèle.

1. 01

   Une tâche utile

   L'agent prépare une modification réelle dans une fixture confinée.

2. 02

   La faille, dans la baseline

   La même tentative hors périmètre produit son effet dans une baseline volontairement permissive, observée depuis un autre processus. C'est un contrôle expérimental connu, non une vulnérabilité découverte sur votre machine.

3. 03

   La faille, contenue

   Avec le contrôle actif, cette route est contenue et la tâche utile s'achève quand même. Un refus qui rend la tâche inutile ne compte pas comme une valeur.

4. 04

   La preuve expire quand l'environnement change

   Une dépendance matérielle du profil change : la preuve antérieure cesse d'habiliter cette route jusqu'à sa revalidation.

5. 05

   Seul le candidat exact sort

   Le candidat gelé est examiné. Modifier ses octets ou sa destination invalide l'export ; rétablir ce qui a été approuvé autorise l'effet.

Démarrage rapide

Doctor n'a besoin ni de Docker ni d'un modèle et n'exécute rien de ce qu'il lit. Le scénario de référence est synthétique : il n'exécute jamais de code du projet et son rapport est étiqueté comme preuve simulée.

# Node 22.22.3 ou version ultérieure
npm install --save-dev @securestamp/mcp-guard @securestamp/execution-governance

# 1. Doctor : diagnostic statique des fichiers que vous choisissez
npx securestamp-mcp-doctor scan .mcp.json --propose
npx securestamp-mcp-doctor scan-native <settings.json|config.toml> --format=<shape>
npx securestamp-mcp-doctor scan-workflow .github/workflows/agent.yml

# 2. Scénario portable : valider et exécuter la référence, avec un hold
npx securestamp-execution-governance validate scenario.json
npx securestamp-execution-governance run scenario.json --hold-before=step-1

Chaque commande affiche son usage et les formats pris en charge lorsqu'on lui donne des arguments invalides. Pour un HarnessProfileV1 complet, utilisez securestamp-mcp-doctor scan-harness. Avec --hold-before, l'exécution montre un effet retenu qui n'est jamais admis. Aucune télémétrie par défaut.

Doctor : vos fichiers natifs d'abord

Doctor produit des faits déclarés, chacun avec son fichier source et son champ, ainsi qu'un diagnostic partiel qui indique quelles couches il a lues et lesquelles restent inconnues. La compatibilité se décrit comme forme + transport + client testé ; un format qu'il ne reconnaît pas est signalé comme non pris en charge, jamais ignoré en silence.

• .mcp.json · JSON avec mcpServers (stdio)

  Commandes déclarées, références de credentials, secrets écrits dans le fichier, lancements via shell et paquets mutables ou en @latest. Une version épinglée n'établit pas l'intégrité : vérifier l'artefact effectif par rapport à celui qui a été approuvé incombe à l'exécutant.

• settings.json · config.toml ([mcp_servers])

  Permissions, outils et couches de configuration reconnues, avec les conflits et les données manquantes. Un fichier seul ne révèle ni les politiques gérées, ni les surcharges CLI, ni la configuration héritée : la sortie le signale.

• .github/workflows/*.yml

  Agent Workflow Doctor : entrée non fiable d'une issue, d'une PR ou d'un commentaire qui atteint l'agent, permissions déclarées, références de secrets, outils étendus et checkout de contenu externe. Il ne télécharge pas les actions, ne résout pas les secrets et n'exécute pas le YAML.

• HarnessProfileV1

  Le profil complet pour les utilisateurs avancés. Doctor ne l'invente jamais à partir d'un seul fichier : montages, observateur, credentials effectifs et backend sont choisis et validés par l'opérateur.

• Ne lit que les fichiers qu'on lui désigne ; il ne parcourt pas le répertoire personnel.
• N'exécute aucune commande, aucun hook ni aucune expression du fichier.
• Ne résout aucun secret et ne valide aucun token.
• Propose un correctif révisable sur une copie ; n'écrase jamais l'original.
• Présente un résultat propre avec le même poids qu'un constat.
• Un diagnostic statique n'établit ni l'isolation ni la protection.

Exact Export : l'agent prépare, vous autorisez la modification exacte

L'agent prépare la modification dans une copie confinée de votre projet. Le credential d'export reste hors de son environnement, et seul le candidat examiné sort, par l'Execution Guardian.

1. 01

   Préparer

   En quarantaine, sur un instantané du projet choisi ; votre .git n'est jamais réutilisé comme base de confiance.

2. 02

   Geler

   Le candidat est fixé avant l'examen : base, octets et empreintes, ref, destination et état antérieur.

3. 03

   Autoriser

   L'approbation est liée à ce candidat. Une modification ultérieure l'invalide ; un --yes ne remplace ni la MFA ni le quorum.

4. 04

   Exécuter

   Conservé en dépôt par le Guardian, avec vérification de l'état de la destination : les dérives et les courses ne sont jamais écrasées.

5. 05

   Vérifier

   Vérification indépendante de la postcondition et un reçu que vous joignez à la PR ou à l'issue.

La destination initiale est un dépôt Git local. Avec un profil et une destination autorisés, l'adaptateur GitHub crée une nouvelle ref : il ne met à jour aucune branche, ne fait ni force-push, ni merge, ni déploiement, et l'ouverture d'une PR est un effet distinct avec sa propre autorisation. La garde du credential n'est revendiquée que pour le profil qui la démontre avec l'identité effective, les montages, les sockets et le réseau, ainsi que des canaris depuis le contexte de l'agent.

Une configuration portable, trois interfaces

La configuration est un fichier JSON versionné dans votre dépôt. La bibliothèque génère les contrats complets et leurs empreintes ; personne n'écrit de signatures à la main. La CLI et le tableau de bord importent et exportent la même représentation et passent la même validation : il n'existe pas de politique web différente de la politique dans Git. Chaque modification crée une nouvelle révision et les exécutions actives conservent leur instantané.

• npm · @securestamp/execution-governance

  Contrats de scénario portables, plan de contrôle avec hold, resume et stop, et rapports expurgés : valider et sérialiser des scénarios, lancer des exécutions, émettre des ordres idempotents, et construire, vérifier et comparer des rapports. Il n'accorde aucune autorité, ne confine pas l'hôte et ne remplace pas le Guardian du client.

• CLI · securestamp-mcp-doctor · securestamp-execution-governance

  scan, scan-native, scan-workflow et scan-harness pour le diagnostic ; validate et run pour les scénarios. Sans compte. Chaque exécution produit son propre rapport sans en écraser un autre.

• Dashboard · securestamp.online/dashboard/agents

  Scénarios, préparation, exécutions, détail en direct et analyse post-exécution, sur des runners enrôlés exploités par le client. Le navigateur n'exécute pas le test et ne reçoit pas les credentials du fournisseur ; connecter un runner est optionnel.

Hold, resume, stop

Les contrôles agissent sur les routes médiatisées par le Guardian. L'agent peut continuer à raisonner pendant que ses effets sont suspendus ; l'interface l'affiche comme « effets suspendus / processus en cours », jamais comme un agent gelé.

Une réponse HTTP réussie confirme seulement que l'ordre a été reçu. Le tableau de bord montre séparément ce qui a été demandé, ce que le superviseur a appliqué et ce qui a été observé. Si le canal distant tombe alors que l'observateur est sain, les admissions restent suspendues en local ; si l'observateur tombe, le profil coupe l'egress et termine le conteneur. Le stop local ne dépend jamais du tableau de bord.

Rapports : des états qui ne se réduisent pas à un feu tricolore

Le rapport d'exécution porte seulement une somme de contrôle informative, déclare son niveau de preuve et permet de comparer les exécutions ; une somme de contrôle n'authentifie pas l'émetteur. Lorsqu'un bundle Action Proof complet est joint, le vérificateur indépendant le vérifie hors ligne avec des ancres fournies en dehors du rapport et lie le candidat, la destination, l'autorité et le résultat observé du reçu. Un FAIL, un SKIP, une preuve absente ou une route non évaluée reste visible ; une défaillance d'instrumentation laisse l'exécution en INCOMPLETE, jamais en PASS.

Contrôle informatif de pull request

Compare la base et la tête des fichiers natifs avec les mêmes importeurs et règles, montre les changements déclarés, les inconnues et les candidats à la revalidation, et valide un reçu joint par rapport à ses ancres. Il s'exécute depuis une révision de confiance épinglée, avec des permissions de lecture, sans secrets et sans exécuter de code de la PR. Il informe la revue : ce n'est pas le contrôle qui autorise un export, ni un substitut du Guardian ou d'un ruleset.

Ce que cela ne fait pas

• Il ne rend pas le modèle sûr et ne prouve pas un alignement général : il teste des limites d'exécution sur un profil déclaré.
• Il ne contrôle pas les routes qui contournent le Guardian ; une route sans sonde reste not evaluated, jamais protégée par héritage.
• Il n'annule pas un effet déjà produit : hold et stop ne sont pas un rollback.
• Un reçu montre l'intégrité et la portée sous ses ancres ; il ne montre ni que le code approuvé est inoffensif ni que quelqu'un d'indépendant l'a audité.
• Ce n'est pas un kill switch à l'échelle de l'entreprise : la v1 contrôle l'exécution choisie et ses runners déclarés.
• La compatibilité est publiée par profil, version et environnement. Un PASS sur un harnais ne se transfère pas à un autre système d'exploitation, une autre route ou un autre client.

Pour aller plus loin