Intents

Understand the value and flexibility intents provide with context-aware access control

Public preview: This feature is being released incrementally to customers on a rolling basis. If the feature is not available in your tenant yet, contact your Immuta representative to enable it.

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:

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

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

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.

	Clinical Trials Restricted	Patient data Restricted
User A entitlements Group: Product team Attribute: Project:Research	✅	✅
User B entitlements Group: Product team Attribute: Clearance level:Secret	❌	❌

This birthright access approach gives these users all access or no access. There is no temporary elevation of access without intent-based access control. See the Intents reference guide 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.

	Clinical Trial A Research, sensitive	Clinical Trial B Research, sensitive
User A entitlements Group: Product team Attribute: Project:Research	✅	✅
User B entitlements Group: Product team Attribute: Project:Research	✅	✅

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. See the Intents reference guide 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, 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.

Implement intents

1

Register your user metadata: Connect the IAM your organization already uses to register your users and their metadata in Immuta.

2

Create intents: Create an intent that can be used in Immuta policies to enforce intent-based access controls.

3

Author policies

1. Author a global subscription policy: 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 to determine your policy authoring strategy.
2. Author a global data policy: 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 to determine your policy authoring strategy.