一、RLS与Fabric Data Agent、自定义Copilot的核心协同逻辑 #

RLS的生效核心是让数据存储层（语义模型/Warehouse/Lakehouse）感知到当前请求的用户身份，Data Agent和Copilot作为中间层，需要承担传递用户身份上下文的职责：

• Fabric Data Agent：作为前端与Fabric数据存储的代理，不能用固定身份访问数据。必须配置自定义逻辑，提取前端请求中的用户身份信息（比如自定义token里的用户ID、部门），用该身份发起对Fabric数据的查询，触发RLS规则过滤。
• 自定义Copilot：生成查询时不能用自身服务身份，必须绑定当前请求的用户上下文。可以在Copilot的后端逻辑中注入用户身份参数，让生成的SQL/MDX查询自动带上RLS过滤条件，或者调用已经传递用户身份的Data Agent接口，确保查询结果符合用户权限范围。

二、未登录场景的凭据传递与RLS适配 #

未登录场景指用户使用应用自有身份体系（而非Fabric账号），需按以下步骤实现：

1. 前端请求携带自定义凭据：比如JWT Token，内含用户ID、权限角色、部门等核心标识信息。
2. Data Agent解析并映射身份：
   • 解析前端Token，提取用户身份字段（如user_department）。
   • 若使用语义模型：在语义模型中定义基于自定义字段的RLS角色（例如SalesUser角色，过滤条件为Sales.Territory = @UserDepartment），Data Agent调用语义模型查询时，将解析到的user_department作为参数传递，触发RLS自动过滤。
   • 若使用Warehouse/Lakehouse：Data Agent需将用户身份作为过滤条件拼接进SQL，或设置Warehouse会话变量（如SET @CurrentUser = 'xxx'），同时在表的RLS策略中引用该变量（例如CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE Sales.Territory = @CurrentUser FOR Sales）。
3. Copilot适配：在Copilot后端逻辑中同步解析前端凭据，将用户身份参数注入查询生成上下文，确保生成的查询包含RLS过滤逻辑，或直接调用已处理身份的Data Agent接口。

三、服务主体认证模式下的实现 #

服务主体适合后端服务调用场景，实现步骤如下：

1. 配置服务主体权限：给服务主体授予Fabric数据存储的访问权限，同时开启其*身份模拟（Impersonation）*权限，允许它模拟具体用户身份发起查询。
2. 传递用户身份上下文：
   • 语义模型场景：服务主体调用语义模型查询API时，在请求头中添加用户身份标识（如X-MS-USER-ID），或使用Fabric的模拟身份功能，让服务主体以目标用户身份查询，RLS会基于该模拟身份生效。
   • Warehouse/Lakehouse场景：服务主体连接Warehouse后，执行会话变量设置语句（如EXEC sp_set_session_context @key = 'CurrentUser', @value = 'user123'），RLS策略直接引用该变量进行数据过滤。
3. Data Agent与Copilot集成：
   • Data Agent使用服务主体认证访问Fabric数据，每次请求时将前端传递的用户身份注入会话上下文或查询参数。
   • 自定义Copilot通过服务主体调用Fabric接口时，同步注入用户身份上下文，确保查询触发RLS规则。

四、不同存储方案的适配细节 #

• 语义模型：原生支持RLS，是最优选择。只需在语义模型中定义角色和过滤规则，确保Data Agent和Copilot传递用户身份到查询接口，Fabric会自动应用RLS。
• Fabric Warehouse：需手动创建RLS安全策略，依赖会话变量或查询参数传递用户身份，Data Agent和Copilot需在查询时注入这些变量。
• Lakehouse：原生RLS支持有限，建议将Lakehouse数据封装到语义模型后使用RLS，简化权限控制逻辑。

内容的提问来源于stack exchange，提问作者DataNovice