You're correct that groups in Permit.io are tenant-scoped (1) . When creating groups, you specify a

group_tenant

parameter , and when assigning users to groups, you also specify the tenant . For cross-tenant group management, your proposed ABAC approach with intersection checking is indeed a solid solution. The documentation shows you can implement this pattern using custom attributes (2) . Here's how you could implement the intersection check using custom Rego code:

package permit.custom
import <http://future.keywords.in|future.keywords.in>

# Default value if no conditions are met
default custom_user_attributes["has_intersection"] = false

# Set to true if there's an intersection between user and resource attributes
custom_user_attributes["has_intersection"] := true {
 # Convert attributes to sets for intersection testing
 user_attr_set = {x | some x in data.users[input.user.key].attributes["attr_in_user"]}
 res_attr_set = {x | some x in input.resource.attributes["attr_in_resource"]}
 # Check if there's at least one common value
 count(user_attr_set & res_attr_set) > 0
}

You could adapt this to check for group membership by: 1. Storing a

groups

array attribute on both users and tenants 2. Using the intersection pattern to check if any groups match between the user and tenant This ABAC approach gives you the flexibility to manage cross-tenant groups without being constrained by the tenant-scoped nature of the native Groups API . You'd manage the group assignments through user and tenant attributes rather than the Groups API itself (3) .

To learn more, see the sources I considered: [[1] Groups API](https://docs.permit.io/api/rebac/groups) [[2] ABAC Design Patterns](https://docs.permit.io/how-to/build-policies/abac/patterns) [[3] Sync Data into your App](https://docs.permit.io/overview/sync-applications-data)

For ABAC-based cross-tenant groups, you would use ​*User Sets*​ (dynamic roles) combined with ​*Condition Sets*​ to assign permissions (1) . Here's how to implement role assignments for your ABAC groups: 1. Create User Sets (Dynamic Roles) User Sets group users based on attribute conditions . For your cross-tenant groups, you'd create User Sets that check for group membership:

{
  "allOf": [
    {
      "user.groups": {
        "array_contains": "support_team"
      }
    }
  ]
}

(2) 2. Create Condition Sets for Permissions Condition Sets combine User Sets with Resource Sets to grant permissions . They require three elements: • ​*User Sets*​ - the users affected by the policy • ​*Resource Sets*​ - the resources affected by the policy • ​*Permissions*​ - the action and resource to grant permission to Here's an example from the documentation:

resource "permitio_condition_set_rule" "allow_safeowners_large_transactions" {
  user_set = permitio_user_set.Safe_Owners.key
  resource_set = permitio_resource_set.Large_Transaction.key
  permission = "Transaction:create"
  depends_on = [permitio_resource_set.Large_Transaction, permitio_user_set.Safe_Owners]
}

3. Sync Group Attributes You'd sync the

groups

attribute to users when they're created or updated :

await permit.api.users.update(key, { attributes: { groups: ["support_team", "enterprise_clients"] } })

This approach lets you define role-like permissions through User Sets that check group membership attributes, effectively creating cross-tenant "roles" for your ABAC groups without being limited by tenant boundaries (3) (1) .

To learn more, see the sources I considered: [[1] Create an ABAC Policy](https://docs.permit.io/overview/setup-attribute-based-access-control) [[2] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde) [[3] ABAC Design Patterns](https://docs.permit.io/how-to/build-policies/abac/patterns)