Funcionalidad
¿Qué es Purpose-based Access Control?
Jochen Christ
Co-Founder & CTO, Entropy Data ·
Las cosas cambian. Con agentes de IA autónomos ejecutando procesos de negocio, ya no sabemos de antemano a qué datos de negocio necesita acceder el Data Consumer, el agente, para cumplir su tarea. Pero somos, más que nunca, responsables de que los datos de negocio se usen para los fines correctos.
Esto significa que ya no podemos conceder permisos de lectura completos sobre un producto de datos a un único principal. Un acceso total al producto de datos Customer 360, con todos sus atributos PII, sería demasiado amplio y poco específico para el fin. Y tampoco podemos conceder el acceso manualmente para cada consulta.
Purpose-based Access Control
Para la era de los agentes necesitamos un nuevo concepto de control de acceso. Presentamos Purpose-based Access Control (PurBAC).
La idea de Purpose-based Access Control es sencilla: el Data Owner define las condiciones de uso para acceder al producto de datos en un Data Contract: los fines de uso permitidos y las limitaciones. En el momento de la consulta, un componente compara la consulta real y su contexto con las condiciones de uso definidas en el Data Contract, usando un LLM.
Como se apoya en el procesamiento con LLM (derivar el fin, interpretar lenguaje natural, leer consultas SQL), es un enfoque basado en riesgo. Podemos definir el nivel de confianza necesario para las decisiones automáticas y, para algunas decisiones y productos de datos, quizá sigamos queriendo a una persona en el proceso. El grupo de Data Governance puede establecer umbrales y políticas prácticos.
Cómo funciona
Purpose-based Access Control toma prestados los dos componentes básicos de las arquitecturas típicas basadas en políticas: un Policy Enforcement Point (PEP), situado en la ruta de acceso a los datos, que intercepta cada consulta, y un Policy Decision Point (PDP), que decide si la consulta está permitida.
Estos son los componentes principales:
- El conector de datos, normalmente un servidor MCP, actúa como Policy Enforcement Point (PEP). Intercepta la petición y delega la decisión en el Policy Decision Point.
- El Policy Decision Point (PDP) evalúa la consulta real, el fin declarado y el contexto, así como el historial de acceso a los datos, los compara con el Data Contract y toma la decisión de permitir o denegar. La decisión queda registrada.
El Policy Decision Point usa un modelo de IA específico para interpretar, por un lado, las condiciones de uso y, por otro, la consulta real y su contexto, derivar el fin y comparar ambos.
Entropy Data implementa ambos. El Policy Enforcement Point es la
herramienta MCP execute_query para un producto de
datos concreto. Internamente llama a un Policy Decision Point que carga el Data Contract,
analiza la consulta SQL y compara ambos para llegar a una decisión.
El Policy Decision Point de Entropy Data expone una Authorization API conforme a
OpenID AuthZEN. AuthZEN
estandariza la petición de un PEP a un PDP como subject, action y
resource, y la respuesta como una decisión de permitir o denegar con motivos
opcionales. En Entropy Data, el resource es el Output Port de un producto de datos y la
action es can_query, con el SQL y el fin derivado como propiedades. Así que el
servidor MCP es solo uno de los puntos de aplicación posibles: tus propios conectores de
datos, gateways de consultas o frameworks de agentes pueden llamar al PDP mediante simples
llamadas a la API y aplicar Purpose-based Access Control a cada ruta de acceso a los datos,
sin pasar por Entropy Intelligence ni por MCP.
Ejemplo
Veamos un ejemplo. Esta es la tarea del agente:
Create a CSV with our top 10000 customers based on customer_lifetime_revenue to import in Mailchimp.
Y este es el Data Contract de nuestro producto de datos de clientes. Las condiciones de uso
viven en la sección description del
Open Data Contract Standard: un fin,
el uso permitido y las limitaciones. Las condiciones de uso resaltadas son aquello contra lo
que el PDP evalúa cada consulta.
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
Cuando se le pide al agente datos de clientes para una newsletter, puede construir fácilmente
una consulta SQL a partir del esquema del Data Contract. Llama a la herramienta
execute_query con esa consulta y con el fin que ha derivado de la conversación.
El PEP intercepta la llamada y entrega ambos al PDP como una petición de evaluación AuthZEN.
El subject es el usuario en cuyo nombre actúa el agente, el producto de datos y el
Output Port son el resource, y la consulta y su fin son las propiedades de la
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"
}
}
}El PDP pasa esta información a su LLM. Por la semántica de «Mailchimp», sabe que se trata de una herramienta de newsletters, lo que convierte la petición en un fin de marketing. Y como Mailchimp es un proveedor estadounidense, exportar los datos también transferiría datos personales de la UE a Estados Unidos.
Así que la decisión es denegar. El PDP responde con la respuesta AuthZEN: la decisión, más un motivo para el usuario y otro más detallado para el administrador:
{
"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 (…)"
}
}
]
}
}El agente recibe la denegación junto con el razonamiento, de modo que puede explicar la situación al usuario y proponer alternativas conformes, como un extracto sin PII para analítica interna o un producto de datos distinto aprobado para activación de marketing.
Con el modo de desarrollador activado, puedes inspeccionar la llamada subyacente a la
herramienta execute_query, incluido el fin declarado por el agente y el
razonamiento de la denegación:
execute_query: el agente pasa el producto de datos, el Output Port, el fin y la consulta SQL al PEP, que los reenvía al PDP. El PDP deniega la petición y explica por qué.Esto no funciona solo en Entropy Intelligence. Funciona en cualquier agente que use Entropy Data como marketplace de datos y Policy Enforcement Point, ya sea Claude, ChatGPT, Microsoft Copilot o tu propio agente conectado a través del servidor MCP de Entropy Data.
¿Qué viene después?
En el ejemplo anterior, el PEP llama al PDP a través de la API conforme a AuthZEN, y el PDP llama a un LLM en el momento de la consulta. Esa llamada al LLM en tiempo de consulta añade coste y latencia. Según la plataforma de datos, el nivel de servicio y la necesidad de decisiones deterministas, son posibles otras implementaciones. Estas están ahora mismo en nuestro backlog:
- Caché. Guardar en caché las decisiones de consultas similares acelera las peticiones posteriores.
- Open Policy Agent. El PDP puede actuar como un motor compatible con Open Policy Agent, lo que lo hace disponible para tecnologías con soporte de OPA como Trino y Kubernetes.
- Tokens de corta duración. Para los casos de uso en los que el cliente necesita acceder directamente a una base de datos, un servicio de autenticación podría emitir tokens de corta duración con permisos sobre las tablas solicitadas para esa sesión. Un servidor de autorización OAuth es la tecnología natural para ello.
- Drivers JDBC y ODBC. Para aplicaciones legacy, también estamos pensando en un driver JDBC u ODBC que actúe como proxy y realice estas comprobaciones antes de reenviar la consulta a la base de datos.
Las decisiones con una persona en el proceso se implementan hoy por adelantado: antes de que un agente pueda consultar un producto de datos, el Data Consumer solicita acceso con un fin declarado y el Data Product Owner lo aprueba. La comprobación del fin en tiempo de consulta se ejecuta entonces dentro de los límites de ese acceso aprobado, de modo que una consulta individual de un agente nunca llega más lejos de lo que una persona ha concedido.
Conclusión
El control de acceso tradicional se diseñó para un mundo en el que conocíamos de antemano al consumidor y el caso de uso. Los agentes son distintos. Purpose-based Access Control desplaza la pregunta de «¿quién eres?» a «¿qué estás haciendo, y está permitido ese fin?»
Sobre el autor
Jochen Christ
LinkedIn de Jochen ChristCo-Founder & CTO, Entropy Data
Jochen construye herramientas para que los datos, las personas y la IA trabajen juntos. Es autor del sitio Data Mesh Architecture, maintainer de la Data Contract CLI y miembro del TSC del proyecto Bitol de la Linux Foundation, hogar del Open Data Contract Standard.