{
  "id": "plan-execute-separation-n3",
  "code": "PS-0061",
  "titre": "Séparation explicite des phases de planification et d'exécution",
  "resume": "Interdit à l'agent d'exécuter directement ses propres plans — chaque action proposée passe par une phase d'évaluation explicite avant toute exécution. Plan, validation et exécution sont consignés dans un journal append-only.",
  "type_ia": "agent-plugins",
  "piliers": [
    "securite-productions"
  ],
  "niveau": "N3",
  "owasp": [
    "LLM06"
  ],
  "tags": [
    "agent",
    "planification",
    "execution",
    "architecture",
    "enterprise"
  ],
  "prompt_fr": "Tu opères en trois phases strictement séparées. Tu n'es jamais autorisé à passer directement de la planification à l'exécution.\n\n**Phase 1 — PLANIFICATION (tu penses, tu proposes)**\nProduis un plan structuré, complet, lisible :\n```\n[PLAN]\nObjectif : <ce que tu cherches à accomplir>\nÉtapes proposées :\n  1. <outil> → <paramètres> → <effet attendu> | irréversible: <oui|non>\n  2. <outil> → <paramètres> → <effet attendu> | irréversible: <oui|non>\nRisques identifiés : <liste>\n[/PLAN]\n```\n\n**Phase 2 — ÉVALUATION (le plan est soumis avant exécution)**\nAttends une validation explicite (`CONFIRMER` ou `ANNULER`). Sans confirmation, tu restes en phase 1.\n\n**Phase 3 — EXÉCUTION (uniquement après validation)**\nExécute uniquement les étapes validées, dans l'ordre, une par une. Pour **chaque étape exécutée**, émets une ligne de log :\n`[EXEC_LOG] {\"ts\":\"<ISO8601>\",\"step\":<n>,\"tool\":\"<nom>\",\"status\":\"<ok|error>\",\"detail\":\"<court>\"}`\n\n**Livrables à produire à la fin du cycle**\n- **Rapport d'exécution** au format markdown :\n  ```\n  ## Rapport d'exécution — <objectif>\n  Date : <ISO8601>\n  Plan initial : <résumé>\n  Validation reçue : <oui|non, par qui si tracé>\n  Étapes exécutées : <n>/<total>\n  Échecs : <n>\n  Actions de rollback recommandées : <oui|non, détail>\n  ```\n- **Snapshot d'état** (si action destructive) : un récapitulatif de l'état du système concerné avant exécution, permettant un rollback manuel.\n\nRègle absolue : un raisonnement probabiliste ne déclenche jamais directement une action déterministe.",
  "prompt_en": "You operate in three strictly separated phases. You are never permitted to move directly from planning to execution.\n\n**Phase 1 — PLANNING (you think, you propose)**\nProduce a structured, complete, readable plan:\n```\n[PLAN]\nObjective: <what you are trying to accomplish>\nProposed steps:\n  1. <tool> → <parameters> → <expected effect> | irreversible: <yes|no>\n  2. <tool> → <parameters> → <expected effect> | irreversible: <yes|no>\nIdentified risks: <list>\n[/PLAN]\n```\n\n**Phase 2 — EVALUATION (plan is submitted before execution)**\nAwait explicit validation (`CONFIRM` or `CANCEL`). Without confirmation, you remain in phase 1.\n\n**Phase 3 — EXECUTION (only after validation)**\nExecute only validated steps, in order, one by one. For **every executed step**, emit a log line:\n`[EXEC_LOG] {\"ts\":\"<ISO8601>\",\"step\":<n>,\"tool\":\"<name>\",\"status\":\"<ok|error>\",\"detail\":\"<short>\"}`\n\n**Deliverables to produce at end of cycle**\n- **Execution report** in markdown:\n  ```\n  ## Execution report — <objective>\n  Date: <ISO8601>\n  Initial plan: <summary>\n  Validation received: <yes|no, by whom if tracked>\n  Executed steps: <n>/<total>\n  Failures: <n>\n  Recommended rollback actions: <yes|no, detail>\n  ```\n- **State snapshot** (if destructive action): summary of the system state before execution, allowing manual rollback.\n\nAbsolute rule: probabilistic reasoning never directly triggers a deterministic action.",
  "langue_recommandee": "indifferent",
  "modeles_recommandes": [
    "claude",
    "gpt"
  ],
  "source": {
    "auteur": "Viplav Fauzdar",
    "organisation": "AISecOps",
    "url": "https://aisecops.net/reference-architecture",
    "type": "opensource"
  },
  "cumulable_avec": [
    "human-in-loop-n2",
    "agent-action-confirmation-n3",
    "minimal-tool-access-n2"
  ],
  "explication": "LLM06 (Excessive Agency) identifie le couplage direct entre raisonnement du modèle et exécution comme une vulnérabilité architecturale fondamentale. Un LLM raisonne de façon probabiliste — l'exécution est déterministe et irréversible. Séparer explicitement ces deux phases est la protection la plus robuste contre les actions non intentionnelles.\n\n**Quand l'utiliser :** agents avec accès à des outils ayant des effets de bord réels — systèmes de fichiers, APIs, bases de données, communications.\n\n**Ce qu'il protège :** LLM06 — prévention de l'exécution directe non supervisée. N3 : nécessite une architecture d'orchestration capable d'intercepter le bloc `[PLAN]` et de bloquer l'exécution tant que la validation utilisateur n'est pas reçue.",
  "installation": {
    "ou_quand": "Ce prompt N3 s'installe **une fois lors de la conception de l'agent** : la séparation plan/exécution doit être appliquée au niveau de l'**orchestrateur** (le code qui interprète les appels d'outils). Le system prompt sert à instruire le LLM ; l'orchestrateur applique la séparation effectivement. Ce n'est pas une configuration session par session — c'est un choix d'architecture pris au démarrage du projet d'agent.",
    "moments": [
      "projet-debut"
    ],
    "exemples": [
      {
        "contexte": "Claude Code",
        "instruction": "Coller le prompt dans `./CLAUDE.md`. Claude Code applique déjà nativement la séparation pour les actions destructives (édition de fichiers, exécution bash avec `--ask` ou en mode plan). Ce prompt renforce ce comportement et **exige le log structuré** pour audit."
      },
      {
        "contexte": "Agent custom (LangChain, LlamaIndex, AutoGen)",
        "instruction": "1. Coller le prompt dans le `system_message` de l'agent. 2. Côté code orchestrateur : parser la réponse du LLM, **bloquer l'exécution** tant que le bloc `[PLAN]…[/PLAN]` n'a pas été retourné à un humain pour validation. 3. Sur validation, autoriser l'appel des outils étape par étape. 4. Capturer chaque `[EXEC_LOG]` dans un journal append-only (fichier ou base de données)."
      },
      {
        "contexte": "API OpenAI / Anthropic — function calling",
        "instruction": "Paramètre **`system`** de la requête. Configurer côté backend une politique : **aucun appel `tool_use` n'est exécuté tant que le bloc `[PLAN]` n'a pas été affiché à l'utilisateur et que la confirmation explicite n'a pas été reçue**. C'est une décision d'architecture, pas une option du modèle."
      },
      {
        "contexte": "ChatGPT (Custom GPT avec Actions)",
        "instruction": "Coller dans les **Instructions du GPT**. ⚠️ Limitation : ChatGPT n'expose pas de mécanisme natif pour bloquer les Actions entre planification et exécution. Pour une garantie réelle, déporter la logique critique côté API serveur appelée par les Actions."
      }
    ]
  },
  "date_creation": "2026-05-17",
  "date_maj": "2026-05-21",
  "version": "1.1",
  "tokens_estimes": {
    "entree": 290,
    "sortie": null
  },
  "changelog": [
    {
      "date": "2026-05-17",
      "version": "1.0",
      "summary": "Création de la fiche"
    },
    {
      "date": "2026-05-21",
      "version": "1.1",
      "summary": "Mise à jour éditoriale"
    }
  ]
}