Keep Shipping: How to Say Yes to AI Agents Without Losing Control

Data Movement Policies

#

DMP fills a gap the existing controls leave open:

• Access control answers: who can query this?
• Masking answers: what does this column return?
• Neither answers: how much sensitive data can leave in a single operation?

DMP does. You define row budgets per movement type, group them into a policy, and attach the policy to a tag or to the account. Snowflake then allows, alerts, or blocks.

-- 1. Rules: one per movement type
CREATE OR REPLACE DATA MOVEMENT RULE pii_export_block
  TYPE = 'COPY_INTO_EXTERNAL_STAGE'
  MAX_ROWS AS () RETURNS INTEGER
  -> (CASE
        WHEN SYS_CONTEXT('SNOWFLAKE$SESSION', 'ROLE')
             = 'DATA_EXPORT_ROLE' THEN NULL   -- approved export role: no limit
        ELSE 1000                              -- everyone else: 1,000 rows max
      END);

CREATE OR REPLACE DATA MOVEMENT RULE pii_agent_block
  TYPE = 'AGENT_ACCESS'
  MAX_ROWS AS () RETURNS INTEGER -> (0);      -- agents: no tagged rows at all

CREATE OR REPLACE DATA MOVEMENT RULE pii_fetch_alert
  TYPE = 'PROGRAMMATIC_FETCH'
  MAX_ROWS AS () RETURNS INTEGER -> (10000);  -- drivers/CLI: alert above 10k rows

-- 2. Policy: which rules enforce, which only alert
CREATE OR REPLACE DATA MOVEMENT POLICY pii_guardrails
  ENFORCE_RULES = (pii_export_block, pii_agent_block)
  ALERT_RULES   = (pii_fetch_alert);

-- 3. Attach to the tag (column, table, schema or database tag) ...
ALTER TAG pii_ssn_full SET DATA MOVEMENT POLICY pii_guardrails;

-- ... and optionally set an account-wide baseline for everything untagged
ALTER ACCOUNT SET DATA MOVEMENT POLICY governance.policies.baseline_dmp;

The building blocks:

MAX_ROWS semantics are simple: NULL = no limit · 0 = block · N = at most N rows. The rule body can read context through SYS_CONTEXT: the session role, as above, or statement details in the SNOWFLAKE$DATA_MOVEMENT namespace, such as stage attributes or the name of the agent.

How the attachments resolve:

• The most granular attachment wins. A column tag beats a table tag, which beats a schema tag, and so on. The account policy covers objects that no tag-based policy covers.
• The strictest row budget wins when a statement touches several protected objects.
• Tag propagation matters. By default, a tag carrying a DMP must have its propagation set to ON_DEPENDENCY_AND_DATA_MOVEMENT, so the protection follows the data into derived tables. You can turn that requirement off with the ENFORCE_TAG_PROPAGATION_FOR_DATA_MOVEMENT_POLICIES account parameter.

I like the tag-first design: you classify once, and the guardrail follows the data wherever the tag goes.

Six movement types, one classification

#

DMP covers the paths data actually takes out of the platform:

Details to know before you design rules:

• One primary type per statement. Precedence is COPY_INTO_EXTERNAL_STAGE → COPY_INTO_INTERNAL_STAGE → AGENT_ACCESS → SNOWSIGHT_UI → PROGRAMMATIC_FETCH, and the first match wins. An agent that runs COPY INTO an external stage is handled by your external-stage rule, not your agent rule. Set the budgets with that in mind.
• UI_DOWNLOAD behaves differently. It’s evaluated after the query completes. When enforced, the download button is disabled. It only works as an enforce rule, never an alert rule, and its violations don’t appear in DATA_MOVEMENT_VIOLATIONS.
• Budgets are per statement. DMP caps rows per operation, not cumulative volume across many statements. Catching slow, many-small-queries exfiltration is the job of the detection half.
• Known limits: unloads with PARTITION BY are always blocked on protected tables, and DMP doesn’t protect cross-region shares.

For monitoring, SNOWFLAKE.ACCOUNT_USAGE.DATA_MOVEMENT_VIOLATIONS records violating queries: the enforced or alerted policy, the movement type, the user, and the tables. DATA_MOVEMENT_POLICIES, DATA_MOVEMENT_POLICY_RULES, and DATA_MOVEMENT_RULE_REFERENCES show the configuration. Expect up to two hours of latency on those views. Rules and policies are plain DDL, so they go through the same review and CI process as the rest of your schema.

Anomaly detection in the Trust Center

#

DMP enforces fixed budgets. Detection looks for behaviour that’s unusual for a particular user. The Data Security scanner package has two event-driven scanners, both rated high severity:

• Users with anomalous amount of data unloaded to external stage
• Users with anomalous amount of data unloaded to internal stage. This one also flags GET operations that follow the unload, which is the classic “stage it, then download it” pattern.

Each compares a user’s export volume over the last 24 hours with that user’s own historical baseline. Each also checks query semantics, table access patterns, and stage characteristics to keep false positives down. Findings appear at most once every four hours, under Governance & security » Trust Center » Detections, for roles with TRUST_CENTER_ADMIN or TRUST_CENTER_VIEWER.

If you run agents, two more packages are worth turning on:

• AI Security includes Sensitive Data Accessed by Agent, a detection that fires when an agent reads classified sensitive columns that have no masking or row access policy. It’s a direct check on whether you’ve actually closed the gap that Scenario 2 is about. The same package flags a disabled prompt injection guardrail and CoCo CLI tokens that have no role restriction or network policy.
• Threat Intelligence has anomaly-style detections: authentication failure spikes, dormant-user sign-ins, logins from unusual IPs, unusual client applications, and outlier long-running queries.

Agent Identity

#

What it is: a way for Snowflake to recognise that an AI agent is active in a session, so you can govern agent-driven access separately from a human or a plain service account. There are two modes:

• Delegated agents act on behalf of a user. The session belongs to the user and is marked agent-active.
• Autonomous agents act under their own identity, as a SERVICE_AGENT user.

It isn’t limited to CoCo or Snowflake’s own agents. A session becomes agent-active in any of these ways:

There is one gap to know about. An agent that logs in as a regular user with a key pair or a programmatic access token is not recognised as an agent. To the platform, it looks like the user typing SQL. If you’re building or buying an agent, route it through OAuth with IS_AGENTIC, through the managed MCP server, or through a SERVICE_AGENT user.

How to use it in policies: two context values matter.

• SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') returns whether an agent is active.
• SYS_CONTEXT('SNOWFLAKE$CURRENT', 'AGENT_TYPE') returns which kind: CORTEX_AGENT (a saved, named Cortex Agent), CORTEX_LITE_AGENT (an on-demand agent such as a CoCo client), or EXTERNAL_AGENT (an IS_AGENTIC integration, a token exchange, or a SERVICE_AGENT user). It returns NULL when no agent is active.

-- One masking policy, every agent, no per-agent maintenance
CREATE OR REPLACE MASKING POLICY email_agent_mask AS (val STRING) RETURNS STRING ->
  CASE
    -- no agent: normal RBAC behaviour for the human
    WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN = FALSE
      THEN val
    -- curated, saved Cortex Agents for the support team may see emails
    WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'AGENT_TYPE') = 'CORTEX_AGENT'
         AND IS_ROLE_IN_SESSION('SUPPORT_ROLE')
      THEN val
    -- every other agent, internal or external, gets a masked value
    ELSE '*** MASKED FOR AGENT ***'
  END;

-- Put it on a tag so every classified column is covered
CREATE OR REPLACE TAG sensitive_data_tag;
ALTER TAG sensitive_data_tag SET MASKING POLICY email_agent_mask;

ALTER TABLE customer_data MODIFY COLUMN email
  SET TAG sensitive_data_tag = 'Sensitive';

Humans see the email as usual. A curated Cortex Agent for the support team sees it. Ad-hoc agents, MCP clients, and external agents get the masked string, without you knowing in advance which agents will show up. The same check works in row access, projection, aggregation, and join policies. Note that SYS_CONTEXT returns a string unless the 2026_06 behaviour change bundle is enabled, so keep the ::BOOLEAN cast.

Auditing: ACCOUNT_USAGE.QUERY_HISTORY has an agent_type column for the agent that issued each query. ACCOUNT_USAGE.ACCESS_HISTORY has an agents_info column with the agent type, ID, and name, ordered from the nearest agent to the top-level one, so nested agent calls stay traceable.

SELECT query_start_time, user_name, agents_info, direct_objects_accessed
FROM snowflake.account_usage.access_history
WHERE agents_info IS NOT NULL
ORDER BY query_start_time DESC;

For Snowflake’s own agents and the managed MCP server, there’s nothing to do. For an agent you build yourself, the agent context is decided at authentication time, so it’s the login code that has to get it right. My nanocortex project, a minimal Cortex Agent CLI in a single Python file, implements both supported paths, so I’ll use it as the example.

Path A: IS_AGENTIC OAuth. The human stays the identity, and their queries are marked agentic. Use this when the audit trail should name the person, not a service account.

First, the integration:

CREATE OR REPLACE SECURITY INTEGRATION nanocortex_agent_oauth
    TYPE = OAUTH
    OAUTH_CLIENT = CUSTOM
    OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
    OAUTH_REDIRECT_URI = 'http://localhost:9000/callback'
    OAUTH_ISSUE_REFRESH_TOKENS = TRUE
    OAUTH_REFRESH_TOKEN_VALIDITY = 86400
    IS_AGENTIC = TRUE          -- every session from this integration is agent-active
    ENABLED = TRUE;

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('NANOCORTEX_AGENT_OAUTH');

Then the agent runs a normal authorization code flow with PKCE and logs in with the resulting token. Condensed from nanocortex.py:

# 1. Send the user to Snowflake's authorize endpoint. Bind the role into the
#    scope NOW: switching roles after login doesn't downscope the token.
verifier  = secrets.token_urlsafe(64)
challenge = base64.urlsafe_b64encode(
    hashlib.sha256(verifier.encode()).digest()).rstrip(b"=").decode()
state = secrets.token_urlsafe(16)

params = {
    "client_id": client_id,
    "response_type": "code",
    "redirect_uri": "http://localhost:9000/callback",  # must match the integration
    "state": state,
    "code_challenge": challenge,
    "code_challenge_method": "S256",
    "scope": "session:role:ANALYST",
}
webbrowser.open(f"{account_url}/oauth/authorize?{urllib.parse.urlencode(params)}")
# ... a loopback HTTP server captures ?code=...&state=... and checks state ...

# 2. Exchange the code for tokens (HTTP Basic client auth)
token = post_form(f"{account_url}/oauth/token-request",
                  auth=(client_id, client_secret), data={
    "grant_type": "authorization_code",
    "code": code,
    "redirect_uri": "http://localhost:9000/callback",
    "code_verifier": verifier,
})

# 3. Log in with the agentic token. This session is now agent-active.
conn = snowflake.connector.connect(
    account=account, user=user,
    authenticator="oauth", token=token["access_token"],
)

What I learned building it:

• Bind the role in the token scope (session:role:ANALYST). That’s what actually limits the agent. A USE ROLE after login doesn’t shrink what the token can do.
• Every session needs the agentic token. nanocortex has two logins: one for the Cortex Agent REST API and one for the Python connector that runs SQL tools. If only one of them uses the IS_AGENTIC token, masking differs depending on which path a query takes. Make sure every login the agent opens uses it.
• Cache and refresh, don’t re-prompt. Store the access and refresh tokens (mode 0600), use the refresh grant, and have non-interactive runs fail clearly instead of popping up a browser.
• Verify it, don’t assume it. nanocortex runs a probe at startup and on /agent, and shows not activated in red if the session didn’t come back agent-marked. If it isn’t marked, none of the agent-aware masking is in force.

SELECT SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') AS is_agent_activated,
       SYS_CONTEXT('SNOWFLAKE$CURRENT', 'AGENT_TYPE')         AS agent_type,
       CURRENT_USER(), CURRENT_ROLE();
-- expected through the agent: TRUE | EXTERNAL_AGENT | ME@EXAMPLE.COM | ANALYST

Path B: a SERVICE_AGENT user. The agent has its own identity. Every session that user opens is agent-active, with no change on the client side, which makes it the sturdiest option for autonomous or scheduled agents:

CREATE USER IF NOT EXISTS nanocortex_agent
    TYPE = SERVICE_AGENT
    RSA_PUBLIC_KEY = '<public key body>'
    DEFAULT_WAREHOUSE = 'COMPUTE_WH'
    COMMENT = 'nanocortex agent identity';

CREATE ROLE IF NOT EXISTS nanocortex_agent_role;
GRANT ROLE nanocortex_agent_role TO USER nanocortex_agent;

The agent then authenticates with an ordinary key-pair JWT (authenticator = "SNOWFLAKE_JWT"), or with workload identity federation if it runs in a cloud workload. The difference from the gap above is the user type: a key pair on a regular user isn’t agentic, while a key pair on a SERVICE_AGENT user is.

nanocortex’s demo/agentic_masking.sql has the full setup for both paths, a masking policy to test against, and a QUERY_HISTORY check to run afterwards.

What it is: a privilege ceiling on what an agent can do on behalf of a user. Effective access is the intersection of the user’s RBAC and the RSS. It never grants anything the user’s roles don’t already allow, and once it’s active in a session it can’t be loosened there.

It applies to any agent, not just CoCo. An admin-managed RSS kicks in whenever IS_AGENT_ACTIVATED is true, whatever the client: CoCo, CoWork, Cortex Agents, an MCP client on the managed MCP server, a partner tool on an IS_AGENTIC OAuth integration, or a SERVICE_AGENT user. When no agent is active, the same user works with their normal privileges.

There are three ways to set the ceiling.

1. Admin-managed, through a session policy. This is the main control. Set AGENT_RESTRICTED_SESSION_SCOPE on a session policy and attach it to the account or to specific users. The simplest version uses a predefined scope:

-- Account-wide: every agent session is read-only
CREATE SESSION POLICY governance.policies.agent_readonly_policy
  AGENT_RESTRICTED_SESSION_SCOPE = 'SNOWFLAKE$DATA_READ_WITH_AI';

ALTER ACCOUNT SET SESSION POLICY governance.policies.agent_readonly_policy;

For anything more specific, define your own scope object in YAML. This one gives the finance team’s agents read access to finance reporting and write access only to a sandbox and the user’s personal database, and it keeps agents off the admin roles completely:

CREATE RESTRICTED SESSION SCOPE governance.policies.finance_agent_scope AS $$
privilege_scopes:
  allowed_privileges:
    - privileges: [data read]
      databases: [FINANCE_PROD]
    - privileges: [data write]
      databases: [FINANCE_SANDBOX, USER$]
role_scopes:
  blocked_roles: [ACCOUNTADMIN, SYSADMIN, SECURITYADMIN]
  allow_role_switching: true
$$;

CREATE SESSION POLICY governance.policies.finance_agent_policy
  AGENT_RESTRICTED_SESSION_SCOPE = 'GOVERNANCE.POLICIES.FINANCE_AGENT_SCOPE';

ALTER USER finance_lead SET SESSION POLICY governance.policies.finance_agent_policy;

A user-level session policy replaces the account-level one for that user. The two aren’t merged. So the user-level scope has to be a complete ceiling on its own.

2. User-managed, per chat. Users can tighten their own session further: /guardrails (or cortex --with-restricted-session-scope=…) in the CoCo CLI, and + → Restrict this session/chat in CoCo Desktop and in Snowsight. This only narrows what the admin ceiling already allows, and it can’t be relaxed in the middle of a chat.

3. Token-bound, for your own apps and third-party agents. When an app uses OAuth token exchange to hand a user’s identity to an agent, it can attach a ceiling directly to the token with a Rich Authorization Request:

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=<user token>
subject_token_type=urn:ietf:params:oauth:token-type:access_token
act={"sub":"invoice-bot","type":"agent"}
authorization_details=[{"type":"snowflake-rss.v1","rss":"SNOWFLAKE$DATA_READ"}]

The resulting token is short-lived (one hour by default), labelled with the acting agent for audit, and capped by the RSS. If an admin-managed RSS also applies, Snowflake enforces the intersection of the two. Every layer can make the scope smaller, and none can make it bigger.

Things to keep in mind:

• No RSS means no ceiling. If the session policy doesn’t set AGENT_RESTRICTED_SESSION_SCOPE, the agent has the user’s full access.
• blocked_roles matches exact role names. It doesn’t walk the role hierarchy, so privileges inherited through another role can still come through. Block the roles that actually carry the risky grants.
• Warehouses are always usable. RSS limits data and object privileges, not compute. Pair it with a dedicated agent warehouse and a resource monitor.
• Owner’s-rights procedures can still write under SNOWFLAKE$DATA_READ_PROGRAM_USAGE, because they run with the owner’s privileges.
• ALTER RESTRICTED SESSION SCOPE takes effect immediately on every session and token issued from it, including changes that loosen it.
• You can check what’s active in a session with SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'ACTIVE_RESTRICTED_SESSION_SCOPES');

1. Make every agent identifiable. Set IS_AGENTIC = TRUE on the OAuth integrations that agents use, prefer the managed MCP server for MCP clients, and use SERVICE_AGENT users for autonomous agents. For agents you build, get the agent context right in the login code (see the nanocortex example above), and avoid agents that log in as a regular user with a PAT or key pair.
2. Classify. Get sensitive data tagged. Every control below is easier when it can hang off a tag.
3. Set an account-wide agent ceiling. A session policy with SNOWFLAKE$DATA_READ_WITH_AI is a sensible default. Add user-level policies with custom scopes where a team needs more.
4. Add IS_AGENT_ACTIVATED / AGENT_TYPE to your tag-based masking and row access policies.
5. Attach Data Movement Policies to your most sensitive tags. Start with AGENT_ACCESS and COPY_INTO_EXTERNAL_STAGE as alert rules, watch DATA_MOVEMENT_VIOLATIONS, then move them to enforce.
6. Enable the Trust Center Data Security and AI Security scanner packages, and route the findings to wherever your SOC already looks.