Allowlist vs Blocklist pour les agents IA : pourquoi le default deny est plus sûr

L'idée en 30 secondes

Allowlist en runtime définit quels outils l'agent peut appeler. Blocklist interdit seulement une partie des outils d'un ensemble déjà large.

Quand c'est nécessaire : quand un agent a accès à de vraies API, à des actions d'écriture ou reçoit régulièrement de nouveaux tools en production.

Le problème

Beaucoup d'équipes commencent par une blocklist : « on interdit les outils dangereux ». Au début, cela paraît rapide et pratique. En production, ce modèle casse vite.

La raison est simple : chaque nouvel outil devient automatiquement disponible s'il n'est pas explicitement bloqué. Donc l'accès augmente par défaut, pas par décision explicite.

Analogie : c'est comme un bureau sans liste des portes autorisées, mais avec une liste « ne pas entrer ici ». Dès qu'une nouvelle pièce apparaît, elle est ouverte à tout le monde jusqu'à ce que quelqu'un pense à la bloquer.

La solution

La solution consiste à poser default deny dans le policy layer et à autoriser les tools uniquement via une allowlist. La blocklist reste un frein d'urgence supplémentaire pour le mode incident, pas le modèle d'accès principal.

Le policy layer renvoie une décision technique pour chaque appel : allow, deny ou approval_required. Cette décision est prise à chaque étape, pas seulement à la fin du run. C'est une couche système séparée, pas une partie du prompt ni de la logique du modèle.

Allowlist ≠ Blocklist

Ce sont deux approches de contrôle différentes :

Allowlist : seul ce qui est explicitement ajouté à la policy est autorisé.
Blocklist : tout est autorisé, sauf ce qui est explicitement interdit.

L'un sans l'autre ne suffit pas :

sans allowlist, les accès s'élargissent entre les releases presque sans visibilité
sans blocklist, il est plus difficile de désactiver rapidement un tool précis pendant un incident

Exemple :

allowlist : search.read, kb.read, refund.lookup
incident blocklist : interdire temporairement browser.run à cause d'un vendor instable

Métriques de contrôle d'accès aux tools

Ces métriques et signaux fonctionnent ensemble à chaque étape de l'agent.

Métrique	Ce qu'elle contrôle	Mécaniques clés	Pourquoi
Default deny	Règle d'accès de base	`default = deny` deny by default	Un nouveau tool ne devient pas disponible automatiquement
Allowlist	Quels tools sont autorisés	noms de tools explicites capability scoping	Fixe des limites explicites pour l'exécution runtime
Incident blocklist	Blocages d'urgence temporaires	incident mode deny list time-bound rules	Permet de réduire vite le risque sans release
Write escalation	Actions d'écriture risquées	`approval_required` separate write policy	Évite les actions irréversibles sans contrôle
Policy observability	Visibilité sur les décisions de policy	audit logs alerts on deny spikes	Ne limite pas directement les actions, mais montre où et pourquoi l'accès est bloqué

À quoi cela ressemble dans l'architecture

Le policy layer (tool gateway) se place entre le runtime et les tools, et constitue le point de contrôle d'accès unique avant chaque étape. Chaque décision (allow, deny, approval_required) est enregistrée dans l'audit log.

Chaque étape de l'agent passe par ce flow avant exécution : le runtime n'exécute pas l'action directement. Il y a d'abord un contrôle policy, puis l'exécution. Pour les actions d'écriture, la policy peut renvoyer approval_required : c'est un flow de confirmation séparé qui n'est pas montré dans ce diagramme (voir Human approval).

Résumé du flow :

Le runtime prépare le tool call
Le policy layer applique default deny, puis allowlist et incident blocklist
allow -> le tool call est exécuté
deny -> un stop reason est renvoyé
chaque décision est écrite dans l'audit log

Dans le runtime, deny est transformé en stop reason explicite, visible dans les logs et dans la réponse du run.

Exemple

Un agent de support reçoit une demande de fermeture en masse de tickets. Le tool ticket.close_bulk n'est pas dans l'allowlist, donc l'appel est immédiatement bloqué.

Pendant un incident séparé, l'équipe ajoute browser.run à l'incident blocklist. Même si ce tool est dans l'allowlist, le policy layer renvoie temporairement deny("incident_deny").

L'allowlist limite l'accès de base, et la blocklist fournit un contrôle d'urgence rapide.

En code, ça ressemble à ça

Dans le schéma simplifié ci-dessus, on voit le control flow principal. En pratique, la vérification est exécutée à un seul endroit : le policy layer avant chaque étape.

Exemple de configuration allowlist :

YAML

policy:
  default: deny
  allowlist:
    - search.read
    - kb.read
    - refund.lookup
incident_blocklist:
  - browser.run

PYTHON

decision = policy.evaluate(tool, user_context, mode="normal")

if decision.outcome == "approval_required":
    if not approval.ok():
        audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool)
        return stop(decision.reason)
    else:
        audit.log(run_id, "approval_granted", reason="human_approved", tool=tool)

elif decision.outcome == "deny":
    audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool)
    alerts.notify_if_needed(run_id, decision.reason, tool=tool)
    return deny(decision.reason)

result = tool.execute(args)
decision = Decision.allow(reason="policy_ok")
audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool, result=result.status)
return result

À quoi ça ressemble pendant l'exécution

TEXT

Scénario 1 : tool absent de l'allowlist (deny)

1. Le runtime prépare un appel ticket.close_bulk.
2. Le policy layer vérifie l'allowlist.
3. Décision : deny (tool_not_allowed).
4. Audit : decision=deny, tool=ticket.close_bulk, reason=tool_not_allowed.
5. L'action n'est pas exécutée.

---

Scénario 2 : blocage incident (incident_deny)

1. Le runtime prépare un appel browser.run.
2. Le tool est dans l'allowlist, mais le mode incident est actif.
3. Le policy layer vérifie la blocklist et renvoie deny (incident_deny).
4. Audit : decision=deny, tool=browser.run, reason=incident_deny.
5. Le run s'arrête sans appel d'outil.

---

Scénario 3 : appel autorisé (allow)

1. Le runtime prépare un appel kb.read.
2. Le policy layer vérifie les règles : allow.
3. Le tool est exécuté.
4. Audit : decision=allow, tool=kb.read, result=ok.
5. Le résultat est renvoyé au runtime.

Erreurs courantes

faire de la blocklist le modèle d'accès principal
ne pas utiliser default deny pour les nouveaux tools
autoriser des wildcards comme * sans limites strictes
conserver des tools « universels » comme workflow.run_anything
logger seulement allow, sans logger deny/approval_required
vérifier l'accès dans le prompt ou l'UI au lieu du policy layer

Résultat : l'accès semble contrôlé, mais en réalité il s'élargit à chaque release.

Auto-vérification

Vérification rapide de la policy allowlist avant lancement en production :

Il y a un default deny : un nouveau tool n'est pas autorisé automatiquement
Il y a une allowlist explicite avec des noms de tools concrets
La blocklist est utilisée uniquement en mode incident
Les actions d'écriture ont une policy séparée et (si nécessaire) un approval
Chaque étape (tool call) passe par un policy layer centralisé
Chaque décision de policy a un outcome et un reason explicites
Tous les deny et approval_required sont écrits dans l'audit log
Il y a de l'alerting sur les pics de décisions deny

Progression: 0/8

⚠ Les contrôles de governance de base manquent

Avant la production, il faut au minimum le contrôle d'accès, des limites, des audit logs et un arrêt d'urgence.

FAQ

Q : Peut-on faire de la production avec seulement une blocklist ?
A : En production, non. La blocklist est utile comme mécanisme d'urgence, mais le modèle de base doit être default deny + allowlist.

Q : Par où commencer pour une allowlist ?
A : Commence par un ensemble minimal de tools read-only. Ajoute les actions d'écriture séparément, avec conditions explicites et approval.

Q : Une allowlist wildcard (crm.*), c'est acceptable ?
A : Seulement dans des cas limités avec revue régulière. Sinon, les wildcards deviennent vite un default-allow caché. Par exemple, crm.* autorisera crm.delete_all_contacts si ce tool apparaît dans la prochaine release.

Q : Où implémenter ces vérifications ?
A : Dans un policy layer centralisé (tool gateway), pas dans le prompt ni dans la logique UI.

Q : Que faire s'il faut désactiver un tool en urgence ?
A : Ajoute-le à l'incident blocklist, consigne la raison dans l'audit log, puis reviens à la policy allowlist permanente.

Où cela se place dans le système global

Allowlist/blocklist est une des couches de l'Agent Governance. Avec RBAC, les budgets, l'approval et l'audit, cela forme un système unifié de contrôle d'exécution.

Pages liées

Suite du sujet :

Vue d'ensemble Agent Governance — modèle global de contrôle des agents en production.
Contrôle d'accès (RBAC) — comment combiner rôles, permissions et tenant scope.
Contrôle des budgets — comment limiter les coûts de run au niveau runtime.
Human approval — comment ajouter une confirmation pour les actions risquées.
Audit logs pour agents — comment analyser les décisions de policy pendant les incidents.