Oct 30, 2026/6 min readCore Platform
Control What AI Agents Can Do in Your Snowflake Sessions
AI agents already operate inside your most sensitive data environments. They authenticate as your users, inherit their roles and execute actions at machine speed. For most tasks, that's what makes them useful. But it also means a single misguided prompt can lead an agent to drop a production table, alter account-level settings, grant itself new privileges or access PII the task never required, all using the privileges the user holds.
Until now, there was no built-in way for an administrator to say: "Agents on this account must operate with a scope of privileges narrower than those held by the user, tailored to the specific task requested" without breaking authentication for that user entirely or re-creating role-based access control (RBAC) just for the agent.
We are excited to announce the general availability of Restricted Session Scopes (RSS). RSS lets administrators and end users define a privilege ceiling that automatically applies whenever an AI agent is active. It can only restrict what agents can do on behalf of the user, never expand user privileges.
Why regular access control is not enough for agents
RBAC works well for human users whose access patterns are predictable and relatively stable.
Agents are different. They reason dynamically, chain actions across systems, and determine what to access at runtime based on the given task that changes with every interaction. A role that is appropriate for the user is not necessarily appropriate for every action the agent takes on their behalf.
This is the direction the industry is moving. Industry guidance increasingly points toward the principle that agent sessions should execute under constrained, task-scoped boundaries rather than inheriting standing user privileges. Static roles create standing access; what agents need is a runtime ceiling that reflects the task, not the identity.
RSS is Snowflake's first step in this direction of task-scoped boundaries. It enforces least privilege for agent sessions without requiring changes to the user's actual role grants or authentication configuration.
How it works
RSS applies to every agent session Snowflake identifies as agentic: Cortex Agents, Snowflake CoCo, Snowflake CoWork, MCP integrations, and external agents that identify themselves as agentic via OAuth (IS_AGENTIC=TRUE) or the SERVICE_AGENT user type. It operates at three levels:
- Account-wide. An administrator sets a session policy with an RSS that applies to every agent session on the account.
- Per-user. An administrator attaches a session policy with an RSS to a specific user, governing all of that user's agent sessions.
- Per-session. An individual user sets their own RSS on a specific CoCo session, restricting what the agent can do for that session only.
Account-wide and per-user admin governance
Administrators create a RESTRICTED SESSION SCOPE object that defines which privileges are allowed and which roles are permitted or blocked. Consider a common scenario: you want agents to read data and use AI functions across the account, allow writes only to a sandbox database, and block the PII governance role so agents cannot unmask sensitive data.
CREATE RESTRICTED SESSION SCOPE governance.policies.agent_safe_scope
AS $$
privilege_scopes:
allowed_privileges:
- privileges: [data read, object discovery, program usage]
account: [all]
- privileges: [data write, object management]
databases: [AGENT_SANDBOX]
role_scopes:
blocked_roles: [ACCOUNTADMIN, SYSADMIN, SECURITYADMIN, DATA_GOVERNOR]
allow_role_switching: true
$$;With this scope, agents can query any table, run AI functions, and build objects in the sandbox database, but they cannot write to production, cannot activate any of the blocked administrative or governance roles, and cannot activate the DATA_GOVERNOR role, which in this example is the role that reveals unmasked PII.
The scope is then attached to a session policy and applied account-wide or to a user. It activates automatically whenever an agent session is detected. No action is required from the end user.
CREATE SESSION POLICY governance.policies.agent_session_policy
AGENT_RESTRICTED_SESSION_SCOPE = 'governance.policies.agent_safe_scope';
ALTER ACCOUNT SET SESSION POLICY governance.policies.agent_session_policy;Per-session: self-service guardrails in CoCo
RSS also works at the individual user level. Users can set their own restrictions on their CoCo sessions.
In CoCo in Snowsight, users can configure restricted scopes directly from the UI. In CoCo Desktop, they click the + button and select Restrict this session. In CoCo CLI, users run /guardrails and select a restricted session scope.
This matters because not every restriction needs to come from the top down. A developer who holds ACCOUNTADMIN but is using CoCo to explore data can set read-only mode before enabling bypass approval. An analyst can block their governance role so the agent can't use that role to unmask PII during an exploratory workflow. The user's self-imposed scope can only downscope any admin-imposed RSS.
What customers are building with RSS
Among private preview participants, we've seen three patterns emerge:
Start with read-only and refine later. Not every organization knows exactly which privileges to restrict on day one. RSS provides a built-in SNOWFLAKE$DATA_READ_WITH_AI scope that enforces read-only access while preserving AI function usage. It is the fastest way to set a meaningful boundary: agents can query and analyze data, but cannot write, modify, or delete anything. Many customers start here, observe how their agents behave within the constraint, and then build a more tailored scope once they understand what their agents actually need.
Block roles agents should never use. In a common configuration, customers block administrative roles (ACCOUNTADMIN, SYSADMIN, SECURITYADMIN) so agents cannot touch elevated privileges regardless of the user's own grants. Others block data-governance roles that unmask PII through masking policies, helping prevent the agent from activating a role that would bypass sensitive-data protections even if the user has access.
Scope agents to specific data. Rather than granting account-wide access, customers restrict agents to named databases or schemas. Several customers built a "read everywhere, write only to sandbox" pattern where agents can read across the account but write operations are limited to a single designated database, letting agents build and iterate under safe boundaries.
RSS and Agent Identity: two halves of the same story
RSS does not operate in isolation. It is the "Authority" pillar of the agentic identity model we outlined earlier this year.
Agent Identity, now also generally available, gives Snowflake the ability to recognize when an agent is active in a session. New audit columns in QUERY_HISTORY and ACCESS_HISTORY show which identified agent ran each query and what it accessed. The IS_AGENT_ACTIVATED() context function lets you use data governance policies to, for example, restrict sensitive data specifically when an agent is active.
Together, these two capabilities answer the two questions every security team asks about agents: What did the agent actually do? (Agent Identity) and What was it allowed to do? (RSS).
Getting started
RSS is generally available today. You can start with a built-in scope in a single session policy, with no changes to your existing role grants. To begin:
- Review the Restricted Session Scopes documentation for the full YAML reference and configuration options.
- Start with the built-in
SNOWFLAKE$DATA_READ_WITH_AIwell-known scope if you want a quick read-only baseline that preserves AI function access. - Running CoCo in bypass mode? Set an RSS first so the agent can only act within the boundaries you define.
If you are working through how to govern agents in your environment, what scenarios you are facing, or what gaps you are hitting, we want to hear from you. Reach out to your account team or contact us directly. The security model for agentic AI is being built with practitioners, not just for them.
