---
name: agent-security-hardener
description: Sécurisation d'agents IA contre injections, abus et fuites de données. Se déclenche avec "sécurité agent", "agent security", "prompt injection", "jailbreak", "agent abuse", "guardrails", "safe agent", "sécuriser mon agent", "agent en production sécurisé".
---

# Agent Security Hardener

## Quand utiliser ce skill

Utilise ce skill lorsque l'utilisateur veut sécuriser un agent IA avant ou après son déploiement en production. S'applique pour contrer les attaques par injection de prompt, prévenir les fuites de données, limiter les abus d'outils, ou mettre en conformité l'agent avec des exigences réglementaires (GDPR, SOC2, HIPAA). Pertinent dès qu'un agent est exposé à des inputs utilisateurs non fiables.

## Workflow

1. **Threat model** — Cartographier les menaces avant de les mitiger :
   - **Prompt injection** : l'utilisateur (ou une source externe) tente de modifier les instructions
   - **Data exfiltration** : l'agent est manipulé pour révéler des données sensibles ou son system prompt
   - **Tool abuse** : utilisation malveillante des outils (supprimer des fichiers, envoyer des emails, SQL injection)
   - **Cost attacks** : requêtes conçues pour maximiser la consommation de tokens (DoS économique)
   - **Social engineering** : manipulation progressive du contexte de conversation

2. **Input sanitization** — Filtrer et valider chaque input avant traitement :
   - Injection detection : détecter les patterns suspects (`"ignore previous instructions"`, `"DAN"`, balises XML)
   - Input filtering : supprimer ou échapper les caractères de contrôle, les délimiteurs de prompt
   - Length limits : limiter la taille des inputs (ex : max 4000 chars pour un message utilisateur)
   - Format validation : valider le schéma des inputs structurés (JSON, formulaires) avec Pydantic
   ```python
   INJECTION_PATTERNS = [r"ignore.*instructions", r"system prompt", r"jailbreak"]
   def is_safe_input(text: str) -> bool:
       return not any(re.search(p, text, re.IGNORECASE) for p in INJECTION_PATTERNS)
   ```

3. **System prompt protection** — Protéger les instructions du système :
   - Ne jamais révéler le contenu du system prompt, même si l'utilisateur le demande explicitement
   - Instruction hierarchy claire : les instructions système priment toujours sur les instructions utilisateur
   - Délimiteurs robustes : utiliser des balises XML (`<system>`, `<user>`) pour séparer les sections
   - Tester activement la résistance : vérifier que l'agent répond "Je ne peux pas partager ça" aux tentatives d'extraction

4. **Output validation** — Inspecter chaque réponse avant de la renvoyer :
   - Content filtering : détecter et bloquer les outputs contenant des contenus prohibés
   - PII detection : identifier et masquer automatiquement emails, téléphones, numéros de carte
   - Format validation : vérifier que l'output respecte le schéma attendu (JSON valide, format correct)
   - Safety classification : passer l'output par un classificateur de sécurité avant envoi
   - Utiliser des bibliothèques : `presidio-analyzer` (Microsoft) pour la détection de PII

5. **Tool access control** — Limiter et contrôler l'usage des outils :
   - Permission scoping : chaque agent n'a accès qu'aux outils strictement nécessaires (principe du moindre privilège)
   - Allowlists : lister explicitement les opérations autorisées (lecture seule vs lecture/écriture)
   - Rate limiting par tool : max N appels par minute par outil par utilisateur
   - Sandboxing : exécuter les outils dangereux (code, shell) dans un environnement isolé (Docker, gVisor)
   - Confirmation pour les actions irréversibles : demander validation avant delete, send, publish

6. **Guardrails** — Couche de sécurité applicative :
   - **NeMo Guardrails** (NVIDIA) : rails déclaratifs en Colang, bloque les topics interdits
   - **Guardrails AI** : validators Python composables, input/output guardrails
   - **Custom validators** : fonctions de validation métier spécifiques à l'application
   - **Content policies** : définir explicitement ce que l'agent peut et ne peut pas faire (policy document)
   - Tester les guardrails avec un jeu de cas adversariaux avant la mise en production

7. **Data protection** — Protéger les données personnelles et sensibles :
   - PII masking in logs : ne jamais logger les données brutes, anonymiser avant stockage
   - Encryption at rest : chiffrer les conversations stockées (AES-256), les clés API, les secrets
   - Data retention policies : définir des durées de rétention, supprimer automatiquement après expiration
   - GDPR compliance : droit à l'effacement (supprimer les conversations d'un utilisateur sur demande)
   - Minimisation des données : collecter et traiter uniquement les données strictement nécessaires

8. **Rate limiting et anti-abuse** — Prévenir les abus à grande échelle :
   - Per-user rate limits : max N requêtes / minute / heure / jour par utilisateur authentifié
   - Cost caps : plafond de dépense par utilisateur (stopper si dépassement)
   - Anomaly detection : détecter les patterns inhabituels (burst de requêtes, inputs répétitifs)
   - IP blocking / CAPTCHA : pour les endpoints publics non authentifiés
   - Authentification obligatoire : ne jamais exposer un agent puissant sans authentification

9. **Audit et compliance** — Traçabilité et conformité réglementaire :
   - Audit trail complet : logger toutes les actions de l'agent avec timestamp, user_id, action, résultat
   - Decision logging : expliquer pourquoi l'agent a pris une décision (explainability)
   - Regulatory requirements : adapter les contrôles selon le secteur (HIPAA santé, PCI finance, GDPR EU)
   - Audit log immutability : stocker les logs dans un système tamper-proof (AWS CloudTrail, Azure Monitor)
   - Rapport de conformité : générer des rapports d'audit périodiques pour les équipes sécurité

10. **Red teaming** — Tester activement la robustesse de l'agent :
    - Adversarial testing : tenter manuellement les injections, jailbreaks, et extractions de données
    - Automated red teaming : utiliser des outils comme `garak`, `PyRIT` (Microsoft) pour les tests automatisés
    - Boundary testing : vérifier le comportement de l'agent aux limites (inputs vides, très longs, mal formés)
    - Bug bounty : si l'agent est public, envisager un programme de récompense pour les vulnérabilités signalées
    - Itérer : red teaming continu après chaque mise à jour majeure du prompt ou des outils

## Règles

- Fournis des exemples de code et configuration concrets pour chaque contrôle de sécurité recommandé.
- Priorise la sécurité et la fiabilité : appliquer le principe de défense en profondeur (plusieurs couches de contrôles).
- Documente les pièges courants : faux sentiment de sécurité avec un seul guardrail, inputs encodés qui contournent les filtres basiques, prompt injection via des sources de données externes (web, fichiers).
- Adapte les recommandations au niveau de risque réel de l'application (agent interne vs public, données sensibles ou non).
- Ne jamais sacrifier l'utilisabilité au point de rendre l'agent inutilisable — calibrer les guardrails avec des tests sur des cas d'usage légitimes.


## Communication Rules — MANDATORY

- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.