Feature
Was ist Purpose-based Access Control?
Jochen Christ
Co-Founder & CTO, Entropy Data ·
Die Dinge ändern sich. Wenn autonome KI-Agenten Geschäftsprozesse ausführen, wissen wir nicht mehr im Voraus, auf welche Business-Daten der Data Consumer, also der Agent, zugreifen muss, um seine Aufgabe zu erledigen. Aber wir sind, mehr denn je, dafür verantwortlich, dass Business-Daten für die richtigen Zwecke verwendet werden.
Das heißt: Wir können einem einzelnen Principal nicht mehr volle Leserechte auf ein Datenprodukt geben. Voller Zugriff auf das Datenprodukt Customer 360 mit all seinen PII-Attributen wäre zu weit gefasst und nicht auf den Zweck zugeschnitten. Und wir können den Zugriff auch nicht für jede einzelne Query manuell freigeben.
Purpose-based Access Control
Für das Zeitalter der Agenten brauchen wir ein neues Zugriffskonzept. Darf ich vorstellen: Purpose-based Access Control (PurBAC).
Die Idee hinter Purpose-based Access Control ist einfach: Der Data Owner definiert die Nutzungsbedingungen für den Zugriff auf das Datenprodukt in einem Data Contract: die erlaubten Nutzungszwecke und die Einschränkungen. Zur Query-Zeit vergleicht eine Komponente die tatsächliche Query und ihren Kontext mit den Nutzungsbedingungen aus dem Data Contract, und zwar mit einem LLM.
Weil dabei ein LLM im Spiel ist (den Zweck ableiten, natürliche Sprache interpretieren, SQL-Queries lesen), ist das ein risikobasierter Ansatz. Wir können das Konfidenzniveau festlegen, das für automatisierte Entscheidungen nötig ist, und bei manchen Entscheidungen und Datenprodukten wollen wir vielleicht weiterhin einen Menschen in der Schleife haben. Die Data-Governance-Gruppe kann praktikable Schwellenwerte und Policies erarbeiten.
So funktioniert es
Purpose-based Access Control übernimmt die zwei Bausteine typischer policy-basierter Architekturen: einen Policy Enforcement Point (PEP), der im Datenzugriffspfad sitzt und jede Query abfängt, und einen Policy Decision Point (PDP), der entscheidet, ob die Query erlaubt ist.
Das sind die zentralen Komponenten:
- Der Datenkonnektor, typischerweise ein MCP-Server, agiert als Policy Enforcement Point (PEP). Er fängt die Anfrage ab und delegiert die Entscheidung an den Policy Decision Point.
- Der Policy Decision Point (PDP) wertet die tatsächliche Query, den angegebenen Zweck und Kontext sowie die Zugriffshistorie aus, vergleicht sie mit dem Data Contract und trifft die Allow/Deny-Entscheidung. Die Entscheidung wird protokolliert.
Der Policy Decision Point nutzt ein dediziertes KI-Modell, um auf der einen Seite die Nutzungsbedingungen und auf der anderen Seite die tatsächliche Query und ihren Kontext zu parsen, den Zweck abzuleiten und beides zu vergleichen.
Entropy Data implementiert beides. Der Policy Enforcement Point ist das
MCP-Tool execute_query für ein bestimmtes
Datenprodukt. Intern ruft es einen Policy Decision Point auf, der den Data Contract lädt,
die SQL-Query analysiert und beides vergleicht, um zu einer Entscheidung zu kommen.
Der Policy Decision Point in Entropy Data stellt eine
OpenID AuthZEN-konforme
Authorization API bereit. AuthZEN standardisiert die Anfrage vom PEP an den PDP als
subject, action und resource und die Antwort als
Allow/Deny-Entscheidung mit optionalen Begründungen. In Entropy Data ist die Resource ein
Output Port eines Datenprodukts, die Action ist can_query mit dem SQL und dem
abgeleiteten Zweck als Properties. Der MCP-Server ist damit nur ein möglicher Enforcement
Point: Deine eigenen Datenkonnektoren, Query-Gateways oder Agenten-Frameworks können den
PDP über einfache API-Aufrufe ansprechen und Purpose-based Access Control auf jedem
Datenzugriffspfad anwenden, ohne den Umweg über Entropy Intelligence oder MCP.
Beispiel
Schauen wir uns ein Beispiel an. Das ist die Aufgabe des Agenten:
Create a CSV with our top 10000 customers based on customer_lifetime_revenue to import in Mailchimp.
Und das ist der Data Contract für unser Datenprodukt Customers: Die Nutzungsbedingungen
stehen im Abschnitt description des
Open Data Contract Standard: ein Zweck,
die erlaubte Nutzung und die Einschränkungen. Die hervorgehobenen Nutzungsbedingungen sind
das, wogegen der PDP jede Query prüft.
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
Wenn der Agent nach Kundendaten für einen Newsletter gefragt wird, kann er aus dem Schema im
Data Contract leicht eine SQL-Query bauen. Er ruft das Tool execute_query mit
dieser Query und mit dem Zweck auf, den er aus der Konversation abgeleitet hat. Der PEP
fängt den Aufruf ab und übergibt beides als AuthZEN-Evaluation-Request an den PDP. Das
subject ist der User, in dessen Auftrag der Agent handelt, Datenprodukt und Output
Port sind die resource, und Query und Zweck sind die Properties der
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"
}
}
}Der PDP gibt diese Informationen an sein LLM. Aus der Semantik von „Mailchimp“ weiß es, dass das ein Newsletter-Tool ist, die Anfrage also einen Marketing-Zweck hat. Und weil Mailchimp ein US-Anbieter ist, würde der Export außerdem personenbezogene Daten aus der EU in die USA übertragen.
Die Entscheidung lautet also Deny. Der PDP antwortet mit der AuthZEN-Response: die Entscheidung plus eine Begründung für den User und eine ausführlichere für den Administrator:
{
"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 (…)"
}
}
]
}
}Der Agent erhält die Ablehnung zusammen mit der Begründung. So kann er dem User die Situation erklären und konforme Alternativen vorschlagen, etwa einen Auszug ohne PII für interne Analysen oder ein anderes Datenprodukt, das für Marketing-Aktivierung freigegeben ist.
Mit eingeschaltetem Developer Mode kannst du den zugrunde liegenden
execute_query-Tool-Aufruf einsehen, inklusive des vom Agenten angegebenen
Zwecks und der Begründung für die Ablehnung:
execute_query-Tool-Aufruf: Der Agent übergibt Datenprodukt, Output Port, Zweck und SQL-Query an den PEP, der sie an den PDP weiterleitet. Der PDP lehnt die Anfrage ab und erklärt, warum.Das funktioniert nicht nur in Entropy Intelligence, sondern in jedem Agenten, der Entropy Data als Datenmarktplatz und Policy Enforcement Point nutzt, egal ob Claude, ChatGPT, Microsoft Copilot oder dein eigener Agent, angebunden über den MCP-Server von Entropy Data.
Wie geht es weiter?
Im Beispiel oben ruft der PEP den PDP über die AuthZEN-konforme API auf, und der PDP ruft zur Query-Zeit ein LLM auf. Dieser LLM-Aufruf zur Query-Zeit kostet Geld und Latenz. Je nach Datenplattform, Service Level und Bedarf an deterministischen Entscheidungen sind andere Implementierungen möglich. Diese stehen aktuell in unserem Backlog:
- Caching. Das Caching von Entscheidungen für ähnliche Queries beschleunigt nachfolgende Anfragen.
- Open Policy Agent. Der PDP kann als Open-Policy-Agent-kompatible Engine agieren und steht damit OPA-fähigen Technologien wie Trino und Kubernetes zur Verfügung.
- Kurzlebige Tokens. Für Use Cases, in denen der Client direkt auf eine Datenbank zugreifen muss, könnte ein Auth-Service kurzlebige Tokens mit Grants auf die angefragten Tabellen für diese Session ausstellen. Ein OAuth Authorization Server ist hier die natürliche technische Wahl.
- JDBC- und ODBC-Treiber. Für Legacy-Anwendungen denken wir außerdem über einen JDBC- oder ODBC-Treiber als Proxy nach, der diese Prüfungen durchführt, bevor er die Query an die Datenbank weiterleitet.
Human-in-the-Loop-Entscheidungen sind aktuell vorgelagert umgesetzt: Bevor ein Agent ein Datenprodukt überhaupt abfragen kann, beantragt der Data Consumer den Zugriff mit einem angegebenen Zweck, und der Data Product Owner gibt ihn frei. Die Zweckprüfung zur Query-Zeit läuft dann innerhalb der Grenzen dieses freigegebenen Zugriffs. Eine einzelne Agenten-Query kommt also nie weiter als das, was ein Mensch gewährt hat.
Fazit
Klassische Zugriffskontrolle wurde für eine Welt gebaut, in der wir Consumer und Use Case im Voraus kannten. Agenten sind anders. Purpose-based Access Control verschiebt die Frage von „Wer bist du?“ zu „Was tust du, und ist dieser Zweck erlaubt?“
Über den Autor
Jochen Christ
LinkedIn von Jochen ChristCo-Founder & CTO, Entropy Data
Jochen baut Tools, die Daten, Menschen und KI zusammenarbeiten lassen. Er ist Autor der Website Data Mesh Architecture, Maintainer der Data Contract CLI und TSC-Mitglied im Bitol-Projekt der Linux Foundation, der Heimat des Open Data Contract Standard.