⚡ Agentic AI : Stratégies de Mitigation (2.3/4)

Les stratégies de mitigation définissent comment réagir aux différentes situations détectées par les guardrails. Une approche adaptative et contextuelle est essentielle pour maintenir l’équilibre entre sécurité et utilisabilité.

Actions de Mitigation Disponibles ⚡

Détails et exemples par action

if detector.is_severe(hit):
    mitigation.raise_exception(code=403, reason="policy-violation", context=ctx)
    audit.log_event(detector=hit.src, severity="critical")

const masked = text.replace(/\b(SSN|\d{3}-\d{2}-\d{4})\b/g, '[REDACTED]')

SYSTEM: Tu dois répondre en JSON strict valide avec les clés: topic, risks, summary.
USER: 
GUARDRAIL: Si la réponse initiale ne respecte pas le format, régénère avec structure JSON correcte sans ajout hors-schéma.

def fix(payload):
    before = hash_payload(payload)
    p = normalize_urls(payload)
    p = ensure_json_schema(p, schema)
    p = trim_strings(p)
    audit_diff(before, hash_payload(p))
    return p

Ordre recommandé (par coût) : filter → fix → reask → exception (sauf criticité immédiate).

Ces actions peuvent être combinées et ordonnancées (p.ex. filter → reask → fix) selon la politique définie.

Choix de la Stratégie de Mitigation

Objectif : sélectionner la séquence d’actions la plus efficace (sécurité + coût + UX) en fonction de la situation détectée.

Entrées de Décision

Heuristiques Principales

1. Si criticité ≥ seuil_critique → exception prioritaire.
2. Si contenu partiellement sûr et corrigeable → tenter filter ou fix avant tout reask.
3. Si structure attendue non respectée mais risque faible → reask (ajout de contraintes) limité par max_reasks.
4. Éviter reask si latence cumulée > budget p95 du profil.
5. Sur multi-signaux : appliquer l’action la plus restrictive des actions candidates.

Matrice Décisionnelle (Résumé)

Score Combiné (exemple)

base = criticite * 2 + (1 - confiance)
if profil == 'high': base += 2
if signal in ['secret','code_exec']: base += 3
decision = case base:
  >=7  -> exception
  5-6  -> filter/fix (si applicable) sinon reask
  <5   -> reask ou fix

Adapter pondérations via analyse rétrospective des incidents et coûts mensuels.

Pseudo-code Sélection

def choose_strategy(signal, profile, ctx):
    if signal.is_critical():
        return ['exception']
    seq = []
    if signal.is_maskable():
        seq.append('filter')
    if signal.is_structural_issue():
        seq.append('fix')
    if ctx.can_reask() and signal.needs_regeneration():
        seq.append('reask')
    # Dernière barrière
    if not seq:
        seq.append('exception')
    return dedupe(seq)

💡 Conseil : tracer (signal, profil, stratégie choisie) pour affiner la matrice de décision.

Implémentation des Stratégies

🧩 Interfaces Recommandées

Séparer strictement détection, décision et exécution pour limiter le couplage.

📦 Schéma d’un Result

{
  "handled": true,
  "action": "filter",
  "latency_ms": 18,
  "notes": "2 tokens masqués",
  "reask_suggested": false
}

Gardez ce schéma contractuel versionné — utilisez un test de régresion JSON Schema.

🛠️ Orchestration (JS)

async function mitigate(req){
  const signals = await detectors.runAll(req);
  const profile = deriveProfile(req, signals);
  const actions = chooseStrategy(signals, profile, req.ctx);
  for (const name of actions){
    const impl = registry.action(name);
    const t0 = performance.now();
    const result = await impl.execute(req, signals);
    audit.record({action:name, latency_ms:performance.now()-t0, profile});
    metrics.action_latency.observe(name, performance.now()-t0);
    if (result.handled) return result.payload;
  }
  throw new Error('Unmitigated');
}

Implémentez un timeout global et une politique de rollback si aucune action ne gère.

📈 Observabilité

• Métriques par action : latence (histogram), taux succès / échec.
• Log structuré : req_id, profile, action, policy_version, decision_path.
• Traces : span parent “mitigation” + sous-spans par action.

Ajoutez un sample payload hash pour corréler sans stocker le contenu.

⚙️ Performance & Idempotence

Exposez un compteur mitigation_chain_length pour surveiller les dérives.

✅ Tests Essentiels

Automatisez un benchmark hebdo pour détecter la dérive de latence.

⚠️ Anti-Patterns

Revue trimestrielle: supprimer actions rarely-used (<0.1%).

📊 Instrumentation (Prometheus - Python)

🚀 Checklist de Déploiement

Automatisez la checklist dans un pipeline (quality gate blocante si un point critique manque).

🗂️ Récapitulatif Métriques Clés

Définissez des SLO : ex. exception_rate (high) < 0.1%, reask_rate (medium) < 3%.

action_latency = Histogram('guardrail_action_latency_seconds', 'Latency', ['action'])
def execute_action(action, fn):
    start = time.time()
    try:
        return fn()
    finally:
        action_latency.labels(action=action).observe(time.time()-start)

Ajoutez un Counter pour les échecs et un Summary expérimental pour tail latence.

Impact des Actions 📊

Mesurer et valider l’impact

Objectif : prouver que les actions de mitigation protègent le système sans dégrader l’expérience utilisateur ni faire exploser les coûts.

Pour être opérationnel, liez chaque métrique aux labels suivants : profile, detector, model_version, region — cela permet de segmenter l’impact par cas d’usage.

Métriques recommandées

Bonnes pratiques : échantillonnez traces et payloads pour debug (safeguard PII), conservez id_corrélation pour chaque métrique afin de suivre la requête dans les logs et traces.

Seuils et targets (exemples)

Exemple de KPI minimal (récapitulatif)

• Taux d’exception critique : < 0.1% des requêtes (profil high)
• Taux de reask : < 3% (profil medium cible, adapter par cas d’usage)
• Latence p95 supplémentaire acceptée : 200ms (profil medium)