多租户隔离不能依赖LLM：Snowflake 工程师详解 Cortex Agent 安全治理的正确路径

随着企业级AI智能体在2026年逐步落地，如何确保多租户场景下的数据隔离成为关键挑战。Snowflake Cortex Agents允许业务用户用自然语言查询数据，但若将租户隔离托付给大语言模型（LLM），安全风险极高。Snowflake工程师Brian Hess近日撰文指出：安全不应依赖prompt engineering，而应借助Snowflake原生的治理原语——RBAC、行访问策略（RAPs）和会话属性——在物理层面限制Agent的权限。

Cortex Agents通过生成SQL并在Snowflake会话中执行来响应查询。如果仅依赖LLM在每次查询中自动添加正确的WHERE子句，一旦模型遗漏或出错，租户数据就可能被越权访问。因此，治理必须在Snowflake内部强制执行，而非寄希望于Agent的智能。

Hess将多租户应用划分为三类：共享访问、按用户访问和按租户访问，并针对每种场景给出了Cortex Agent的集成方案。

共享访问是最简单的情况。所有访问者通过应用自身的身份验证后，以单一服务用户（service user）的身份连接Snowflake。Cortex Agent直接使用该用户的凭据调用API，继承其所有权限，无需特殊处理。

按用户访问要求每个访问者拥有独立的Snowflake用户身份。通过External OAuth进行身份验证，应用将OAuth token转发至每次Snowflake API调用（包括Cortex Agent run），Snowflake验证token后以该用户的身份执行操作，RBAC和RAPs自动生效。

按租户访问最为复杂，因为访问者没有Snowflake身份，但数据必须按租户隔离。Hess提出了三种模式：

模式A：每个租户一个用户。为每个租户创建Snowflake用户，并在多租户表上应用以CURRENT_USER()为键的行访问策略。管理成本较高，需要处理凭据轮换和用户生命周期。

模式B：每个租户一个角色。使用单一服务用户持有所有租户角色的授权，每次请求时通过USE ROLE切换角色，行访问策略以CURRENT_ROLE()为键。在Cortex Agent API调用中，通过设置X-Snowflake-Role header指定租户角色，并确保服务用户没有默认secondary roles，防止回退。

模式C：租户会话属性。无需创建任何Snowflake对象，通过SET_SYS_CONTEXT()在会话中设置不可变的会话属性（使用保留命名空间SNOWFLAKE$SESSION_ATTRIBUTES），行访问策略以该属性为键。此模式管理最轻量，但需要应用在每次请求中正确设置属性。

Hess提供了包含表、RAPs和cURL命令的完整示例设置（链接见原文），帮助开发者快速上手。他强调，无论选择哪种模式，核心原则是不能将安全责任交给LLM，而应利用Snowflake已有的治理基础设施，从架构层面确保多租户隔离。

对于企业而言，在部署Cortex Agent时，需要根据自身多租户模型、运维能力和安全要求选择合适方案。角色租户模式在灵活性和管理成本之间取得平衡，而会话属性模式则适合追求极简管理的场景。无论如何，将治理嵌入数据库层而非应用层，才是长久之计。