You're on the right track thinking about Groups and Account resources. Permit's Groups API is designed for exactly this B2B scenario where you want to manage permissions at an account level without syncing all relationships (1) . Here's how you can model this cleanly: Using Groups for Account-Level Management The Groups API allows you to create groups that represent your Account resources, then assign both users and resource instances to these groups . When you assign roles to a group, they automatically cascade to group members through role derivation . For example, you can create an account group and assign resources to it:

curl '<https://api.permit.io/v2/schema/{project_id}/{env_id}/groups>' \
  -H 'authorization: Bearer API_SECRET_KEY' \
  --data-raw '{"group_instance_key": "account-123", "group_resource_type_key": "accounts", "group_tenant": "default"}'

Then assign users to that account group with roles:

curl -X PUT \
'<https://api.permit.io/v2/schema/{project_id}/{env_id}/groups/{group_resource_type_key}/users/{user_id}>' \
  -H 'authorization: Bearer API_SECRET_KEY' \
  --data-raw '{"tenant":"business"}'

JIT Checks with Account Context For your JIT ABAC approach, you can pass the Account key as an attribute during your permission checks. Since you have the Account key readily available, you can include it in the resource attributes:

const isAuthorized = await permit.check(
  {
    key: "user-id",
    attributes: {
      // user attributes
    }
  },
  "action",
  {
    type: "resource-type",
    attributes: {
      account: "account-123"  // Your Account key
    }
  }
) ;

(2) Automated Role Derivation The Groups API automatically creates role derivations (1) . When you assign a role to a group, it creates: • A role derivation from the group member role to resource roles • Relations between the group and resources • Automatic permission inheritance for new members added to the group This means you don't need to sync all individual relationships - just the group memberships and the Account association. Alternative: Resource Instance Approach You could also model the Account as a resource with resource instances, then use resource instance roles (3) :

await permit.api.roleAssignments.assign({
  role: "AccountAdmin",
  tenant: "default",
  resource_instance: `Account:${accountId}`,
  user: "user-id"
}) ;

This gives you account-level role assignments without needing to sync all child resource relationships. The key insight is that Groups handle the relationship management for you, while ABAC attributes let you pass the Account context at check time without pre-syncing everything.

To learn more, see the sources I considered: [[1] Groups API](https://docs.permit.io/api/rebac/groups) [[2] Fine-Grained Keycloak Authorization with ABAC and ReBAC](https://www.permit.io/blog/fine-grained-keycloak-authorization-with-abac-and-rebac) [[3] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde)

I’m just trying avoid syncing all my application state needlessly right now.