What is Purpose-Based Access Control (PBAC)?

Why access control has to start asking why

Standard access control decides who can reach data based on their role. An AI agent that runs under a role like “data science” or “support” can reach everything that role covers, whatever task it’s working on.

That setup worked when humans were the only ones making data requests, because a person reads a policy and understands context. But AI agents don’t work that way. Writing for the IAPP, Riskonnect senior counsel Rachel Webber argues that purpose limitation matters even more for agents. They pull and recombine data in ways that can drift past the purposes people were told about. That’s the gap Purpose Based Access Control (PBAC) closes, because the system itself checks why data is being used, on every request.

Why listen to us?

Purpose has been central to Ethyca’s work since 2021, when it open-sourced Fides, an ontology for describing data and the uses it’s permitted for. Those permitted uses are the purpose labels a PBAC system checks each request against. IAB Tech Lab received the Fides taxonomy as a donation in collaboration with Ethyca and built its Privacy Taxonomy on it. Fides also runs inside organizations including The New York Times and Ramp.

“
At the core of our vision is trust. Trust from our users, our partners, and our teams. By adopting Ethyca’s infrastructure, we’re unifying privacy, legal, and engineering around a single source of truth, enabling us to manage data responsibly and confidently as we expand globally.”

Anna Dvorak, Director of CRM & Lifecycle Marketing, JustPark

Ethyca’s runtime governance platform builds Purpose-Based Access Control on that foundation and enforces 150,000 policy decisions a second at runtime. This guide explains PBAC the way Ethyca applies it in production.

What is Purpose-Based Access Control (PBAC)?

Purpose-Based Access Control (PBAC) is a data access model that grants or denies access based on why someone needs the data. The requester can be a person, an application, or an AI agent, and the check happens when the request is made.

Every data request includes a declared purpose, such as “fraud detection,” “ad targeting,” or “AI model training.” The system checks that purpose against your policies, contracts, consent records, and applicable regulations. It either allows the data through, denies the request, or escalates it for review.

This maps directly to how privacy law already works. GDPR’s purpose limitation principle says personal data collected for one purpose can’t later be used in a way that’s incompatible with it. PBAC makes that enforceable at the infrastructure level, automatically, at the moment of access. And that includes requests from AI agents that can’t read a policy document the way a human can.

PBAC vs. RBAC vs. ABAC

RBAC, ABAC, and PBAC each answer a different question about a data request. Role-based access control (RBAC) grants access based on your job title or team. Attribute-based access control (ABAC) adds rules about the user, the data, and the request context. PBAC adds a purpose layer on top of both, and you’ll likely run all three together. The table shows how they compare.

Why AI agents and models need purpose-level controls

The gap between role and purpose is widest with AI agents. A person reads a ticket, pulls the records they need, and stops. An agent built to answer billing questions can start pulling purchase history to build an ad profile, and nothing in its role definition prevents that. The role only says support can see customer records, so nothing limits what the agent does with them.

Regulators are already watching for exactly this kind of overreach. Guidance from France’s data protection authority, the CNIL, published in 2024, confirms that general-purpose AI systems still need a defined purpose, even when their end use isn’t known during development.

In 2022, Hungary’s data protection authority fined Budapest Bank about €700,000 for using AI to analyze the emotions in customer service calls. The bank used the results to decide who to call back and to rate its staff. It never told customers, saying the disclosure would make calls too long. The regulator found no valid legal basis for the processing and ordered it to stop unless it could show one.

At the scale AI systems operate, there’s no way to review these requests manually, so your system has to check each one as it comes in.

Worked example: A bank’s fraud detection model

A bank builds a machine learning model to flag potentially fraudulent card transactions. The model needs access to transaction history, device data, and account records.

Under RBAC, the model runs under a “Fraud AI” service account. That role grants access to customer records, but it also grants that access for any purpose. So the same data could feed a marketing campaign, a credit risk model, or a third-party analytics vendor.

Under PBAC, the model’s access is tied to a declared purpose, fraud.detection. When it queries the transaction database, the request carries that purpose label. The system checks that label against the bank’s policies and approves it, because fraud detection is an approved use.

Now suppose the marketing team wants to use the same transaction data to target customers with a new credit card offer. This new request carries a different purpose, such as marketing.targeted. The system checks it and finds that these customers haven’t consented to their transaction data being used for marketing. So the system denies the request and logs the decision.

Nobody had to review that request or call a committee, because the policy was already written and the consent status already mapped. If an auditor asks whether transaction data was used for marketing without consent, the log shows it wasn’t.

How Ethyca enforces Purpose-Based Access Control

In the bank example, the fraud model got approved, and the marketing request got denied without a human in the loop.

Ethyca connects to your data stores and whatever is querying them, whether that’s a SQL client, a BI dashboard, a notebook, or an AI agent working through an MCP server. Fides, Ethyca’s open-source ontology, gives your data and its permitted uses a shared set of labels, and you can extend it with your own, like fraud.detection or marketing.targeted.

When a query comes in, Ethyca determines its purpose against those labels, approves fraud.detection, and denies marketing.targeted on the same dataset.

Astralis does the enforcement. It takes the purpose label, looks up the matching policy, checks consent records, and allows or denies the request before it runs. Every decision is logged and reproducible, giving you an evidence trail for when an auditor asks for it. Because Astralis runs inside your own infrastructure or privacy cloud, Ethyca never becomes a processor of your regulated data.

Put a purpose check on every data request

For AI agents that access customer data, RBAC tells you who made each request, and PBAC adds why. Without that second piece, every agent you deploy widens your regulatory exposure. PBAC closes the gap by verifying the purpose of every request and logging each decision.

But it only works if the groundwork is there. Start with a data inventory that maps what you have, where it lives, and what consent covers it. Then define purpose labels specific enough to enforce. Access controls build on both.

Speak with Ethyca’s mission engineers to see how Purpose-Based Access Control works on your own data, at runtime.

Frequently asked questions about PBAC