cmind/platform/v1/capability_service.proto
Package: cmind.platform.v1
Messages
GetPlatformCapabilitiesRequest
GetPlatformCapabilitiesResponse
One field per platform relation in proto/authz/model.fga. The three are independent: a model_admin holds can_manage_models without can_manage_tenants, so callers must gate each surface on its own field rather than on any-of.
| Field | Type | Number | Description |
|---|---|---|---|
canManageTenants | bool | 1 | Administer tenants and read cross-tenant usage (root_admin). |
canManageModels | bool | 2 | Deploy and administer models platform-wide (model_admin or root_admin). |
canManageAgentTools | bool | 3 | Administer platform-owned MCP servers and preset agents (agent_tool_admin or root_admin). |
Services
CapabilityService
CapabilityService answers questions about the calling principal's own standing at platform scope. It holds no resources of its own — it exists so a client can ask "what may I do?" directly instead of inferring it from how some other RPC failed.
GetPlatformCapabilities
GetPlatformCapabilities reports which platform-scoped grants the caller holds. Every logged-in caller may ask; the answer lives in the response body, so an unprivileged caller gets all-false rather than an error. That distinction is the whole point of this RPC. The alternative — calling a privileged RPC and reading PermissionDenied as "no" — is unsound for the list RPCs that gate on member and filter per object: they answer 200-with-an-empty-list for both "you hold nothing here" and "you may not be here at all", and which of the two you get depends on hand-written handler code rather than on the fga_authz annotation. A client that guesses wrong fails open into an admin surface.
Request: GetPlatformCapabilitiesRequest
Response: GetPlatformCapabilitiesResponse