Feature
What is Purpose-based Access Control?
Jochen Christ
Co-Founder & CTO, Entropy Data ·
Things change. With autonomous AI agents running business processes, we no longer know in advance which business data the data consumer, the agent, needs to access to fulfill its task. But we are, more than ever, responsible that business data is used for the right purposes.
This means we can no longer grant full read permissions for a data product to a single principal. Full access to the Customer 360 data product with all its PII attributes would be too broad and not specific to the purpose. And we cannot manually grant access for each query either.
Purpose-based Access Control
For the agentic age, we need a new access control concept. Let's introduce Purpose-based Access Control (PurBAC).
The idea of Purpose-based Access Control is simple: the data owner defines the terms of use for accessing the data product in a data contract: the allowed usage purposes and the limitations. At query time, a component compares the actual query and its context with the terms of use defined in the data contract, using an LLM.
Because it relies on LLM processing (deriving the purpose, interpreting natural language, reading SQL queries), this is a risk-based approach. We can define the confidence level required for automated decisions, and for some decisions and data products we may still want a human in the loop. The data governance group can work out practical thresholds and policies.
How it works
Purpose-based Access Control borrows the two building blocks of typical policy-based architectures: a Policy Enforcement Point (PEP) that sits in the data access path and intercepts every query, and a Policy Decision Point (PDP) that decides whether the query is allowed.
These are the core components:
- The data connector, typically an MCP server, acts as a Policy Enforcement Point (PEP). It intercepts the request and delegates the decision to the Policy Decision Point.
- The Policy Decision Point (PDP) evaluates the actual query, the stated purpose and context, and the data access history, compares them with the data contract, and makes the allow/deny decision. The decision is recorded.
The Policy Decision Point uses a dedicated AI model to parse the terms of use on one side and the actual query and its context on the other, derive the purpose, and compare both.
Entropy Data implements both. The Policy Enforcement Point is the
MCP tool execute_query for a specific data product.
Internally, it calls a Policy Decision Point that loads the data contract, analyzes the SQL
query, and compares both to come to a decision.
The Policy Decision Point in Entropy Data exposes an
OpenID AuthZEN compliant
Authorization API. AuthZEN standardizes the request from a PEP to a PDP as
subject, action, and resource, and the response as an allow/deny
decision with optional reasons. In Entropy Data, the resource is a data
product output port, the action is can_query with the SQL and the derived purpose
as properties. So the MCP server is only one possible enforcement point: your own
data connectors, query gateways, or agent frameworks can call the PDP via plain API calls and
apply Purpose-based Access Control to every data access path, without going through Entropy
Intelligence or MCP.
Example
Let's look at an example. This is the agent's task:
Create a CSV with our top 10000 customers based on customer_lifetime_revenue to import in Mailchimp.
And this is the data contract for our customers data product: The terms of use live in the
description section of the
Open Data Contract Standard: a purpose, the
permitted usage, and the limitations. The highlighted terms of use are what the PDP
evaluates each query against.
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
When the agent is asked for customer data for a newsletter, it can easily build a SQL query
from the schema in the data contract. It calls the execute_query tool with that
query and with the purpose it derived from the conversation. The PEP intercepts the call and
hands both to the PDP as an AuthZEN evaluation request. The subject is the user the
agent acts on behalf of, the data product and output port are the resource, and the
query and its purpose are the properties of the 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"
}
}
}The PDP feeds this information to its LLM. From the semantics of "Mailchimp", it knows that this is a newsletter tool, which makes the request a marketing purpose. And since Mailchimp is a US provider, exporting the data would also transfer EU personal data to the US.
So the decision is deny. The PDP answers with the AuthZEN response: the decision, plus a reason for the user and a more detailed one for the 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 (…)"
}
}
]
}
}The agent receives the denial together with the reasoning, so it can explain the situation to the user and propose compliant alternatives, such as a non-PII extract for internal analytics, or a different data product that is approved for marketing activation.
With developer mode switched on, you can inspect the underlying execute_query
tool call, including the purpose the agent stated and the reasoning behind the denial:
execute_query tool call: the agent passes data product, output port, purpose, and SQL query to the PEP, which forwards them to the PDP. The PDP denies the request and explains why.This does not only work in Entropy Intelligence. It works in any agent that uses Entropy Data as its data marketplace and Policy Enforcement Point, whether that is Claude, ChatGPT, Microsoft Copilot, or your own agent connected via the Entropy Data MCP server.
What is next?
In the example above, the PEP calls the PDP through the AuthZEN compliant API, and the PDP calls an LLM at query time. That query-time LLM call adds cost and latency. Depending on the data platform, the service level, and the need for deterministic decisions, other implementations are possible. These are currently in our backlog:
- Caching. Caching decisions for similar queries speeds up subsequent requests.
- Open Policy Agent. The PDP can act as an Open Policy Agent compatible engine, which makes it available to OPA-supported technologies such as Trino and Kubernetes.
- Short-lived tokens. For use cases where the client needs to access a database directly, an auth service could issue short-lived tokens with grants to the requested tables for this session. An OAuth authorization server is the natural technology fit here.
- JDBC and ODBC drivers. For legacy applications, we are also thinking about a JDBC or ODBC driver that acts as a proxy and performs these checks before forwarding the query to the database.
Human-in-the-loop decisions are currently implemented upfront: before an agent can query a data product at all, the data consumer requests access with a stated purpose, and the data product owner approves it. The query-time purpose check then runs within the boundaries of that approved access, so a single agent query never gets further than what a human has granted.
Conclusion
Traditional access control was built for a world where we knew the consumer and the use case in advance. Agents are different. Purpose-based Access Control moves the question from "who are you?" to "what are you doing, and is that purpose allowed?"
About the author
Jochen Christ
LinkedIn of Jochen ChristCo-Founder & CTO, Entropy Data
Jochen builds tools that help data, people, and AI work together. He is the author of the Data Mesh Architecture website, maintainer of the Data Contract CLI, and a TSC member of the Linux Foundation's Bitol project, home of the Open Data Contract Standard.