AI智能体代用户行事，企业治理要补哪几道口子？
如何在赋予智能体完成任务所需权限的同时，避免授予超出需要的权限？
2026 年，企业级应用里的智能体会出现哪些实质突破？下载《2026 年 AI 与数据发展预测》白皮书即可看到专家的一手判断，抢先了解新的工作方式。
智能体不光是回答问题，它还会查数据、调工具，甚至替你动手办事。麻烦在于，它代表你行动的时候，你的访问权限也可能被它一并继承。治理难题随之而来：怎样让它拿到干活必需的权限，又不至于多给？
人看到敏感数据，会自己掂量该怎么处理。换作智能体，它可能把敏感数据汇总起来、转交给别的工具，或者直接呈现给本无权查看的人，一暴露就是一大片。
针对这类行为，Snowflake 给出了五项控制措施：识别智能体、限制其权限、保护敏感数据、控制资源消耗，并审计其行为。
这五项措施对应五个问题：智能体是谁？它能做什么？它能看到什么？它能消耗多少资源？它做过什么？
识别：智能体身份
把智能体接到获准使用的工具上，只解决了一部分问题。智能体接入 Snowflake 之后，你还得弄清当前会话里执行操作的是智能体，而不只是用户，才能套用恰当的控制措施。
智能体身份功能可以识别出有智能体参与的会话，并把这一上下文送进现有的策略与审计界面。会话如果来自 Snowflake 支持的入口，Snowflake 会自动识别智能体，涵盖 Cortex Agents、Cortex 轻量级智能体、CoCo 客户端、CoWork，以及由 Snowflake 管理的 MCP 服务器。
外部智能体则有两种识别方式：
一是给需要独立 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 托管沙箱里，不在你的设备上。它不需要用仓库，目前处于公开预览阶段。自动化同样受这套治理措施约束。每次运行都按创建者的身份和调用者权限执行，遵循基于角色的访问控制、行访问策略和掩码策略。每次运行用的是该用户的默认角色和默认次要角色，而不是创建自动化时处于活动状态的角色。要缩小潜在影响范围，就得谨慎配置这些默认设置，只挂工作流真正需要的资源。任务历史记录能确认运行有没有完成；对话线程则显示智能体实际做了什么。
想知道哪些重复性工作适合交给智能体，以及自动化该怎么设置，可以去看我究竟应该用智能体自动化哪些工作？
开始使用
先分清智能体的身份。自主运行的工作负载，用 SERVICE_AGENT 来标识；受托代为执行的智能体，则走
IS_AGENTIC = TRUE。SNOWFLAKE$DATA_READ_WITH_AI权限方面也得收紧：可以从起步，也可以自行划定智能体能用的受限会话范围。敏感数据要另加一层防护，可用
IS_AGENT_ACTIVATED同时得让现有策略认得出来这是智能体，而不是普通用户。资源开销也要管住，按需给单个用户设定 AI credit 配额。
最后是审计。QUERY_HISTORY 和 ACCESS_HISTORY 两个视图能查到智能体做过哪些操作、碰过哪些对象。
