Snowflake Proposes Five-Dimensional Governance Framework for AI Agents

智能体在企业落地的核心挑战是权限治理——其自动执行能力可能放大数据越权与泄露风险。Snowflake 提出五维控制框架，聚焦身份识别、权限最小化、数据保护、资源限制与行为审计。其中，智能体身份识别是策略生效前提，支持对 Cortex Agents 等主流智能体会话的自动识别与上下文透传。

智能体身份需独立识别，而非混同于用户会话；权限控制必须基于最小必要原则动态授予；敏感数据在智能体调用链中易被跨工具聚合泄露。

适合数据平台工程师、AI基础设施负责人、企业安全架构师阅读。

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

AI 智能体不只是回答问题。它们还会查询数据、调用工具，并替你执行操作。问题在于，智能体代表你行动时，也可能继承你的访问权限。这带来了治理挑战：如何在赋予智能体完成任务所需权限的同时，避免授予超出需要的权限？

人可以查看敏感数据，并自行判断如何处理。智能体则可能通过汇总敏感数据、将其传递给其他工具，或把数据呈现给无权访问的人，大规模暴露敏感信息。

Snowflake 提供了五项控制措施来管理这类行为：识别智能体、限制其权限、保护敏感数据、控制资源消耗，并审计其行为。

这五项措施共同回答了五个问题：智能体是谁？它能做什么？它能看到什么？它能消耗多少资源？它做过什么？

识别：智能体身份

将智能体连接到获准使用的工具，只解决了部分问题。智能体接入 Snowflake 后，你还需要知道当前会话中执行操作的是智能体，而不只是用户，才能应用恰当的控制措施。

智能体身份功能可以识别由智能体参与的会话，并将这一上下文传递到现有的策略与审计界面中。对于来自 Snowflake 支持的入口的会话，Snowflake 会自动识别智能体，包括 Cortex Agents、Cortex 轻量级智能体、CoCo 客户端、CoWork，以及由 Snowflake 管理的 MCP 服务器。

对于外部智能体，Snowflake 支持两种识别方式：

• 为需要独立 Snowflake 身份和权限的自主智能体创建 SERVICE_AGENT 用户。该用户可以通过工作负载身份联合、密钥对身份验证或程序化访问令牌进行身份验证；
• 对代表最终用户执行操作的委托智能体，在自定义 Snowflake OAuth 或 External OAuth 安全集成上设置 IS_AGENTIC = TRUE。

Snowflake 识别出智能体参与的会话后，现有控制措施便可以使用这一上下文：

• SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') 在智能体处于活动状态时返回 TRUE。在策略逻辑中使用时，请将结果转换为 BOOLEAN；
• QUERY_HISTORY.agent_type 用于识别直接发出查询的智能体，取值可以是 CORTEX_AGENT、CORTEX_LITE_AGENT 或 EXTERNAL_AGENT；
• ACCESS_HISTORY.agents_info 记录参与对象访问的智能体，并可呈现嵌套调用链中的多个智能体。

智能体身份回答了传统用户和角色信息无法回答的一个问题：当前会话中是否有智能体参与？数据策略、会话限制和审计查询随后都可以使用这一上下文。

限制：为智能体权限设定上限

识别智能体，并不会自动减少它能执行的操作。当智能体代表用户行动时，它可能继承用户的权限，即使任务只需要其中一小部分。这就带来了授予智能体超出所需访问权限的风险。

智能体受限会话范围现已正式发布，可为智能体参与的会话设定权限上限。它与 RBAC（基于角色的访问控制）协同工作：可以减少智能体可用的权限，但不能授予用户本身不具备的权限。管理员可以通过会话策略应用预定义范围：

CREATE SESSION POLICY governance.agent_readonly_policy  AGENT_RESTRICTED_SESSION_SCOPE =    'SNOWFLAKE$DATA_READ_WITH_AI';ALTER ACCOUNT SET SESSION POLICY  governance.agent_readonly_policy;

复制代码

智能体处于活动状态时，这一预定义范围允许读取数据、发现对象，以及使用获准的 AI 相关对象，同时禁止写入、DDL、授权操作和存储过程。没有智能体参与时，受限范围会被忽略，用户仍按常规 RBAC 权限执行操作。

如果预定义范围无法满足需求，也可以针对特定工作流设定更严格的边界：

• 允许读取生产环境数据，但将写入操作限制在沙箱或个人数据库中；
• 禁止在智能体会话期间将指定的特权角色用作主角色或次要角色（如果需要严格限制，请使用允许列表，因为角色继承仍然生效）；
• 禁止切换角色；
• 将数据访问限制在获准的数据库和架构中；
• 允许使用指定的智能体、函数或其他程序化对象。

RBAC 与智能体受限会话范围之间的区别很重要：RBAC 定义用户可以执行哪些操作；智能体受限会话范围则定义智能体代表该用户行动时可以执行操作的权限上限。这与数据保护不同。会话范围控制智能体可以访问哪些位置、执行哪些操作；数据策略则控制智能体到达相应位置后可以看到哪些值。

保护：让数据策略识别智能体

即使设置了权限上限，智能体仍可能访问用户有权访问的数据。这正是数据策略发挥作用的地方。例如，当智能体处于活动状态时，现有的掩码策略可以返回经过掩码处理的值，即使用户的角色本来可以查看原始值：

CREATE OR REPLACE MASKING POLICY email_agent_maskAS (val STRING) RETURNS STRING ->  CASE    WHEN SYS_CONTEXT(      'SNOWFLAKE$CURRENT',      'IS_AGENT_ACTIVATED'    )::BOOLEAN = TRUE      THEN '********'    WHEN CURRENT_ROLE() IN ('ANALYST')      THEN val    ELSE '********'  END;

复制代码

使用 ANALYST 角色的人可以查看原始电子邮件地址；智能体参与的会话则会收到经过掩码处理的值。

同一上下文还可以用于：

• 掩码策略
• 行访问策略
• 投影策略
• 聚合策略
• 联接策略

提示词可以要求智能体不要暴露敏感值。数据策略则可以在数据层决定智能体能否访问该值；只要 Snowflake 识别出当前会话有智能体参与，这项控制就会生效。

控制：管理 AI 资源消耗

一次用户请求可能触发多次模型调用、检索步骤和工具调用，因此产生的 AI 资源消耗远超请求本身所显示的规模。Snowflake 的单用户配额现已正式发布，管理员可以监控并限制单个用户在 AI Functions、Cortex Agents、CoCo 和 CoWork 中消耗的 AI credits。

使用单用户配额，团队可以：

• 为范围内的每位用户设置每日、每周或每月的 credit 限额；
• 为所有用户设置相同配额，或使用标签为选定的用户群组设置配额；
• 在实际消耗或预计消耗超过阈值时，通知用户和管理员；
• 在用户达到设定限额时，自动阻止新的 AI 请求；
• 在配额周期重置或提高限额后解除阻止；
• 在 Snowsight 中查看使用率、支出和执行状态。

这为开发者测试和运行 AI 工作流设定了明确边界，同时也让管理员能够控制资源消耗，无需逐一手动检查每条提示词或每次部署。

两者的区别很简单：访问策略控制请求是否获准；配额控制请求可以产生多少 AI 资源消耗。

审计：检查智能体活动

最后一个问题关乎责任追溯：智能体执行操作后，如何确认它做了什么？**识别智能体后，可以通过 Snowflake 的历史记录视图调查其活动。

QUERY_HISTORY.agent_type 用于识别直接发出查询的智能体。你可以通过以下语句查看近期记录的智能体活动：

SELECT  query_id,  user_name,  role_name,  agent_type,  start_time,  query_textFROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYWHERE agent_type IS NOT NULLORDER BY start_time DESC;

复制代码

通过这些信息，你可以了解：

• 哪些已识别的智能体发出了查询？
• 它们使用了哪些用户和角色？
• 活动发生在什么时间？
• 智能体发出了什么 SQL？

需要注意一个重要限制：这条查询只能找到 Snowflake 已识别并记录为由智能体发起的活动。它无法发现环境中所有未知的智能体或未注册的工具。

在调查对象级别的活动时，ACCESS_HISTORY.agents_info 会记录访问 Snowflake 对象时参与其中的智能体。与查询历史中单一的 agent_type 值不同，agents_info 可以呈现嵌套调用链中的多个智能体。

两个视图适用于不同的问题：

• 使用 QUERY_HISTORY 调查直接发出查询的智能体；
• 使用 ACCESS_HISTORY 了解访问 Snowflake 对象时有哪些智能体参与。

身份信息可以确认智能体参与了操作；智能体受限会话范围可以限制它能做什么；数据策略可以控制它能看到什么；历史记录则展示发生过什么。

将各项措施结合起来

设想一个智能体需要汇总敏感的交易信息。分析师拥有广泛的生产环境访问权限，但智能体完成任务并不需要全部权限。目标是在不让智能体不受限制地访问分析师可访问的所有内容的情况下，允许它获取完成任务所需的信息。

对于自主工作负载，可以为智能体配置 SERVICE_AGENT 身份；对于委托访问，可以使用 IS_AGENTIC = TRUE 的 OAuth 集成，再结合智能体受限会话范围和能够识别智能体的数据掩码策略。

智能体可以检索获准访问的数据，并且只能将结果写入获准的位置。之后，管理员可以使用 QUERY_HISTORY.agent_type 和 ACCESS_HISTORY.agents_info 检查智能体执行了哪些操作、访问了哪些对象。

智能体开始自动运行时

当智能体在你不在场时运行，这些控制措施会更加重要。CoCo 自动化是一条已保存的提示词，可以按计划运行。它能在无人值守的情况下运行，并为每次运行创建一个对话线程，方便你之后检查智能体的消息、工具调用、运行结果和最终回复。适合交由智能体处理的工作，通常需要推理或判断，而不是执行静态宏：

• 排查昨夜的故障。按可能原因分组需要判断，不能只靠 GROUP BY；
• 解释某项指标为何变化。查询可以得出数值；要解释变化，还需要综合多种信号，并判断哪些信号发挥了作用；
• 检查数据新鲜度和质量。数据缺口是否重要取决于具体情境，固定阈值无法涵盖所有情况。

CoCo 自动化在 Snowflake 内部的 Snowflake 托管沙箱中运行，而不是在你的设备上运行。它无需使用仓库，目前处于公开预览阶段。自动化也适用相同的治理措施。每次运行都以创建者的身份和调用者权限执行，并遵循基于角色的访问控制、行访问策略和掩码策略。每次运行都会使用该用户的默认角色和默认次要角色，而不是创建自动化时处于活动状态的角色。为缩小潜在影响范围，请谨慎配置这些默认设置，并且只附加工作流所需的资源。任务历史记录可以确认运行是否完成；对话线程则展示智能体实际执行了什么。

如果你想了解哪些重复性工作适合交给智能体处理，以及如何设置自动化，请阅读我究竟应该用智能体自动化哪些工作？