Agent Harness securise pour Claude Code et Codex : permissions, verification et rollback

Plus l’agent est puissant, plus le cadre compte

Au debut, avec Claude Code ou Codex, on pense souvent que tout depend du prompt. C’est vrai pour une petite correction. Mais lorsqu’un agent commence a toucher au deploiement, aux APIs SaaS, aux fichiers locaux, a la publication ou aux emails, le vrai sujet devient le cadre d’execution.

J’appelle ce cadre Agent Harness : permissions, plan de travail, verifications, journaux et procedure de retour arriere. L’agent peut proposer et modifier, mais il ne doit pas pouvoir tout executer sans controle.

Pour commencer par le concept, lisez le guide du harness engineering. Pour les erreurs concretes, voyez aussi les cas d’echec securite de Claude Code.

User request
  |
  v
Agent
  |
  v
[1] Policy layer       Autoriser, demander, refuser
[2] Plan layer         Definir l'ordre des etapes
[3] Verification layer Prouver que le resultat fonctionne
[4] Recovery layer     Revenir en arriere si necessaire
  |
  v
Files / shell / SaaS APIs / deploy

La documentation de Claude Code couvre les settings, permissions, hooks et MCP. Les pages Claude Code settings, Hooks reference et MCP sont de bons points de depart.

Exemple : publier un article

Publier un article n’est pas une action unique.

1. Lire les statistiques des 7 derniers jours
2. Choisir un sujet proche d'un cluster qui progresse
3. Verifier les articles existants
4. Ecrire l'article source
5. Creer toutes les versions linguistiques
6. Valider le frontmatter, le slug et les liens
7. Construire le site
8. Verifier l'URL publique
9. Commit et push

Sans plan explicite, l’agent risque de terminer la partie visible et d’oublier les etapes ennuyeuses. Le Plan layer rend ces etapes obligatoires.

SaaS : separer lecture, generation et envoi

Pour un agent qui cherche des entreprises et prepare des emails, la limite doit etre claire.

Operation	Automatique	Raison
Lire des pages publiques	Oui	Faible impact
Enregistrer un CSV local	Oui	Verifiable
Generer une page exemple	Oui	Revisable avant publication
Rediger un email	Oui	Pas encore envoye
Envoyer l’email	Approbation	Action externe difficile a annuler

La lecture et la redaction peuvent etre automatisees. Le deploiement, l’envoi et les modifications de production doivent demander une validation.

Policy layer : allow, ask, deny

Une politique simple suffit pour commencer.

{
  "allowCommands": [
    "npm run build",
    "npm run test",
    "node scripts/content-trend-report.mjs"
  ],
  "askCommands": [
    "git push",
    "wrangler pages deploy",
    "node scripts/outreach-send-mails.mjs --send"
  ],
  "denyCommands": [
    "rm -rf",
    "git reset --hard",
    "curl * | sh",
    "npm publish"
  ],
  "protectedPaths": [
    ".env",
    ".env.local",
    "claudecode-lab-sheets-f54fc47c68f0.json"
  ]
}

Avec Claude Code, la configuration projet peut porter la meme intention.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./claudecode-lab-sheets-f54fc47c68f0.json)"
    ]
  }
}

Une bonne regle est concrete. Il faut bloquer les fichiers secrets, les commandes destructrices et les actions externes.

Verification layer : transformer le succes en commandes

“Verifie bien” n’est pas suffisant. Un script peut verifier l’URL publique et les tags essentiels.

const url = process.argv[2];
const response = await fetch(url, { redirect: "follow" });

if (!response.ok) {
  throw new Error(`Page returned ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["adsense", /ca-pub-2125588229998303/i],
  ["analytics", /G-3YR0LE68MJ/i]
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) throw new Error(`Missing ${name}`);
}

Pour les articles avec code, ajoutez Playwright afin de verifier l’affichage mobile des blocs pre, code et table.

Recovery layer : journaliser les changements

Le danger n’est pas seulement l’echec. Le danger est de ne pas savoir ce qui a ete modifie.

{
  "runId": "2026-05-19-article-001",
  "topic": "agent harness security",
  "changedFiles": [
    "site/src/content/blog/claude-code-codex-agent-harness-security.mdx"
  ],
  "commands": [
    "node scripts/content-trend-report.mjs --days 7",
    "npm run build"
  ],
  "status": "deployed"
}

Pour Git, privilegiez les retours arriere cibles.

git status --short
git diff -- site/src/content/blog/target-article.mdx
git revert <bad-commit>

Checklist de déploiement : partir du point de sortie

La première mistake n’est pas un mauvais prompt. C’est de laisser l’agent passer de la lecture à une action externe sans frontière nette. Définissez d’abord la sortie de chaque workflow.

Pour le contenu, la sortie n’est pas “l’article est rédigé”. C’est “l’URL publique répond 200, Analytics et AdSense sont encore présents, et les blocs de code tiennent sur mobile”. Pour la prospection, la sortie n’est pas “l’email est envoyé”. C’est “la liste de sociétés, la page de démonstration et le brouillon d’email sont prêts à relire”. Pour la sécurité, la sortie n’est pas “le code a changé”. C’est “le diff, les tests et le rollback sont visibles”.

use case	Automatiser d’abord	Garder une approbation
Contenu	sujet, brouillon, traduction, liens internes, build	deploy, git push, modification des tags publicitaires
Intégration SaaS	lecture seule, CSV, résumé, brouillon	envoi, suppression, facturation
Sécurité	proposition de patch, tests, note d’impact	secrets, production, élargissement des droits

Le pitfall le plus fréquent est de mélanger lecture et exécution. Lire des issues, des logs ou des pages web est utile. Mais si le même agent peut envoyer des emails, supprimer des données ou déployer en production, une instruction hostile cachée dans un document externe devient un vrai risk. Le référentiel OWASP Top 10 for LLM Applications parle de Prompt Injection et d’Excessive Agency, deux sujets directement liés aux agents de code.

Côté Claude Code, appuyez-vous sur les guides officiels security et permissions. Côté Codex, la page OpenAI code generation donne le cadre produit. Pour aller plus loin dans ClaudeCodeLab, lisez aussi les échecs de sécurité et les prompts dangereux.

Les modèles prêts à adapter sont dans /products/. Pour concevoir les permissions, la CI, la revue et le déploiement avec votre équipe, /training/ est le meilleur point d’entrée.

Conclusion

La qualite d’un agent ne vient pas seulement du prompt. En production, elle vient du cadre.

• Policy : ce qui est autorise, demande ou bloque
• Plan : ce qui va se passer avant execution
• Verification : la preuve que le resultat fonctionne
• Recovery : la maniere de reparer un echec

Claude Code et Codex sont differents, mais le principe est identique : donner a l’agent un chemin de travail utile et sur, pas une liberte illimitee.