Conviction

Appliquer le Zero Trust aux actions agentiques

Une identité d’agent connue et correctement authentifiée ne justifie pas une confiance permanente dans toutes ses actions futures.

Chaque action sensible reste à évaluer selon la ressource, l’opération, le contexte et les privilèges nécessaires.

Le point de départ : le Zero Trust du NIST

L’architecture Zero Trust du NIST abandonne la confiance implicite fondée principalement sur la localisation réseau et centre la protection sur les ressources. Son modèle de référence comprend des fonctions de décision et d’application de politique qui contrôlent l’accès aux ressources protégées ; authentification et autorisation participent toutes deux à la décision.[1]

L’ABAC du NIST fournit un modèle où les attributs du sujet, de l’objet, de l’opération et de l’environnement influencent l’autorisation.[2]

« Zero Trust agentique » n’est pas une notion définie par le NIST. C’est notre application de ces principes à une chaîne agentique.

Chaque action, une nouvelle décision

Chaque action réévaluée

Une identité authentifiée pilote l’agent. Action 1 : décision, permit, outil. Action 2 : décision, permit, API. Action 3 : décision, deny, bloquée.

L’authentification de l’agent ne transforme pas ses actions futures en actions implicitement approuvées.

Même identité, trois demandes

Même agent, même identité, même outil :

DemandeAuthentificationConséquence possible
A · lire le catalogue produit publicidentiquefaible : donnée publique
B · exporter des fiches clientsidentiquefuite de données personnelles
C · supprimer une fiche clientidentiqueperte irréversible

L’authentification ne distingue pas ces trois demandes. Les exigences d’autorisation et les conséquences, si.

Le moindre privilège sur plusieurs couches

Couches de moindre privilège d’un agent

Identité de l’agent, périmètre du credential, outils disponibles, opération permise, ressource autorisée, paramètres acceptés, destination approuvée, restrictions runtime.

Toutes les architectures n’implémentent pas chaque couche ; chacune réduit un type d’écart différent.

OWASP recommande de limiter fonctionnalités, permissions et autonomie, d’exiger une approbation humaine pour les opérations à fort impact et d’implémenter l’autorisation en aval.[3] L’Agent Control Standard ajoute l’inspectabilité, la traçabilité et les contrôles runtime.[4]

Conséquences d’architecture

Réévaluer les actions sensibles
Une session ouverte ne vaut pas approbation des actions suivantes.
Utiliser des credentials de périmètre réduit
Un token limité à la tâche borne l’effet d’un agent détourné.
Tracer chaque décision
Permit ou Deny, requête, contexte et action résultante restent reconstituables.

Limite

Le Zero Trust est un principe d’architecture. Il ne justifie pas d’insérer un moteur de politique dans chaque interaction technique : l’effort de contrôle se concentre sur les actions dont l’effet le justifie.

Contenus associés

Sources

Sources vérifiées le

  1. [1]

    Framework

    NIST

    Zero Trust Architecture (NIST SP 800-207) (lien externe, nouvel onglet)

    Publication du NIST décrivant l'architecture Zero Trust, centrée sur les ressources, avec Policy Decision Point et Policy Enforcement Point.

    Publié en Vérifié le

  2. [2]

    Norme

    NIST

    Guide to Attribute Based Access Control (ABAC) Definition and Considerations (NIST SP 800-162) (lien externe, nouvel onglet)

    Guide du NIST définissant l'ABAC : évaluation d'attributs du sujet, de l'objet, de l'opération et de l'environnement au regard de politiques.

    Vérifié le

  3. [3]

    Framework

    OWASP GenAI Security Project

    LLM06:2025 Excessive Agency (lien externe, nouvel onglet)

    Fiche OWASP sur l'agentivité excessive : fonctionnalités, permissions et autonomie excessives, et mesures d'atténuation dont la médiation complète.

    Vérifié le

  4. [4]

    Framework

    OWASP GenAI Security Project

    Agent Control Standard (ACS) (lien externe, nouvel onglet)

    Standard OWASP sur la transparence et le contrôle des agents d'entreprise : inspectabilité, traçabilité, instrumentation et points de contrôle runtime.

    Publié le Vérifié le

Appliquer ce principe à une architecture réelle

Nous pouvons partir d’un agent, d’un outil MCP ou d’une action sensible pour identifier la frontière de contrôle et vérifier comment elle est réellement appliquée.

Étudier mon architecture