Snowflake made CoCo automations available in public preview on 21 August 2026. The feature lets users schedule recurring, unattended CoCo runs in the command line and Snowsight. Each run executes in a Snowflake-managed sandbox and creates a Cortex thread that a user can inspect and continue.
The governance consequence is immediate. Snowflake says the account-level EXECUTE AGENT TASK privilege that controls access is granted to the PUBLIC role by default. Administrators can revoke it and grant it to selected roles. Teams adopting the preview should therefore review access, task ownership, data reach, cost limits, and evidence before unattended runs become normal operational infrastructure.
What changed in the Snowflake CoCo preview
Snowflake's release note says automations are available in all commercial regions on AWS, Azure, and Google Cloud. The preview is not available in government, FedRAMP, DoD, VPS, or China deployments.
Users can create an automation in the CoCo CLI or Snowsight, then monitor and manage it from either surface. User-created runs incur standard Snowflake task billing plus CoCo token consumption. System-initiated analysis is not charged, according to Snowflake.
The source documentation establishes four operational facts:
| Area | Snowflake's current preview behavior | Governance question |
|---|---|---|
| Execution | Recurring unattended CoCo run in a managed sandbox | Which tasks may run without a person present? |
| Identity | Run uses the permissions available through the configured Snowflake role and tools | Is the role limited to the task's real need? |
| Access | EXECUTE AGENT TASK is granted to PUBLIC by default | Should the privilege be revoked and reassigned before enablement? |
| Cost | Task billing and token consumption apply to user-created runs | Who owns limits, monitoring, and unexpected spend? |
These are Snowflake product statements. A bounded search found no independent reporting that verified the exact 21 August availability change. The article therefore does not treat vendor claims about security, governance, or performance as independently proven.
Why unattended agents change the control problem
A person using an interactive coding agent can see a prompt, observe a proposed change, and stop when the context looks wrong. A scheduled run removes that continuous presence. The automation may operate after data, code, permissions, dependencies, or business assumptions have changed.
The Snowflake-managed sandbox is one useful boundary, but a sandbox does not define which tables, tools, APIs, files, or external systems the run should reach. Nor does it prove that an output is correct, a data update matches the intended effect, or a recurring task remains necessary.
Before deployment, teams need a task contract that states the permitted objective, inputs, tools, data classes, outputs, external effects, and stop conditions. Maetra's Task Guard guide explains how task alignment and effect verification differ from approval routing.
Seven controls to review before enabling CoCo automations
- Revoke broad access if it is not intended. Review the
PUBLICgrant and assignEXECUTE AGENT TASKonly to approved roles when least privilege requires it. - Name an owner for every automation. Record who created it, who reviews it, which business process it supports, and when it expires or must be renewed.
- Limit the execution identity. Use the narrowest role, warehouse, data access, tool set, and external connection needed for the task.
- Define change triggers. Re-review the automation when schemas, models, skills, MCP servers, permissions, schedules, prompts, or dependent systems change.
- Set cost and frequency boundaries. Record the maximum cadence, run duration, token use, task spend, and response to repeated failures.
- Verify the intended effect. Distinguish a successful agent response from a verified data or system outcome. Reconcile ambiguous outcomes before any retry.
- Retain evidence. Keep the task definition, identity, input class, tool calls, policy decisions, outputs, exceptions, costs, and final effect in a useful audit record. Maetra's AI audit evidence guide provides a starting structure.
An approval step is not mandatory for every run. It becomes relevant when the action can change production data, send communications, alter access, create material spend, or trigger another consequential system. The threshold should come from an explicit policy.
Important limits in the announcement
Public preview does not mean general availability or a compliance certification. Snowflake excludes several regulated and government deployment types from this preview. Product behavior, billing, and regional availability can change before general availability.
The default privilege also does not mean every user can access every object. Snowflake role and object permissions still matter. The concern is that a global capability to create or run unattended agent tasks starts broadly available unless an administrator narrows it.
Teams should test the exact account configuration rather than infer permissions from the release note alone. They should also review Snowflake's current security guidance for CoCo, connected MCP servers, conversation history, and production workflows.
Maetra analysis: treat the schedule as a production capability
The key shift is not scheduling by itself. It is the combination of a recurring trigger, agent reasoning, tool use, data permissions, and operation without a person continuously present.
Add each automation to the organization's AI agent inventory, including owner, role, tools, data, schedule, cost limit, effect, and latest review. Then apply policy to consequential actions and verify that the completed run produced the intended state. This turns a convenient personal automation into an inspectable production capability.
Sources
- Snowflake: CoCo automations in CLI and Snowsight, public preview, dated 21 August 2026.
- Snowflake: EXECUTE AGENT TASK privilege granted to PUBLIC by default, accessed 24 August 2026.
- Snowflake: Governed AI for Every Builder, published 18 August 2026.