Contents
Snowflake's new always-on agents act with the exact access rights of the person who sets them up. That is the headline from Snowflake's press release of 3 November 2026, issued at its Expedition 2026 event. For anyone running go-to-market data in Snowflake, the practical meaning is simple. Whatever your revenue operations roles can see today, an agent will be able to see, read and act on tomorrow, in the background, without a person in the loop until it asks for sign-off.
What did Snowflake announce?
Snowflake announced CoCo and CoWork Bots on 3 November 2026. CoCo is its coding agent for data teams and CoWork is its work agent for knowledge workers. The Bots run continuously rather than waiting for a prompt. In Snowflake's words, Bots "act on behalf of the user, inheriting their exact access rights, role context, and permissions." The release says Bots plan and complete work in the background, "operating strictly within the user's governed boundaries in Snowflake and surfacing only when a critical decision or final approval is needed."
One example Snowflake gives is directly relevant to sales teams: a Bot set the goal of "preparing briefings for every customer meeting." Another is a sales leader asking CoWork to analyse sales performance and schedule that analysis to run every week, with a fresh report delivered to their inbox.
The release footnotes matter here. Snowflake says Bots are "in private preview soon." CoCo Automations, the scheduled workflows with an audit trail, are generally available. CoWork Profiles, Snowflake for Slack and Snowflake Mobile are in public preview. The always-on part is not here yet. The scheduled part is.
Snowflake also published usage figures. It says CoWork is used by more than 5,800 accounts and CoCo by more than 9,100, measured as the average of the last four weeks of the quarter ended 31 July 2026. Those are Snowflake's own numbers, counted by its own internal method.
Why does permission inheritance matter for GTM data?
Permission inheritance is a sensible default. An agent that could see more than its owner would be a security hole.
The catch is that it takes your existing role model as correct. In most GTM stacks it is not. Revenue operations people tend to collect broad access because they fix things across every territory. Sales managers get read access to deal tables "temporarily" and keep it. A marketing ops analyst gets a role built for a one-off attribution project. None of this caused much harm while a human had to sit down and write a query. A Bot that runs every morning with that same role changes the exposure. Over-broad access stops being dormant and starts being exercised on a schedule.
There is a second gap specific to CRM data. Salesforce and HubSpot have their own sharing rules, territory hierarchies and field-level security. When CRM objects are synced into Snowflake, those rules do not travel with the rows unless someone rebuilds them as warehouse policies. If that has not happened, the Bot's view of the CRM is the warehouse role's view, not the CRM's view. A rep who cannot see another region's opportunities in Salesforce may well be able to see them in the synced table, and so could their Bot.
What controls does Snowflake give admins?
The release names a few. CoWork Profiles, in public preview, "let admins set agent access and routing instructions that end users cannot remove." CoCo Automations keep "an audit trail and task history, so teams can see exactly what CoCo did and suspend or rerun a job whenever they need to." Memory in both agents can be viewed, updated or deleted by users.
A separate Snowflake release on the same day, 3 November 2026, describes Cortex AI Gateway as governing "how the agents access models, invoke tools, and take action across enterprise systems." It also describes Business Ontology, in public preview, which lets teams approve official definitions for business terms and link them to the underlying tables.
That second piece is quietly important for GTM. Joe Tobey, Head of Data Product Engineering at dentsu, is quoted in that release: "The value of a data product depends on everyone agreeing what each attribute means, whether it's a household income band or a B2B firmographic segment." If your ICP tiers, lifecycle stages and pipeline definitions live in three different dashboards, an agent will pick one. Snowflake cites a report from MIT Technology Review, sponsored by Snowflake, in which 55% of executives named a lack of business context as the main cause of low-quality AI agent insights. Treat it as vendor-sponsored, but the direction holds.
What should a GTM team do before Bots arrive?
**Audit roles by person, not by table.** List every human role that can query GTM data and ask what a Bot running as that person every day would reach. Start with RevOps and sales leadership, because they tend to hold the widest grants.
**Rebuild CRM visibility in the warehouse.** If reps should only see their own territory in the CRM, express that as row access policies on the synced tables. Otherwise the sync has quietly flattened your sharing model.
**Mask the fields agents should never summarise.** Contract values, personal contact details and anything covered by a data processing agreement are candidates for masking policies, so a briefing Bot gets the account context without the sensitive columns.
**Write down your definitions.** Agree what counts as an MQL, an active opportunity and a target account before an agent agrees for you.
**Read the audit trail.** Snowflake says every automation run is logged. Someone should own reviewing it.
A worked example (hypothetical)
The numbers below are invented for illustration only.
Take a 40-person GTM organisation with three warehouse roles. Thirty reps hold a role scoped to their own territory. Six managers hold a regional role. Four RevOps people hold a role that sees every territory, every contract value and every contact record.
If every person sets up one meeting-briefing Bot, there are 40 always-on agents. Thirty of them are scoped tightly. But four of them can read the entire customer base, and those four belong to the people most likely to automate aggressively. If each RevOps Bot touches, say, 25 accounts a day across 20 working days, that is 4 × 25 × 20 = 2,000 account reads a month from roles with full access. None of it is a breach. All of it is reach that nobody consciously granted to an agent.
The fix is not to stop RevOps using agents. It is to give their Bots a narrower role than their own, which is exactly what admin-controlled Profiles appear designed to support.
The real shift
Docusign's Chief Data Officer, Bala Sahejpal, is quoted in Snowflake's 3 November release saying "Our GTM teams can now execute deep account research and get insights into an account without needing SQL expertise." That is the upside, and it is real. The same change removes the friction that used to keep loose permissions from mattering. When agents inherit access, your role model is your agent policy. Fix it first.
