Snowflake为CoCo推出受限会话范围，限制AI Agent权限

无需重写角色层级即可限制智能体行为：受限会话范围

受限会话范围现已在 Snowflake CoCo 中可用！

直到现在，当智能体代表你行动时，它会继承你的全部权限集。如果你持有 ACCOUNTADMIN，智能体也拥有该权限。如果你的角色允许写入生产环境，智能体也可以写入生产环境。你自己的操作几乎从不如此广泛，而智能体的操作范围更窄，但之前的继承关系是全有或全无。

受限会话范围（Restricted Session Scope, RSS）是一种权限上限，用于限制智能体代表用户能执行的操作，它被定义为一个包含权限范围和角色范围的 YAML 文档。

它正在改变数据团队获批在生产账户中使用智能体的方式，而无需重写角色层级。以下是四点需要了解的内容。

上限模型：RSS 只做限制，不做授权

当有人要求你限制智能体时，直觉反应是创建一个权限更少的服务角色。然后你维护两套并行的权限系统，并希望它们保持同步。

RSS 并不取代 RBAC。它作为上限位于其上。当智能体处于活动状态时，有效权限是用户 RBAC 权限与活动 RSS 的交集，并且 RSS 永远不能授予用户通过其角色尚未拥有的权限。

该属性仅在智能体活动时生效，即 SYS_CONTEXT(‘SNOWFLAKE$CURRENT’, ‘IS_AGENT_ACTIVATED’) 返回 TRUE 时。当没有智能体活动时，它会被忽略，用户保留完整的 RBAC 权限。用户保留其拥有的所有权限。但代表用户的智能体并不保留。

安全团队真正想要的控制是常驻和集中的，而不是每个开发者自行选择加入。

管理员在会话策略上设置 AGENT_RESTRICTED_SESSION_SCOPE，然后将该策略附加到账户或特定用户。最简单的版本引用一个 Snowflake 预定义范围：

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

有三个预定义范围。SNOWFLAKE$DATA_READ 是对数据对象的只读访问。SNOWFLAKE$DATA_READ_WITH_AI 在此基础上增加对 AI 和智能体对象的使用权，并特意排除了存储过程，因为它们可能以所有者权限运行，无法保证只读执行。SNOWFLAKE$DATA_READ_PROGRAM_USAGE 则允许调用 UDF 和存储过程。

对于更具体的需求，可以创建一个 RSS 对象并通过完全限定名称引用它，或者将 YAML 内联嵌入策略中。常见的模式是：所有地方可读，仅沙盒可写，并完全阻止提升角色：

CREATE RESTRICTED SESSION SCOPE mydb.governance.agent_scope AS $$
privilege scopes:
  allowed privileges:
    - privileges: [data read]
    account: [all]
    - privileges: [data write]
    databases: [SANDBOX_DB]
    - privileges: [program usage]
    account: [all]
role scopes:
  blocked roles: [ACCOUNTADMIN, SYSADMIN, SECURITYADMIN]
  allow role switching: false
$$;

在部署前值得了解一个优先级细节。如果用户具有用户级会话策略，则该策略对于该用户完全覆盖账户级策略。两者不会合并。

从命令行限制你自己的会话

等待账户级策略并不总是可行，有时最需要防护栏的人正是持有危险角色的人。

CoCo CLI 提供完整的配置流程。运行 /guardrails 并应用现有的 RSS 定义，启用具有预定义范围的 SQL 只读模式，或者构建一个命名范围，并在配置时提供实时 YAML 预览。命名定义存储在个人数据库 USER$<username>.RSS 中，以便重用：

cortex — with-restricted-session-scope=PRODUCT_RSS

`/guardrails status` 显示活动限制，`/guardrails-guide` 指导你完成流程。CoCo 无法自行应用或移除限制。应用 RSS 是工具链中的显式操作，正是为了让智能体无法自行解除其上限。

如果管理员上限也生效，Snowflake 会强制取两者的交集。用户不能通过 CLI 授予智能体超过管理员策略允许的访问权限。

需要了解的事项

权限上限是一种安全控制，安全控制的边界应该明确说明，而不是事后发现。

在此预览版中需要规划的五件事：

• 表面支持仍在完善中。CoCo CLI 提供通过 /guardrails 实现的完整配置流程，并且你可以在 Snowsight 中运行受限的只读聊天。其余 CoCo 表面的支持正在进行中。管理员管理的 RSS 适用于会话策略覆盖的、智能体活跃的会话，无论客户端如何。
• SPCS 会移除该上限。 如果智能体调用在 Snowpark Container Services 中运行的作业或应用程序，RSS 将不再适用于该工作负载。Snowflake 正在积极解决这一差距。
• 仅对角色列表直接授权。 角色允许列表和阻止列表适用于直接授予用户的角色。仅通过嵌套继承可达的角色不会因命名而被抑制。
• 无法被提升。一旦 RSS 对智能体活动生效，它不能放宽以授予智能体超过活动上限允许的权限。
• 智能体上下文并非普遍适用。当 IS_AGENT_ACTIVATED 为 TRUE 时，上限启动，这通过 Snowflake MCP 服务器、IS_AGENTIC = TRUE 的 OAuth 安全集成或 SERVICE_AGENT 用户实现。通过 REST 或 SDK 使用密钥对或 PAT 认证连接的智能体目前不会激活它。

RSS 控制智能体可以访问哪些数据库和操作。它不控制其中哪些列值可见，因此请配合基于 IS_AGENT_ACTIVATED 的掩码策略使用。

下一步是什么？

最快感受这种方式的方法是使用 CoCo CLI。运行 /guardrails，使用 SNOWFLAKE$DATA_READ_WITH_AI 限制会话，然后让智能体写入内容。拒绝来自 Snowflake，而不是来自你需要信任的提示词。一旦你知道所需的形式，就将其构建为命名范围，并在未来会话开始时使用

cortex --with-restricted-session-scope=<name>

这样从第一条消息起上限就生效。如果你持有 ACCOUNTADMIN 或 SYSADMIN，这也是使 /bypass 合理运行的原因。

当您准备好进行静态控制时，您在CLI中构建的相同作用域可以通过ALTER USER附加到试点组的会话策略，然后扩展到账户。

查看更多文档：https://docs.snowflake.com/en/LIMITEDACCESS/security/agent-restricted-session-scope

试试Snowflake CoCo！

限制Snowflake中的AI代理权限：受限会话作用域最初发表于Snowflake Builders Blog：数据工程师、应用开发者、AI与数据科学在Medium上，人们通过突出显示和回应这个故事来继续对话。