> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/SaaS/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/SaaS/govern/secure-your-data/intents.md).
# Intents
{% hint style="info" %}
**Private preview**: This feature is available to select accounts. Contact your Immuta representative for details.
{% endhint %}
Intents is a feature that enforces permissions based on the user's specific intent, allowing policy authors to scope data access to specific reasons for accessing data. Instead of basing access decisions solely on who users are, intents allow the policy decision to be based on what the users are doing and why they need access.
## Birthright access control challenges
Typical access decisions are based on facts about the querying user, and these facts fall into two categories:
{% columns %}
{% column %}
**Groups**
Groups are facts about a group of users that are consistent for everyone in the group, for example,
* Product team group member
* Engineering group member
* Full-time employee group member
{% endcolumn %}
{% column %}
**Attributes**
Attributes are facts about users, but those facts can be different throughout a given group. For example,
* Product team group member 1
* Attribute: Clearance level: SECRET
* Product team group member 2
* Attribute: Clearance level: TOP SECRET
{% endcolumn %}
{% endcolumns %}
The traditional access control approach makes access decisions based on who the users are: groups and attributes dictate whether or not they are granted access to data. However, if users need access to a dataset based on a project they're working on, it’s cumbersome to grant temporary access to a user based on what they need access to using the birthright model. Consider the following examples.
Elevated access example: A birthright access approach gives users all access or no access. There is no temporary elevation of access without intent-based access control.
Some members of the product team need elevated access for a specific project they're working on, but they shouldn't have this access permanently. The following policy is authored to restrict access to that data:
> Subscription policy: Allow users with attribute `Project:Research` to subscribe to data sources tagged `Restricted`.
The system then verifies the following things about the data and the user when making an access decision:
* Is the data source tagged `Restricted`?
* Does the user have attribute `Project:Research`?
These checks result in the following access.
| |
| :x: | :x: |
This birthright access approach gives these users all access or no access. There is no temporary elevation of access without [intent-based access control](#intent-based-access-control). See the [Intents reference guide](/SaaS/govern/secure-your-data/intents/intents-reference-guide.md#gain-table-access-keep-masking-exceptions) for a specific example of how intents can solve this use case.
Clinical trial example: A birthright access approach gives users access to both sets of data, and there's no way to temporarily restrict them to one trial without intent-based access control.
Some members of the product team are analyzing clinical trial data, and they need exclusive access to Trial A data. However, while working on Trial A, they shouldn't see Trial B data because of a conflict of interest. The following policy is authored to restrict access to that data:
> Subscription policy: Allow users with attribute `Project:Research` to subscribe to data sources tagged `Research`.
The system then verifies the following things about the data and the user when making an access decision:
* Is the data source tagged `Research`?
* Does the user have attribute `Project:Research`?
These checks result in the following access.
| |
| :white\_check\_mark: | :white\_check\_mark: |
The birthright access approach gives them access to both sets of data, and there's no way to temporarily restrict them to one trial without [intent-based access control](#intent-based-access-control). See the [Intents reference guide](/SaaS/govern/secure-your-data/intents/intents-reference-guide.md#limit-table-access-gain-masking-exceptions) for a specific example of how intents can solve this use case.
## Intent-based access control
Intents provide the context awareness essential to solving the access problems illustrated above by allowing users to temporarily assume attributes that replace their per-user attribute to grant them access to data under a specific intent. When you use intents in Immuta, you can
* **Prevent cross-purpose access:** Using intents ensures exclusive access where users only see data for the active intent.
* **Prove intent-aligned use:** Using intents allows organizations to shift from passive logging of who queried data to active assurance that the data was accessed under the specific intent it was approved for.
* **Enable governed self-service:** Users can select approved contexts without manual intervention, and their birthright access is temporarily constrained while in a specific context.
When a [governor creates an intent](/SaaS/govern/secure-your-data/intents/manage-intents.md#create-an-intent), they assign groups to authorize group members' use of the intent, and they assign attributes to the intent that will replace users' attributes when they assume the intent. For example,
1. The group `Analysts` is assigned to an intent called `Fraud detection`, and that intent includes the attribute `Exception:InternalData`.
2. Then, a policy author could create the subscription policy like the one below that uses the intent attribute `Exception:InternalData` to dictate access to data.
> Allow users with attribute `Exception:InternalData` to subscribe to data sources tagged `Research`.
3. Once a member of the `Analysts` group switches to the intent in their native platform, their assigned group remains the same, but their birthright attribute is replaced by the `Exception:InternalData` intent attribute. When they are not acting under the intent, their access to those tables is denied.
For details and examples of when to use group names instead of intent attributes in policies to determine access, see the [Intents reference guide](/SaaS/govern/secure-your-data/intents/intents-reference-guide.md#policy-authoring-strategy).
## Implement intents
{% stepper %}
{% step %}
[**Register your user metadata**](/SaaS/configuration/people/section-contents.md)**:** Connect the IAM your organization already uses to register your users and their metadata in Immuta.
{% endstep %}
{% step %}
[**Create intents**](/SaaS/govern/secure-your-data/intents/manage-intents.md#create-an-intent)**:** Create an intent that can be used in Immuta policies to enforce intent-based access controls.
{% endstep %}
{% step %}
**Author policies**
1. [Author a global subscription policy](/SaaS/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial.md): Once you have created intents, you can author subscription policies to dictate access to data sources based on the context under which users should access data. Consult the [Intents reference guide](/SaaS/govern/secure-your-data/intents/intents-reference-guide.md#policy-authoring-strategy) to determine your policy authoring strategy.
2. [Author a global data policy](/SaaS/govern/secure-your-data/authoring-policies-in-secure/data-policies/how-to-guides/data-policy-tutorial.md): Once you have created intents, you can author data policies to dictate what data users can see at the column, row, and cell level when acting under that intent. Consult the [Intents reference guide](/SaaS/govern/secure-your-data/intents/intents-reference-guide.md#policy-authoring-strategy) to determine your policy authoring strategy.
{% endstep %}
{% endstepper %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.immuta.com/SaaS/govern/secure-your-data/intents.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.