TBAC : Contrôle d'accès basé sur les tâches pour l'ère des agents

La plupart des modèles de contrôle d'accès en production reposent encore sur un acteur stable : qui fait la demande, quels attributs ou relations lui sont associés, et quels droits cela lui confère. Les rôles ont répondu à ce besoin pour l'organigramme, les attributs pour le contexte, et les relations pour les graphes sociaux. Les agents IA bouleversent cette logique : l'identité d'un agent est stable, mais son travail ne l'est pas. Il est déployé par tâche, nécessite un périmètre de permissions différent pour chaque mission, s'exécute à la vitesse de la machine et suit des instructions intégrées aux données qu'il traite. Le modèle que l'époque actuelle exige pose la question suivante : quel travail effectuez-vous en ce moment précis ? Cette question porte un nom à l'héritage ancien : le contrôle d'accès basé sur les tâches (TBAC), proposé par Thomas et Sandhu dans les années 1990 et aujourd'hui remis au goût du jour sous une forme adaptée à l'IA agentique. Cet article examine honnêtement la famille des modèles de contrôle d'accès, explique pourquoi les agents mettent chaque modèle à rude épreuve, présente le TBAC et ses formulations modernes, et fait correspondre ce résultat multicouche aux structures de passerelle qui le mettent en œuvre, en ancrant la cartographie TrueFoundry dans la documentation publique.

Ines, architecte sécurité, a reçu la demande d'examen que toutes les équipes de sécurité reçoivent cette année : approuver un agent de support capable de lire des tickets, d'interroger la base de données des commandes et d'émettre des remboursements de moins de cinquante dollars. Son instinct, forgé par vingt ans de pratique, lui a dicté de créer un rôle. Mais agent-support en tant que rôle lui a semblé inapproprié dès l'heure du déjeuner. Un rôle est provisionné une fois et décrit une fonction stable ; cet agent n'avait besoin de la permission de remboursement que pendant les tâches de remboursement, de la base de données que pour le client du ticket, et de rien entre deux exécutions. Pire encore, il conserverait les droits accordés en permanence, pour chaque instance parallèle, à la vitesse de la machine — et si un ticket malveillant lui ordonnait d'utiliser ses permissions de manière créative, il pourrait s'exécuter. Le modèle de rôle lui offrait deux mauvaises options : accorder trop de droits et accepter une exposition permanente, ou en accorder trop peu et bloquer l'agent. Elle souhaitait une troisième voie : des permissions assemblées par tâche, limitées aux objets de la tâche, actives pendant sa durée et supprimées une fois celle-ci terminée. Cette troisième voie existe, sur le papier, depuis avant même le début de sa carrière.

1. Une brève et honnête histoire des modèles BAC

Chaque génération de contrôle d'accès repose sur une hypothèse concernant l'acteur. La première distinction — le contrôle discrétionnaire (DAC), où les propriétaires de ressources accordent l'accès, par opposition au contrôle obligatoire (MAC), où une autorité centrale étiquette et valide — supposait des personnes disposant d'habilitations. Le RBAC, formalisé par Ferraiolo, Kuhn et Sandhu dans les années 1990 puis normalisé, lie les permissions aux rôles plutôt qu'aux individus : un rôle de développeur donne accès aux dépôts, un rôle de clinicien aux dossiers des patients. Son hypothèse fondamentale : les acteurs ont des fonctions professionnelles stables qui évoluent à l'échelle de l'organisation — ce qui est vrai pour les employés, et explique pourquoi le RBAC équipe encore la plupart des entreprises.

L'ABAC — le contrôle d'accès basé sur les attributs, traité de manière canonique dans la norme NIST SP 800-162 — a remplacé la recherche de rôle par une évaluation de politique basée sur les attributs du sujet, de la ressource, de l'action et de l'environnement : autoriser si département = finance et classification ≤ interne et heures de bureau. Il offre de la flexibilité au prix d'une complexité accrue dans la rédaction des politiques, et comme le notent les analyses de sécurité des agents, il évalue bien le contexte mais ne comprend pas intrinsèquement l'intention derrière une requête. ReBAC — le contrôle d'accès basé sur les relations (Relationship-Based Access Control), popularisé par le document Zanzibar de Google — déduit les autorisations à partir des relations au sein d'un graphe : vous pouvez modifier ce document parce que vous possédez le dossier parent. À cela s'ajoutent le PBAC, qui regroupe les approches basées sur des moteurs de règles, et l'accès juste-à-temps issu de la gestion des accès privilégiés — un avant-goût, dans le monde humain, de l'autorisation à durée limitée. Chacun de ces modèles répond à la question « qui êtes-vous et à quoi cela vous donne-t-il droit ? » — le tout provisionné avant même que le travail ne commence. C'est précisément cette hypothèse que les agents remettent en cause.

2. Pourquoi les agents brisent le contrôle d'accès centré sur l'identité

La tension est structurelle, et la littérature sur la sécurité des agents a convergé vers un diagnostic cohérent. Premièrement, les agents n'ont pas de fonction stable: ils sont déployés pour des tâches spécifiques, opèrent sur des périmètres de données variables, s'exécutent à la vitesse de la machine et lancent des instances parallèles — un rôle d'« agent de documentation clinique » donnant accès à un référentiel de données de santé (PHI) ne peut pas exprimer que cette instance est autorisée pour ces trois dossiers pour cette consultation, comme le souligne une analyse comparant l'ABAC et le RBAC. Deuxièmement, les agents peuvent exercer tout ce qu'ils détiennent, de manière programmatique et à grande échelle — la formulation d'Oso est la plus percutante : les employés ignorent la grande majorité de leurs autorisations, mais pas les agents. Un sur-provisionnement qui est négligeable pour les humains devient une surface d'attaque active pour une entité capable d'explorer son espace d'autorisation à la vitesse de la machine. Troisièmement, les agents peuvent être manipulés: l'injection de prompt signifie que les instructions arrivent via les données lues par l'agent ; une autorisation permanente devient donc une cible permanente — le problème du « député confus » (confused-deputy problem) avec une interface en langage naturel.

Quatrièmement, et c'est le point le moins bien compris : les chaînes de délégation brouillent la responsabilité. Les flux effectués « pour le compte de » (on-behalf-of) entraînent une escalade silencieuse — l'agent hérite de l'intégralité du périmètre de session de l'utilisateur, y compris des autorisations sans rapport avec la tâche — et les transferts entre agents transmettent l'autorité sans réévaluation. Les recommandations des experts convergent vers la liaison au contexte de la requête : chaque appel en aval doit porter l'identité de l'utilisateur à l'origine, la tâche et la décision d'autorisation, car la limite des privilèges doit passer du moment de la connexion au moment de la requête. Le coût de cette négligence apparaît dans les rapports sur les violations de données : les études industrielles citant le rapport IBM 2025 sur le coût d'une violation de données indiquent que la grande majorité des organisations ayant subi des incidents de sécurité liés à l'IA manquaient de contrôles d'accès appropriés, et le rapport SpyCloud 2026 sur l'exposition des identités souligne une exposition à grande échelle de clés API et de jetons, y compris des identifiants liés à des outils d'IA. Les modèles conçus pour les humains, selon ces constats, ne tiennent pas la route pour les agents.

3. Entrée du TBAC : une idée ancienne dont l'heure a enfin sonné

Le contrôle d'accès basé sur les tâches n'est pas nouveau, ce qui rend sa renaissance crédible. Dans les années 1990, Roger Thomas et Ravi Sandhu ont proposé des contrôles d'autorisation basés sur les tâches, marquant une transition d'une approche centrée sur le sujet vers une approche centrée sur l'activité : des autorisations regroupées par tâches, accordées sous forme d'ensemble minimal requis pour une activité spécifique, actives pendant sa durée, et consommées ou révoquées au fil du flux de travail. L'idée était en avance sur son infrastructure : les systèmes de workflow des années 1990 n'en avaient pas un besoin critique. Les agents, eux, en ont besoin. Un article récent sur arXiv concernant le contrôle d'accès adaptatif au risque pour les systèmes agents s'appuie sur le TBAC « en raison de son alignement naturel avec la nature orientée vers les objectifs des agents IA » — un agent, contrairement à un employé, est réellement réduit à sa tâche actuelle.

Les formulations modernes étendent le concept original dans deux directions. Le cadre proposé par Cisco Outshift — contrôle d'accès basé sur les outils, les transactions et les tâches — positionne explicitement le TBAC comme la couche venant après le RBAC, l'ABAC et le ReBAC pour l'IA agentique : une autorisation définie non pas par l'identité de l'agent, mais par les outils qu'il peut appeler, les transactions qu'il peut effectuer et la tâche qu'il exécute. La recherche explore actuellement la manière dont la « tâche » est validée : les travaux sur arXiv utilisent un LLM comme juge conscient de l'incertitude pour déterminer si une action sert la tâche autorisée — une approche prometteuse, précoce et transparente sur ses défis. Entre le consensus des praticiens et la recherche, une définition opérationnelle émerge. Le TBAC à l'ère des agents signifie : un ensemble d'autorisations par tâche (outils et données minimaux pour cet objectif), une liaison à la durée (identifiants éphémères limités à la tâche avec des TTL de quelques minutes), une capture de délégation (la tâche porte l'identité de celui qui l'a autorisée et pour le compte de qui), et des points de contrôle transactionnels (les étapes irréversibles font l'objet d'une validation explicite). Rien de tout cela ne remplace les anciens modèles ; cela vient s'y ajouter, ce qui constitue l'idée directrice que les sections suivantes concrétisent.

4. Le modèle en couches : où chaque BAC conserve sa pertinence

La littérature spécialisée est unanime sur un point : remplacer entièrement le RBAC n'est ni nécessaire ni souhaitable. Les modèles se complètent, et dans une pile LLM/RAG/MCP, chacun a son rôle. Le RBAC reste la limite extérieure — définissant quelles équipes et quels services peuvent accéder à quels modèles, serveurs MCP et agents ; une approche globale, auditable, calquée sur l'organigramme, exactement ce qu'une limite extérieure doit être. Une politique de type ABAC s'exécute au moment de la requête — l'équipe, l'environnement, la classification des données et les métadonnées de coût déterminent si cet appel, dans ce contexte, peut aboutir ; dans le cadre du RAG, c'est ici que résident les autorisations au niveau des documents, afin que la récupération respecte les droits de l'utilisateur effectuant la requête plutôt que ceux du pipeline. Le ReBAC régit la structure même des données — la propriété et l'héritage — qui sont primordiaux lorsque les agents parcourent des graphes de contenu tels que des lecteurs partagés ou des wikis. Le TBAC encadre le travail: le bundle d'outils par tâche, les identifiants limités à la tâche, l'enregistrement de délégation, le point de contrôle pour les actions irréversibles.

Considérés comme une pile, les modèles répondent à quatre questions concernant une requête d'agent : ce mandant est-il autorisé ici (RBAC), cette requête est-elle acceptable dans ce contexte (ABAC), la structure des données le permet-elle (ReBAC), cette action sert-elle la tâche autorisée dans ses limites (TBAC). Appliquez ces quatre contrôles en un point unique, avec un journal d'audit les reliant, et vous obtenez ce que l'ère des agents exige. Ce point est la passerelle — et ici, l'argument cesse d'être conceptuel, car ces constructions existent en tant que fonctionnalités documentées et opérationnelles.

‍

‍