Snowflake CoCo Automations Run on Schedules Without Tool Prompts

If your engineers use Snowflake's CoCo, its agent can now keep working after they log off, and its scheduled form runs with no tool prompts under each engineer's default roles. Snowflake announced on November 3 that CoCo Cloud Agents and CoCo Automations are generally available. It also named Restricted Session Scope as a way for an engineer to limit a Cloud Agent session. Set that ceiling first, then prove it applies to scheduled runs, because the documentation we read on November 4 does not say that it does.

Snowflake published no price for any of this in the release. The Cloud Agents docs say the feature is available "at no additional cost," without saying whether that covers CoCo token consumption, and add: "Pricing may be introduced in a future release."

What Snowflake Actually Shipped on November 3

Snowflake moved its coding agent off the laptop and gave it a schedule. A Cloud Agent session gets its own container in an environment Snowflake manages, works on files in a shared Snowflake Workspace, and, per the release, can keep going after the engineer logs off. Automations run CoCo on a schedule from a task written in plain language, such as checking pipeline health or investigating failed jobs.

The installed base is large. Snowflake says CoCo was used by more than 9,100 accounts, averaged over the last four weeks of the quarter ended July 31, 2026. That figure covers CoCo overall, not Cloud Agents or Automations.

The status labels need a second look:

Capability	Status Snowflake gives	Where to check
CoCo Cloud Agents	GA in commercial regions on AWS, Azure and Google Cloud	Cloud Agents docs
CoCo Automations	GA in Snowsight and CLI, public preview in CoCo Desktop	Snowflake blog
Restricted Session Scope	GA	Snowflake engineering blog
Spark migration skill in CoCo	GA	Snowflake blog
DataFrameWriterV2 for Iceberg	Preview, available to all accounts	Iceberg docs

The Automations docs page still carried a public preview label when we read it on November 4, a day after the GA announcement. Expect the page to change, and recheck the limits quoted below before you build on them. Neither Cloud Agents nor Automations is available in government, FedRAMP, DoD, VPS or China deployments.

---

Why Automations Are the Part to Worry About

Automations carry the larger risk because a run has no approval prompt and no separate identity. We flagged the identity design during the August preview, and the current docs describe the same behavior:

• A run uses the creating user's default role and default secondary roles. If those cover every granted role, "a run can reach any object that the user can reach through any of their roles."
• "There is no option to configure a different executing user or role."
• EXECUTE AGENT TASK "is granted to the PUBLIC role by default."
• "Automation runs are unattended, so interactive tool permission prompts are disabled."

All four come from the Automations docs, which also say "Do not schedule destructive or irreversible actions" without deliberately configuring how they behave.

The release describes a gentler workflow, where CoCo traces a likely cause and proposes a fix for engineers to review. That review holds only if the run lacks the privilege to apply the fix itself. With prompts off, your role grants and your scope are what stop a write.

The strongest case for Snowflake is that a managed container is safer than a laptop, and on egress the case holds. Snowsight Cloud Agents can reach only a fixed allowlist of package and build hosts, read-only, and an ACCOUNTADMIN can block all non-Snowflake egress with COCO_CLOUD_AGENTS_NON_SNOWFLAKE_EGRESS_DISABLED, which defaults to FALSE. The CLI sandbox doesn't upload local files and starts with no GitHub credentials. Snowflake also says Cloud Agents do "not modify any of your Snowflake RBAC settings or open up additional SQL access."

The container doesn't shrink what the session can do inside Snowflake, and CoCo has a history there. In February, PromptArmor reported that a prompt injection hidden in a repository README could lead the CLI, then called Cortex Code, to run a downloaded script outside its sandbox without approval, at about 50% efficacy. The demonstrated script stole database contents and dropped tables using the agent's cached tokens. Snowflake fixed it in version 1.0.25 on February 28, and that specific chain is closed. An unattended agent that reads repositories and job logs still takes in text it did not write, and no person is watching the run.

---

Restricted Session Scope Has a Gap You Should Test

Restricted Session Scope is a privilege ceiling. Snowflake's docs define it as something that "limits what an agent can do on behalf of a user," and it can narrow access without ever granting more. An admin sets AGENT_RESTRICTED_SESSION_SCOPE on a session policy and attaches it to the account or to specific users. A user can also narrow an individual chat, a capability Snowflake marked GA on September 14.

The admin-managed version applies only to agent-active sessions. The agent identity docs count CoCo clients as agent-active, and the release says a data engineer can use the scope to limit a Cloud Agent session, though it says nothing about an admin-set ceiling there. The CLI cloud sandbox page cuts against that: it says restricted session scope is "not supported" in cloud mode, because it applies "to a local SQL connection" and has "no effect server-side." That page does not separate user-managed from admin-managed scope, and the Cloud Agents page never mentions the scope, so test cloud sessions as well. For scheduled runs we found no confirmation: the Automations page does not mention Restricted Session Scope, and neither the scope page nor the agent identity page mentions automations or tasks. Automations run in what the docs call a task session. Maybe those sessions activate the scope and the docs simply have not caught up. You can settle that in an afternoon, and you should not assume the answer.

Three more limits change how you configure it:

A user-level policy can erase your account ceiling. The docs say a user-level policy's scope "is used exclusively" and the account policy "isn't consulted or merged," and that if a policy doesn't set the property, "no agent scope is applied." Read together, those sentences suggest an engineer with a user-level session policy that omits the property gets no ceiling, even with an account-level scope in place. Check this before you trust an account-wide rollout.

Read-only scopes also have edges. Owner's-rights stored procedures can still modify objects under SNOWFLAKE$DATA_READ_PROGRAM_USAGE, so prefer SNOWFLAKE$DATA_READ_WITH_AI, which excludes stored procedures, unless a job needs them. Role blocklists match exact names and don't strip privileges a permitted role inherits.

And a read-only agent can still spend money: Classmethod's hands-on test reports that warehouse usage is implicitly permitted regardless of privilege scope. It tested CoCo in Snowsight and did not cover scheduled runs.

What Unattended Agents Will Cost You

The release gives no rates and the components are metered separately, so a full number has to come from your own test runs. Automations incur "standard Snowflake task billing in addition to CoCo token consumption for each run," and they don't need a warehouse. CoCo bills in AI Credits, which Snowflake prices at $2.00 under global routing and $2.20 under regional routing. That page points to Table 6 of the Service Consumption Table for AI Credit rates.

The preview docs set a minimum interval of one hour, so one hourly automation is 720 runs in a 30-day month. Multiply that by whatever a run costs you in a test, then multiply again by the number of engineers allowed to create one. If you plan to rely on quotas, read how Cortex AI Gateway spend caps can overshoot first.

Keep two more limits in mind. Run history and threads are retained for two months, so export them if your audit window is longer. The docs also warn that task success doesn't guarantee the business outcome, so someone has to read transcripts.

---

The Spark Path Is Real, With Sharp Edges in the Writer

Snowflake now offers a shorter route off Spark clusters, though the Iceberg writer that makes it easy is still in preview. Snowpark Connect runs existing PySpark, Java and Scala code on Snowflake with no external clusters to manage, and the CoCo migration skill converts notebooks and jobs that need rewriting.

The evidence on the payoff is thin. Klarent's Kumar Maddali says in the release that moving heavy Spark workloads "cut our total cost of ownership by 60%," adding: "Our longest pipeline went from more than 10 hours to under three." That is one customer quoted by the vendor, with no baseline, workload size or measurement period given. Use it as a reason to run your own test, and leave it out of the business case.

The Iceberg documentation lists what a pilot has to check:

• On catalog-linked databases, createOrReplace and replace drop the existing table first, because those databases reject CREATE OR REPLACE for externally managed Iceberg tables. If a downstream reader hits that table during a write, test what it sees.
• Bucket transforms are not supported, so any table partitioned that way needs a new design. Supported transforms are years, months, days and hours, plus identity columns.
• Adding nested fields to struct columns on catalog-linked Iceberg tables is not supported.
• The full feature set needs snowpark-connect 1.44.0 and snowflake-snowpark-python 1.53.1 or later, and the docs say to stay on format version 2 unless your account team confirms V3 for your catalog type.

If you are also weighing leaving a platform, our Snowflake alternatives and Databricks alternatives pieces cover the exit math, and Apple's Ascend.io deal shows what a forced pipeline migration looks like.

---

What to Do Before Agents Run Unattended

This Week:

1. Run SHOW GRANTS TO ROLE PUBLIC; and look for EXECUTE AGENT TASK. If nobody has decided who should schedule agents, revoke it from PUBLIC and grant it to a named role. The docs warn that this stops affected users from creating or running automations, so tell those teams first.
2. List your largest agent identities from SNOWFLAKE.ACCOUNT_USAGE.USERS, where DEFAULT_SECONDARY_ROLE shows ALL or NULL. The view can lag by up to two hours.
3. Inventory existing automations and their owners. Each one runs as a person, so add automation ownership to your offboarding checklist.

This Month:

1. Create a scratch automation under a test user with a policy attached, and have it run SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'ACTIVE_RESTRICTED_SESSION_SCOPES'); plus an INSERT into a table the scope should deny. Read the transcript. Your data platform lead should have that result on paper before anyone schedules a production run.
2. Check every user-level session policy for the AGENT_RESTRICTED_SESSION_SCOPE property, since a policy without it may leave that user with no agent ceiling.
3. Decide whether the egress default suits you, and have an ACCOUNTADMIN set the egress parameter if it does not.
4. Query agent_type in QUERY_HISTORY and agents_info in ACCESS_HISTORY, the audit columns Snowflake documents, and confirm that your scratch run's queries appear the way your monitoring expects. Snowflake's docs do not say how scheduled runs are labeled.

Before You Move a Spark Job:

1. Pick the job with the worst cluster cost and measure its current runtime and total cost for a full month, so you have the baseline Klarent's quote lacks.
2. Scan that job for bucket partitioning, nested schema changes and createOrReplace calls before you let the migration skill touch it.

The Bottom Line

Data teams have seen this before with cron jobs and service accounts: a script set up under one employee's login works for years, gathers privileges as that person is promoted, and surprises everyone when they leave. Automations follow the same shape, with a model deciding what to run next. Cloud Agents are worth using, and moving this work off laptops is an improvement. The identity model has not caught up, since Snowflake still offers no way to give an automation its own role.

If you standardize on Snowflake Cortex AI, ask your account team two things in writing: whether admin-managed Restricted Session Scope applies to automation runs, and when a run-as option will ship. Until you have that answer, schedule automations only under users whose default roles you would be comfortable giving to an unattended script.

Continue Reading

• Snowflake Agents Run as All Your Roles. Revoke From PUBLIC.
• Your Snowflake Cortex AI Gateway Spend Caps Can Overshoot
• Snowflake Alternatives: Fix the AI Bill Before You Move a Table
• Snowflake Cortex vs Databricks Mosaic AI: Pick on Exit Cost
• Databricks Alternatives: How to Cut Costs Without Migrating