用户、群组与角色
用户、群组与角色
访问管理应使每位成员仅获得完成工作所需的最小权限。Admin 定义部署范围的边界；Curator 管理受群组范围限制的 Agent、连接器和文档集，而 MCP/OpenAPI Actions 始终受所有者范围限制。
角色
管理用户
Admin 应仅通过部署提供的用户管理控制项添加、移除或更新成员。在授予访问权限前确认成员身份及其预期职责；不再需要时及时移除访问权限，并定期检查不活跃账号。
可见的用户管理控制项取决于部署配置和身份设置。不要因为某个部署显示某个菜单，就假定其他部署也已启用它。
管理群组
当多位成员需要相同资源访问权限时使用群组。为群组使用能明确识别用途的名称，保持成员关系最新；如果更小的群组或单独共享已足够，不要使用过于宽泛的群组。
群组用于组织访问分配；它们不会取代部署的角色边界，也不会取代已连接服务自身的权限检查。
共享资源
向预期用户或群组共享已获批准的 Agent 或其他可用资源，然后以该受众成员身份验证最终体验。工作结束或受众变化时，及时移除共享。
共享资源会让所选受众使用其已批准的配置，但不会授予该受众 Admin 权限、允许其编辑资源，或提供对已连接服务的不受限访问。
Curator 边界
Curator 可以管理自己负责群组内的 Agent、连接器和文档集；Global Curator 可以管理自己所属群组内的这些群组资源。两类 Curator 都可以创建 MCP/OpenAPI Actions，但只能修改、删除自己创建的 Action 或维护其受保护凭据；Global Curator 身份不会扩大 Action 所有权。
Curator 可以把当前可用的 Action 附加到自己有权编辑的任意 Agent。修改他人 Action、部署级模型、Index Settings、组织级集成或安全、Usage 及组织范围访问规则时，需要由 Admin 操作。
验证访问权限
为每个预期角色或群组使用有代表性的账号测试访问。确认预期成员可以找到并使用已共享资源、共享范围之外的成员无法使用，并确认 Curator 除非被明确授予 Admin 角色，否则无法进入部署范围的设置。