[3.3] Add plugin-owned AI resource visibility authorization APIs

[KomachiSion]

Motivation

Nacos AI resources already have owner and scope metadata, and the visibility plugin contract is used by AI resource read/write paths. The current default visibility behavior is useful but still incomplete for team collaboration:

• global administrators can read/write all AI resources;
• the resource owner can read/write the resource;
• PUBLIC resources are readable by non-owners;
• PRIVATE resources are not visible to other users unless an explicit permission check succeeds.

The code and specs already reserve an explicit authorization model:

• DefaultAiVisibilityService checks the explicit resource permission @@visibility/{namespaceId}/{resourceType}/{resourceName} for single-resource access.
• VisibilityService.adviseQuery(...) returns AuthorizedResources so list/search queries can include explicitly authorized resources.
• DefaultVisibilityAdvisorConverter already has the hook to include authorizedResourceNames, but the default visibility service currently leaves the authorized resource list empty.
• The visibility plugin spec says visible resources may be owner-only, public-readable, or explicitly authorized, and that list/search APIs must apply visibility before count and pagination.
• The default auth plugin spec documents the visibility permission resource format and says the default implementation should support explicit visibility permission.

What is missing is a plugin-owned management API and implementation for granting a specific user read/write permission to a specific AI resource.

This should be completed in 3.3.

Problem

Today, the default AI resource visibility model effectively behaves as owner/admin/public-read for most user workflows. There is no clear API for a resource owner or administrator to grant another user read or write permission on one AI resource.

This blocks common collaboration scenarios, for example:

• user alice owns a private skill and wants user bob to read it;
• user alice owns a private agentspec and wants user bob to update drafts or publish versions;
• a team wants to keep a resource private while granting a small set of users access;
• list/search APIs should show resources that the caller is explicitly authorized to read, not only public resources and resources owned by the caller.

A key design constraint: the authorization API should belong to the plugin implementation, not to the generic AI resource API.

Generic AI resource APIs should continue to manage resource metadata, versions, lifecycle, scope, labels, and content. They should not know how a specific visibility/auth plugin stores grants, roles, users, or external authorization state.

Desired Capability

1. Add plugin-owned AI resource visibility authorization APIs

Add v3 APIs owned by the default auth/visibility plugin implementation. The exact path can be finalized in design, but it should live under the plugin API surface such as /v3/auth/..., not under /v3/admin/ai/*, /v3/console/ai/*, or generic AI resource controllers.

The API should support at least:

• grant read permission for a user on one AI resource;
• grant write permission for a user on one AI resource;
• revoke read/write permission;
• list current grants for one AI resource;
• optionally list AI resources explicitly granted to the current user or a target user, if needed by the console.

The model should include:

• namespaceId;
• resourceType, such as mcp, prompt, skill, or agentspec;
• resourceName;
• grantee identity, initially user-based;
• action: r, w, or a compatible rw representation;
• operator and audit-friendly metadata if available.

2. Keep the API boundary plugin-specific

The default nacos auth/visibility plugin can implement these APIs using its RBAC/permission storage, for example by writing permissions with resource:

@@visibility/{namespaceId}/{resourceType}/{resourceName}

Other visibility/auth plugins should be free to implement their own API or report that grant management is unsupported. The generic AI resource service should only call the VisibilityService SPI for validation and query advice.

3. Complete runtime authorization behavior

After a grant is created:

• single-resource read should allow a user with explicit r permission;
• single-resource write should allow a user with explicit w permission;
• list/search/count should include explicitly authorized resources through AuthorizedResources;
• explicit read grants should not imply write permission;
• write permission should be at least as strict as read permission, as required by the visibility plugin spec;
• read-denied single-resource access should continue to hide existence when the API contract requires not found;
• write-denied operations should return access denied.

4. Define who can manage grants

The first-stage 3.3 behavior should be explicit and conservative. Suggested rule:

• global administrators can manage grants for any AI resource;
• the resource owner can manage grants for that resource;
• users with explicit write permission can modify the resource, but whether they can delegate grants should be a deliberate plugin policy, not an accidental side effect.

The selected rule should be documented in the default auth/visibility plugin spec.

5. Console integration

If the console exposes AI resource sharing or authorization management, it should call the plugin-owned API and handle "unsupported by current plugin" gracefully.

The console should not hard-code default plugin storage details into generic AI resource pages.

6. Specs and tests

Update the affected specs:

• visibility plugin spec;
• default auth plugin spec;
• AI resource model/lifecycle specs if they need to clarify the boundary between resource metadata and visibility grants;
• v3 API surface spec for the new plugin-owned API family.

Testing should cover:

• grant/revoke API validation and authorization;
• owner/admin grant management rules;
• explicit read and write checks in DefaultAiVisibilityService;
• list/search/count including explicitly authorized resources before pagination;
• no leakage of private resources without explicit permission;
• console/API behavior when the selected visibility plugin does not support grant management.

Because this adds HTTP API behavior, the API integration test scenario matrix and coverage registry should also be updated according to the repository API IT rules.

Non-goals

• This issue should not move grant management into generic AI resource controllers.
• This issue should not require every custom visibility plugin to adopt the default plugin storage model.
• This issue should not make PUBLIC resources writable by all users.
• This issue should not replace the existing owner/scope visibility model.

Acceptance Criteria

• The default plugin provides a clear v3 API to grant/revoke/list user read/write access for one AI resource.
• The API is implemented under the plugin-owned auth/visibility API surface.
• Explicitly granted users can read/write the target AI resource according to the granted action.
• List/search/count APIs include explicitly readable resources correctly.
• Owner/admin grant management rules are documented and tested.
• Generic AI resource APIs remain storage-agnostic and delegate visibility decisions to the visibility plugin.

[KomachiSion]

assign myself first, If anyone want to do this, prefer to assign to volunteer.

[Zhengcy05]

How is the progress? I'd like to try if possible, please assign it to me. Or is there anything I can help with? :)

[KomachiSion]

@Zhengcy05 There is no progress for me, If you want to do, I will assign to you.