Fonctionnalité

Qu'est-ce que le Purpose-based Access Control ?

Jochen Christ

Co-Founder & CTO, Entropy Data · 2026-08-21

Les choses changent. Avec des agents IA autonomes qui pilotent des processus métier, nous ne savons plus à l'avance à quelles données métier le Data Consumer, c'est-à-dire l'agent, devra accéder pour accomplir sa tâche. Mais nous restons, plus que jamais, responsables de l'utilisation des données métier aux bonnes fins.

Cela signifie que nous ne pouvons plus accorder des droits de lecture complets sur un produit de données à un seul principal. Un accès complet au produit de données Customer 360, avec tous ses attributs personnels, serait trop large et sans lien avec la finalité. Et nous ne pouvons pas non plus accorder manuellement l'accès pour chaque requête.

Purpose-based Access Control

Pour l'ère des agents, nous avons besoin d'un nouveau concept de contrôle d'accès. Voici le Purpose-based Access Control (PurBAC).

L'idée du Purpose-based Access Control est simple : le propriétaire des données définit les conditions d'utilisation pour accéder au produit de données dans un Data Contract : les finalités d'utilisation autorisées et les limitations. Au moment de la requête, un composant compare la requête réelle et son contexte avec les conditions d'utilisation définies dans le Data Contract, à l'aide d'un LLM.

Parce qu'elle repose sur un traitement par LLM (déduire la finalité, interpréter le langage naturel, lire des requêtes SQL), cette approche est fondée sur le risque. Nous pouvons définir le niveau de confiance requis pour les décisions automatisées et, pour certaines décisions et certains produits de données, nous pouvons toujours vouloir garder un humain dans la boucle. Le groupe de gouvernance des données peut élaborer des seuils et des politiques pratiques.

Comment ça fonctionne

Le Purpose-based Access Control reprend les deux briques des architectures classiques fondées sur des politiques : un Policy Enforcement Point (PEP), placé sur le chemin d'accès aux données, qui intercepte chaque requête, et un Policy Decision Point (PDP), qui décide si la requête est autorisée.

Voici les composants principaux :

• Le connecteur de données, en général un serveur MCP, joue le rôle de Policy Enforcement Point (PEP). Il intercepte la demande et délègue la décision au Policy Decision Point.
• Le Policy Decision Point (PDP) évalue la requête réelle, la finalité déclarée et le contexte, ainsi que l'historique des accès aux données, les compare avec le Data Contract et prend la décision d'autoriser ou de refuser. La décision est enregistrée.

Le Policy Decision Point utilise un modèle d'IA dédié pour analyser d'un côté les conditions d'utilisation, de l'autre la requête réelle et son contexte, en déduire la finalité et comparer les deux.

Entropy Data implémente les deux. Le Policy Enforcement Point est l'outil MCP execute_query d'un produit de données donné. En interne, il appelle un Policy Decision Point qui charge le Data Contract, analyse la requête SQL et compare les deux pour arriver à une décision.

Le Policy Decision Point d'Entropy Data expose une Authorization API conforme à OpenID AuthZEN. AuthZEN standardise la demande d'un PEP vers un PDP sous la forme subject, action et resource, et la réponse sous la forme d'une décision d'autorisation ou de refus, avec des motifs facultatifs. Dans Entropy Data, la ressource est un Output Port de produit de données, et l'action est can_query, avec le SQL et la finalité déduite comme propriétés. Le serveur MCP n'est donc qu'un point d'application possible parmi d'autres : vos propres connecteurs de données, passerelles de requêtes ou frameworks d'agents peuvent appeler le PDP par de simples appels d'API et appliquer le Purpose-based Access Control à chaque chemin d'accès aux données, sans passer par Entropy Intelligence ni par MCP.

Exemple

Prenons un exemple. Voici la tâche de l'agent :

Create a CSV with our top 10000 customers based on customer_lifetime_revenue to import in Mailchimp.

Et voici le Data Contract de notre produit de données clients. Les conditions d'utilisation se trouvent dans la section description de l'Open Data Contract Standard : une finalité, l'usage autorisé et les limitations. Les conditions d'utilisation surlignées sont celles par rapport auxquelles le PDP évalue chaque requête.

apiVersion: v3.1.0
kind: DataContract
id: sales_customers_v1
name: Customers
version: 1.0.0
status: active
description:
  purpose: |-
    This data product contains customer information provided by the sales
    department. It includes registered webshop customers and guest customers
    since 2020. It includes customer demographics, contact information,
    order history, and engagement metrics.
  usage: Data can be used for financial reporting and sales analytics.
  limitations: Do not transfer data outside of EU. Do not use for marketing purposes.

schema:
  # omitted for brevity, but important for the agent to build a semantically correct SQL query

Lorsqu'on demande à l'agent des données clients pour une newsletter, il peut facilement construire une requête SQL à partir du schéma du Data Contract. Il appelle l'outil execute_query avec cette requête et avec la finalité qu'il a déduite de la conversation. Le PEP intercepte l'appel et transmet les deux au PDP sous la forme d'une demande d'évaluation AuthZEN. Le subject est l'utilisateur pour le compte duquel l'agent agit, le produit de données et l'Output Port constituent la resource, et la requête et sa finalité sont les propriétés de l'action :

POST /api/access/evaluation

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "dataproduct",
    "id": "sales_customers_v1",
    "properties": {
      "outputPortId": "databricks"
    }
  },
  "action": {
    "name": "can_query",
    "properties": {
      "purpose": "Create a CSV of the top 10,000 customers ranked by customer_lifetime_revenue for Mailchimp import",
      "sql": "SELECT customer_id, email, first_name, last_name, phone, country, total_orders, total_spent AS customer_lifetime_revenue FROM sales_customers_demo.dp_customers_v1.customers WHERE email IS NOT NULL AND TRIM(email) <> '' ORDER BY total_spent DESC NULLS LAST LIMIT 10000"
    }
  }
}

Le PDP transmet ces informations à son LLM. Grâce à la sémantique de « Mailchimp », il sait qu'il s'agit d'un outil de newsletter, ce qui fait de la demande une finalité marketing. Et comme Mailchimp est un fournisseur américain, exporter les données transférerait aussi des données personnelles de l'UE vers les États-Unis.

La décision est donc un refus. Le PDP répond avec la réponse AuthZEN : la décision, accompagnée d'un motif pour l'utilisateur et d'un motif plus détaillé pour l'administrateur :

{
  "decision": false,
  "context": {
    "reasons": [
      {
        "id": "DATA_CONTRACT_TERMS_CONFLICT",
        "reason_user": {
          "en": "Query conflicts with data contract terms: The stated purpose is to create a Mailchimp import, which is a marketing use and violates the contract limitation 'Do not use for marketing purposes'. The query also exports PII (email, name, phone), and transferring it to Mailchimp may constitute transfer outside the EU, violating 'Do not transfer data outside of EU'."
        },
        "reason_admin": {
          "en": "Query violates data contract sales_customers_v1 terms: The stated purpose is to create a Mailchimp import, which is a marketing use (…)"
        }
      }
    ]
  }
}

L'agent reçoit le refus accompagné du raisonnement : il peut ainsi expliquer la situation à l'utilisateur et proposer des alternatives conformes, comme un extrait sans données personnelles pour des analyses internes, ou un autre produit de données approuvé pour l'activation marketing.

En activant le mode développeur, vous pouvez inspecter l'appel d'outil execute_query sous-jacent, y compris la finalité déclarée par l'agent et le raisonnement derrière le refus :

Cela ne fonctionne pas seulement dans Entropy Intelligence. Cela fonctionne avec n'importe quel agent qui utilise Entropy Data comme marketplace de données et comme Policy Enforcement Point, qu'il s'agisse de Claude, de ChatGPT, de Microsoft Copilot ou de votre propre agent connecté via le serveur MCP d'Entropy Data.

Et ensuite ?

Dans l'exemple ci-dessus, le PEP appelle le PDP via l'API conforme à AuthZEN, et le PDP appelle un LLM au moment de la requête. Cet appel LLM à l'exécution ajoute un coût et de la latence. Selon la plateforme de données, le niveau de service et le besoin de décisions déterministes, d'autres implémentations sont possibles. Elles figurent actuellement dans notre backlog :

• Mise en cache. Mettre en cache les décisions pour des requêtes similaires accélère les demandes suivantes.
• Open Policy Agent. Le PDP peut se comporter comme un moteur compatible Open Policy Agent, ce qui le rend disponible pour les technologies prenant en charge OPA, comme Trino et Kubernetes.
• Jetons de courte durée. Pour les cas d'usage où le client doit accéder directement à une base de données, un service d'authentification pourrait émettre des jetons de courte durée avec des droits sur les tables demandées pour la session. Un serveur d'autorisation OAuth est ici le choix technologique naturel.
• Pilotes JDBC et ODBC. Pour les applications legacy, nous réfléchissons aussi à un pilote JDBC ou ODBC faisant office de proxy, qui effectue ces contrôles avant de transmettre la requête à la base de données.

Les décisions avec un humain dans la boucle sont aujourd'hui implémentées en amont : avant qu'un agent puisse interroger un produit de données, le Data Consumer demande l'accès en indiquant une finalité, et le Data Product Owner l'approuve. Le contrôle de finalité au moment de la requête s'exerce ensuite dans les limites de cet accès approuvé : une requête d'agent ne va jamais au-delà de ce qu'un humain a accordé.

Conclusion

Le contrôle d'accès traditionnel a été conçu pour un monde où nous connaissions à l'avance le consommateur et le cas d'usage. Les agents sont différents. Le Purpose-based Access Control déplace la question de « qui êtes-vous ? » vers « que faites-vous, et cette finalité est-elle autorisée ? »

À propos de l'auteur

Jochen Christ

LinkedIn de Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen construit des outils pour faire travailler ensemble les données, les gens et l'IA. Il est l'auteur du site Data Mesh Architecture, mainteneur de la Data Contract CLI et membre du TSC du projet Bitol de la Linux Foundation, qui héberge l'Open Data Contract Standard.

Échanger avec Jochen →