Concevoir des workflows d'agents pour limiter les injections de prompt et les risques d'ingénierie sociale

TL;DR en langage simple

• Les agents d'IA qui naviguent et prennent des actions peuvent recevoir des instructions cachées dans des pages web ou des e‑mails. Voir : https://openai.com/index/designing-agents-to-resist-prompt-injection
• Les attaques ressemblent souvent à de l'ingénierie sociale. Elles cherchent à convaincre plutôt qu'à forcer un mot-clé.
• Défense pratique : contraindre l'impact plutôt que compter seulement sur le filtrage. Limitez les capacités, demandez une confirmation humaine pour les actions sensibles, et enregistrez la provenance de chaque source.
• Exemples rapides : canary (1% d'utilisateurs) pendant 48–72 h, timeout de confirmation 120 s, rétention logs 90 jours, seuil confiance 0.3.

Checklist express (2 minutes) :

• [ ] Listez 3–5 actifs sensibles (comptes, paiements, PII).
• [ ] Ajoutez capability-permissions.json et protégez la branche.
• [ ] Enregistrez provenance (URL, headers, timestamp, hash) pour chaque fetch.
• [ ] Exigez confirmation humaine pour actions touchant PII, identifiants ou paiements.
• [ ] Lancez un canary 1 % pendant 48–72 h et surveillez.

Concrete example (court) :

• Scénario : l'agent récupère une page web contenant une "instruction" disant d'envoyer un e‑mail. La chaîne ne doit pas déclencher l'envoi. L'agent doit extraire l'intention, noter la source, calculer un score de confiance, puis demander confirmation avant d'envoyer.

Plain-language explanation before advanced details:

• En clair : ne laissez pas une seule page web décider d'une action sensible. Traitez chaque entrée comme suspecte. Vérifiez d'où elle vient et demandez une validation humaine avant d'agir si l'impact est élevé.

Ce que vous allez construire et pourquoi c'est utile

Vous allez construire un workflow simple en quatre étapes : fetch → extraction d'intention structurée → décision (policy) → exécution contrôlée. L'idée est d'empêcher qu'une instruction cachée déclenche immédiatement une opération à fort impact. Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Artifacts produits :

• capability-permissions.json : mappe chaque outil à allow | confirm | deny.
• Logs de provenance : URL, headers, timestamp, hash, score 0.0–1.0.
• Table de décision qui combine intention, score et permissions.
• Piste d'audit pour chaque action (qui / quand / pourquoi).

Table de décision (exemple simple)

| Score de provenance | Intention (extrait) | Action recommandée | |---------------------:|--------------------------------------|--------------------:| | 0.00–0.29 | intention sensible ou incertaine | block | | 0.30–0.59 | suggestion non critique | confirm | | 0.60–1.00 | info publique non sensible | allow |

Cette séparation réduit le pouvoir d'une injection. Même si une entrée est manipulée, elle ne peut pas directement exécuter une action sensible.

Avant de commencer (temps, cout, prerequis)

Lisez la note centrale : https://openai.com/index/designing-agents-to-resist-prompt-injection

Prérequis et estimations :

• LLM (large language model) ou extracteur d'intention intégré. Budget test suggéré : ~8��192 tokens par session.
• Couche d'interception pour appliquer permissions et journaliser appels d'outils.
• Stockage pour métadonnées de provenance ; rétention recommandée : 90 jours.
• Interface pour confirmations humaines (UI, CLI ou intégration Slack) ; timeout par défaut : 120 s.

Temps & coûts indicatifs :

• Effort dev : 40–120 heures selon l'infra existante.
• Canary : 48–72 heures.
• Corpus red-team initial : 5–20 cas adversariaux.
• Coût tokens indicatif : ex. $0.02 par 1��000 tokens (ajuster selon fournisseur).

Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Installation et implementation pas a pas

1. Rédigez une page de menace listant 3–5 actifs principaux.
2. Créez capability-permissions.json et protégez la branche par revue.
3. Capturez la provenance : pour chaque fetch enregistrez URL, headers, timestamp et hash. Calculez un score de provenance 0.0–1.0.
4. Faites extraire l'intention en JSON structuré ; l'extracteur ne doit appeler aucun outil externe pendant l'analyse.
5. Implémentez la couche de décision qui lit intention + score + permissions et retourne allow / confirm / block.
6. Exigez confirmations auditables pour actions marquées confirm (timeout 120 s).
7. Construisez 5–20 cas adversariaux et exécutez-les en CI avant canary.
8. Lancez un canary (1 % ou groupe nommé) pendant 48–72 h et surveillez blocked_action_rate, suspicious_provenance_rate, mean_time_to_investigate.

Exemple capability-permissions.json :

{
  "web_fetch": "allow",
  "calendar_create": "confirm",
  "send_email": "confirm",
  "access_credentials": "deny",
  "file_upload": "deny"
}

Commandes exemples (activer canary + tail logs) :

# enable a 1% canary group (example)
curl -X POST https://featureflags.example/flags/agent_canary/enable \
  -d '{"group":"canary","percent":1}'

# tail audit logs and show actions
tail -f /var/log/agent/audit.log | jq '.action, .decision'

Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Problemes frequents et correctifs rapides

• Problème : l'agent bloque des workflows utiles.

  • Correctif : passez de deny à confirm pour l'action concernée ; améliorez l'UI de confirmation. Objectif : <1 % d'événements "bloqué mais nécessaire" pendant le canary.

• Problème : l'ingénierie sociale contourne les filtres littéraux.

  • Correctif : fiez-vous à la provenance et à la table de décision ; ajoutez exemples adversariaux dans le CI.

• Problème : fuite de données dans fichiers temporaires.

  • Correctif : sandboxez les écritures, refusez l'accès aux stores de secrets depuis le sandbox, supprimez l'état temporaire en <30 s.

• Problème : trop d'alertes (fatigue).

  • Correctif : regroupez alertes par sévérité, appliquez une moyenne glissante sur 5 minutes, traitez d'abord les 1–2 types d'alerte majeurs.

Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Premier cas d'usage pour une petite equipe

Scénario : une personne seule ou une équipe de 2–3 construit un assistant qui suggère des horaires et récupère des contacts publics sans envoyer d'invitations automatiques ni exfiltrer de PII (données personnelles identifiables). Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Conseils concrets pour solo founders / petites équipes :

1. Permissions minimales immédiates (30–60 minutes)

• Créez capability-permissions.json avec valeurs par défaut strictes : calendar_create = confirm, send_email = confirm, access_credentials = deny. Protégez la branche.
• Action : commit + protection de branche en 30–60 min.

2. Confirmation humaine simple (0.5 journée)

• Pour actions sensibles, implémentez une confirmation via CLI ou Slack bot. Affichez l'intention, score et source (URL, timestamp).
• Action : bouton/commande approve dans 120 s, sinon timeout = refuse.

3. Provenance légère et journaux (1–2 jours)

• Enregistrez URL, timestamp, headers et hash dans un fichier chiffré. Rétention 90 jours.
• Action : écrire un logger qui persiste 1 entrée par fetch.

4. Tests red-team rapides (1–3 jours)

• Construisez 5–10 cas d'ingénierie sociale simples ; exécutez-les en local et ajoutez aux tests CI.
• Action : automatiser 10 cas et exécuter avant chaque release.

5. Canary minimal (48–72 h)

• Lancez canary 1 % des utilisateurs ou un groupe nommé pendant 48–72 heures. Déclencheur rollback : >=1 alerte haute sévérité OU >1 % d'événements bloqué‑mais‑nécessaire.
• Action : script de rollback prêt (<5 minutes pour exécution).

Checklist rapide pour solo :

• [ ] capability-permissions.json en place
• [ ] Confirmation CLI/Slack implémentée (timeout 120 s)
• [ ] Logger provenance activé (rétention 90 jours)
• [ ] 5–10 tests red-team ajoutés au CI
• [ ] Canary 1 % planifié pour 48–72 h

Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Notes techniques (optionnel)

Résumé court : la provenance est un signal de confiance. Le sandbox empêche l'accès aux secrets. Les métriques alertent si le comportement change. Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Conseils et seuils utiles :

• Score de provenance : 0.0–1.0 ; traiter <0.3 comme faible confiance.
• Freshness threshold : freshness_ms_threshold = 60��000 ms (60 s).
• Latence cible décision : médiane 500 ms.
• Suppression état temporaire : <30 s.

Exemple YAML de configuration (seuils et retention) :

provenance:
  retention_days: 90
  low_trust_threshold: 0.3
  freshness_ms_threshold: 60000
decision:
  confirmation_timeout_s: 120
  latency_target_ms: 500

Commande pour lancer les tests red-team localement :

# run red-team tests (5-20 cases) locally
python -m tests.run_redteam --cases 10 --log results.json

Source : https://openai.com/index/designing-agents-to-resist-prompt-injection

Que faire ensuite (checklist production)

Hypotheses / inconnues

• Taille du groupe canary : 1 % des utilisateurs ou groupe nommé (hypothèse).
• Durée du canary : 72 heures (option petite équipe : 48 heures).
• Déclencheur de rollback : toute alerte haute sévérité >= 1 pendant la fenêtre canary.
• Seuil secondaire : <1 % d'événements bloqué‑mais‑nécessaire (objectif).
• Taille du corpus red-team initial : 5–20 cas.
• Échelle du score de provenance : 0.0–1.0 ; considérer <0.3 comme faible confiance.
• Timeout de confirmation : 120 secondes.
• Budget tokens pour tests : suggestion 8��192 tokens par session.
• Latence cible pour étape décision : médiane 500 ms.
• Rétention logs : 90 jours.

Risques / mitigations

• Risque : politiques trop permissives laissent agir une instruction injectée.

  • Mitigation : défaut = deny ou confirm pour actions sensibles ; loggez chaque décision avec provenance.

• Risque : sur‑blocage perturbe workflows critiques.

  • Mitigation : préférez confirm à deny quand raisonnable ; objectif <1 % d'événements bloqué‑mais‑nécessaire pendant le canary.

• Risque : télémétrie insuffisante ralentit la réponse.

  • Mitigation : capturez provenance, décision et snapshots ; gardez logs interrogeables 90 jours.

• Risque : corpus red-team obsolète face à l'évolution des attaques.

  • Mitigation : mettez à jour les cas trimestriellement et exécutez-les à chaque release.

Prochaines etapes

• [ ] Ajouter capability-permissions.json au repo et exiger une revue via protection de branche.
• [ ] Instrumenter et persister headers et métadonnées de provenance pour toutes les fetchs externes (rétention 90 jours).
• [ ] Construire un corpus red-team initial de 5–20 cas et l'exécuter dans CI.
• [ ] Démarrer un canary de 1 % pendant 72 heures ; surveiller blocked_action_rate, suspicious_provenance_rate, mean_time_to_investigate.
• [ ] Être prêt à rollback sur toute alerte haute sévérité (>=1) pendant le canary.

Rappel : comme les attaques d'injection de prompt prennent souvent la forme d'ingénierie sociale, privilégiez une architecture qui contraint l'impact — une seule entrée manipulée ne doit pas pouvoir entraîner une action à fort impact (https://openai.com/index/designing-agents-to-resist-prompt-injection).

Concevoir des workflows d'agents pour limiter les injections de prompt et les risques d'ingénierie sociale

Construisez des workflows d'agents qui séparent récupération, extraction d'intention, décision et action ; enregistrez la provenance, gérez les permissions des…

https://aisignals.dev/fr/posts/2026-03-29-designing-agent-workflows-to-limit-prompt-injection-and-socialengineering-risks

(Chaque semaine: actus IA, patterns d'agents, tutoriels)