RBAC pour les agents IA : contrôle d'accès par rôles sans privilèges excessifs

Idée en 30 secondes

RBAC (Role-Based Access Control) pour un agent IA définit qui peut exécuter quelles actions via tools en runtime.

Quand c'est nécessaire : quand l'agent travaille avec plusieurs rôles, plusieurs tenants, ou a accès à des actions write dans des systèmes réels.

Problème

Sans RBAC, un agent démarre souvent avec un accès "large" : un rôle, beaucoup d'outils, peu de frontières. En demo, cela semble pratique. En production, cela devient vite une source d'incidents.

Une seule erreur dans le plan de l'agent peut déclencher une action en trop : mauvais tool, mauvais tenant, mauvais niveau d'accès. Après cela, il est difficile de répondre même à une question basique : qui a obtenu l'accès et pourquoi. Pour éviter que cette erreur devienne un incident, le contrôle d'accès doit vivre non pas dans le prompt, mais dans la couche de policy avant chaque appel d'outil.

Analogie : c'est comme un badge universel dans un immeuble de bureaux. Tant que tout est calme, la différence est invisible. Au moment d'une panne, ce badge ouvre trop de portes.

Solution

La solution est de déplacer le contrôle d'accès dans la couche de policy du runtime. Chaque appel d'outil est vérifié via user context (role, permissions et tenant scope) avant exécution. Commence par une règle de base : default deny et autorisations explicites seulement pour les rôles nécessaires.

RBAC != simple allowlist

Allowlist définit quels tools existent dans le système.
RBAC définit qui peut les appeler et quand.

L'un sans l'autre ne fonctionne pas :

• sans RBAC, les frontières d'accès entre rôles deviennent floues
• sans allowlist, le set de tools grandit sans contrôle

Exemple :

• allowlist : l'outil refund.create existe et est disponible dans le système
• RBAC : seul le rôle billing_manager peut appeler refund.create dans son propre tenant

Niveaux de contrôle d'accès (RBAC layers)

Ces vérifications fonctionnent ensemble à chaque étape de l'agent.

Comment cela se place dans l'architecture

La couche de policy (tool gateway) se place entre runtime et tools et vérifie chaque appel. Chaque décision (allow, deny, approval_required) est enregistrée dans l'audit log.

Flow : de la requête à la décision

Chaque appel d'outil passe par ce flow avant exécution : runtime n'exécute pas d'action directement et délègue la décision à la couche de policy.

Résumé du flow :

• Runtime forme une tool request
• la couche de policy RBAC vérifie rôle et tenant scope
• allow -> appel d'outil exécuté
• deny -> stop reason + enregistrement dans audit log
• approval_required -> stop reason + enregistrement dans audit log

Décisions de policy

Chaque appel d'outil se termine par une des décisions suivantes :

• allow — l'action est exécutée
• deny — l'action est interdite
• approval_required — une confirmation est requise

C'est un point centralisé par lequel passent toutes les décisions avant l'exécution d'une action. Ces décisions sont utilisées comme raisons d'arrêt et journalisées dans l'audit log.

Exemple

Un agent support (role = support_agent) reçoit une demande de remboursement. L'outil refund.create est autorisé uniquement pour le rôle billing_manager dans son propre tenant.

Résultat :

• support_agent -> refund.create -> deny("permission_denied")
• role mismatch ou tenant scope mismatch -> deny("permission_denied")
• événement écrit dans l'audit log avec la raison du refus

RBAC arrête l'erreur au niveau exécution en vérifiant l'accès avant chaque action.

Dans le code, cela ressemble à ceci

decision = rbac.check(user_context, tool, tenant_id, args)
if not decision.allowed:
    audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason)
    return deny(decision.reason)

if decision.requires_approval and not approval.ok():
    audit.log(user_context, tool, tenant_id, "approval_required", reason="approval_required")
    return stop("approval_required")

result = tool.execute(args)
audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason, result=result)
return result

Comment cela se passe pendant l'exécution

Scénario 1 : accès refusé (deny)

Requête : l'utilisateur demande un refund
Runtime : appel d'outil formé -> refund.create
Policy : vérification role + tenant scope + permissions
Decision : deny (permission_denied)
Audit : decision=deny, role=support_agent, action=refund.create, reason=permission_denied
Stop : action non exécutée

---

Scénario 2 : accès autorisé (allow)

Requête : même cas pour billing_manager dans son tenant
Runtime : appel d'outil formé -> refund.create
Policy : vérification role + tenant scope + permissions
Decision : allow
Tool : refund.create exécuté
Audit : decision=allow, role=billing_manager, action=refund.create, result=ok
Return : résultat renvoyé au client

Erreurs fréquentes

• un rôle "service" unique pour tous les agents et utilisateurs
• absence de allowlist default-deny
• vérification seulement du rôle, sans tenant scope
• absence de couche de policy centralisée
• mêmes droits pour actions read et write
• logique RBAC uniquement dans UI ou prompt
• audit trail absent : role, action, tenant, policy decision reason

Résultat : le système semble contrôlé, mais les frontières d'accès se dégradent avec le temps.

Auto-vérification

Vérification rapide RBAC avant lancement en production :

FAQ

Q: Comment gérer les tools qui appellent GitHub, Jira ou d'autres APIs externes ?
A: Ne donne pas à l'agent une clé partagée unique pour tout. Préfère user-scoped credentials, tokens OAuth, ou policy de service account séparée avec limites explicites.

Q: Quelle différence entre role et tenant scope ?
A: Role définit ce qu'on peut faire. Tenant scope définit où on peut le faire.

Q: Comment ajouter un nouveau tool dans RBAC en sécurité ?
A: Ajoute-le via un modèle explicite de permissions : default deny, droits read/write séparés, et vérification tenant scope.

Q: Que faut-il implémenter en premier : RBAC ou approval ?
A: Commence par RBAC avec default deny et tenant scope. Ensuite ajoute approval pour les actions write risquées.

Q: RBAC seul suffit-il pour la production ?
A: Non. Il faut aussi execution limits, budgets, audit logs et kill switch.

Où RBAC se place dans le système global

RBAC est une des couches d'Agent Governance.
Avec budgets, limites, approval et audit, il forme un système unifié de contrôle d'exécution.

Pages liées

Pour continuer :

• Vue d'ensemble Agent Governance — modèle global de contrôle des agents en production.
• Allowlist vs Blocklist — pourquoi default-deny passe mieux à l'échelle.
• Human Approval — comment ajouter une validation manuelle pour actions risquées.
• Audit logs pour agents — comment reconstruire la chaîne de décisions en incident.
• Kill Switch — comment arrêter un agent en urgence sans release.