Zilliz Splits Cloud Roles Three Ways—Permissions Still Add Up

In its September 3, 2026 release notes, Zilliz separated organization and project roles within Zilliz Cloud’s three-level organization, project, and cluster access model. The release also introduced custom project roles, group-based assignments, SCIM provisioning for Okta and Microsoft Entra, and role-management APIs.

The immediate migration is designed to preserve existing effective permissions, but the administrative model has changed. Responsibilities now sit at distinct scopes, while direct user assignments and roles received through synchronized groups continue to accumulate rather than override one another.

Each access layer answers a different question

Organization access governs the account boundary: membership, organization roles, billing, authentication settings, and SCIM-synchronized groups. The predefined roles at this level are Organization Owner, Billing Admin, and Public.

Project access determines whether a user or group can work with resources in a particular project. Project Admin, Data Admin, Data Operator, and Data Viewer are predefined roles, while custom project roles can combine platform, compute, and data-access permissions and restrict compute or data access to selected clusters.

Cluster access remains the data-plane boundary. Cluster users, cluster roles, privileges, and privilege groups determine which operations an identity can perform on databases, collections, and other resources inside a cluster.

The operational division is therefore sharper than a hierarchy in which one administrative label explains everything. Billing, organization membership, and security settings belong at the organization layer; project membership and cloud-resource administration belong at the project layer; search, query, insert, and other database operations belong at the cluster layer.

A project member may manage cloud resources without automatically receiving every database privilege. Conversely, a cluster user may work with data without becoming an organization administrator. An access inventory must consequently record the identity, role, and scope together.

Legacy grants are mapped into the new project model

The migration converts Admin to Data Admin, Read-Write to Data Operator, and Read-Only to Data Viewer. Assignments previously limited to particular clusters become custom project roles carrying the same restrictions, and the parallel September release record specifies that effective permissions remain unchanged by this conversion.

Existing Organization Owners retain access to projects they could reach before the update because Project Admin has been assigned on those projects. For future projects, however, the Organization Owner role does not itself supply project access. An owner receives Project Admin when creating a project, while a project created by another member requires an explicit project-role assignment.

This distinction affects automated administration more than console-managed legacy assignments. Terraform and API workflows that manage roles need the new role names and must explicitly assign project access to Organization Owners when that access is intended.

The migration protects continuity; it is not a privilege-reduction exercise. Redundant assignments remain redundant, and a grant that was broader than necessary before conversion is not automatically narrowed merely because it now has a different role name.

SCIM supplies identities, while Zilliz Cloud supplies roles

SCIM provisioning allows Okta or Microsoft Entra to send users, groups, and group memberships into Zilliz Cloud. Group names and membership remain controlled in the identity provider, while organization and project roles are assigned within Zilliz Cloud.

That separation creates two administrative control points. Removing someone from an identity-provider group can withdraw permissions inherited through that group, but it does not remove a role assigned directly to the same user. Revoking the direct role likewise leaves any equivalent or broader group-derived role in place.

The effective-access rules combine direct user assignments with group assignments. In the documented example, a user holding Data Viewer directly and receiving Data Operator through a SCIM group keeps the permissions contributed by both roles.

This union is the main post-migration audit risk. A synchronized group can make team access easier to manage without becoming the exclusive source of authority, so an apparently obsolete direct grant may continue to broaden access silently.

An audit worksheet should expose every permission path

A migration worksheet is most useful when each row represents one identity at one scope, rather than one row representing a person across the entire platform. That structure prevents an organization role from obscuring different project assignments or separate cluster credentials.

• Identity: record the user, synchronized group, or cluster user, with identity-provider memberships listed separately.
• Scope: name the organization, project, or cluster to which the assignment applies.
• Direct assignment: list every role granted directly to the user at that scope.
• Group assignment: list every role inherited from each SCIM-synchronized group at the same scope.
• Migrated role: record the predefined or custom role produced from the legacy assignment.
• Effective permissions: expand and combine the capabilities contributed by every applicable assignment.
• Owner and justification: identify the team responsible for the access and the operational duty it supports.
• Remediation: specify whether the direct grant, group role, or identity-provider membership must change.

Comparisons should remain scope-specific. Billing Admin does not imply project administration, and Project Admin does not automatically confer every cluster data-plane privilege. Within the same scope, however, direct and group-derived roles must be evaluated together before administrators can judge whether access is broader than intended.

The remaining work is tenant-specific

As of the September release, the product-level migration path is defined: legacy roles are mapped, existing owner access is retained through project assignments, and SCIM-synchronized groups can receive organization or project roles. What the automatic process cannot determine is whether every preserved grant is still justified.

Platform teams must establish which direct assignments remain necessary, which synchronized groups reproduce or exceed them, and whether Terraform or API workflows now create explicit project assignments. Until that inventory is reconciled, a successful migration confirms continuity of access—not least privilege.

Also read:

• YouTube Channel Permissions Explained: Give a Team Access Without Sharing Your Password
• YouTube’s AI Avatars Arrive—but Access Is Still Rolling Out
• Nicolas Cage’s AI Warning Endures as Actor Contracts Add New Guardrails