Snowflake Cortex Agent Security: Guardrails, Monitoring and Access Control for CoWork and CoCo

If you are researching this now, there is a decent chance you did not choose the current product so much as get renamed into it. Snowflake changed two product names at Summit 2026, and while neither change was a shutdown, both widened what the named thing actually does.

The administrative risk here is the same one we documented when Agentspace became Gemini Enterprise and when Azure AI Foundry became Microsoft Foundry. Nothing operational breaks. The control document simply stops describing the deployment, and nobody notices until an auditor reads both.

Cortex AI Guardrails became generally available on 20 April 2026 and were extended to Snowflake CoWork and Cortex Agents on 14 May 2026. Account administrators enable them for all supported surfaces with a single account-level setting using the AI_SETTINGS parameter. That single setting is both the best and the most limiting thing about them.

The second row is the one worth stopping on, because it inverts the usual assumption. Teams generally expect that the more regulated their deployment, the more security controls they get. Here the opposite is true: a federal or Virtual Private Snowflake customer, which is precisely the customer with the strictest injection threat model, is the customer Snowflake's documentation excludes from the native guardrail. If that is your account type, the prompt injection control has to come from somewhere else, and it is worth confirming your eligibility before the control appears in a compliance narrative.

None of this makes guardrails a bad feature. A single account-level switch that covers three surfaces is a genuinely good design decision for the majority of customers, and Snowflake shipping it at no additional charge inside Horizon is more than several competitors do. It is a coverage control. It is not a policy engine.

This is the part that decides your blast radius, and it comes down to one sentence in Snowflake's documentation: Cortex Agents determine session permissions from the querying user's default role. For CoCo Desktop the equivalent statement is that it runs SQL with whatever role the active connection specifies.

Read that operationally. An agent invoked by a senior analyst can query everything that senior analyst can query. Snowflake is not doing anything wrong here, it is applying the permission model consistently, and that consistency is why the platform is trusted. But an agent is not a person. A person who reads a suspicious message in a support ticket does not then run a query because the message told them to. An agent might, because the instruction and the data arrive through the same channel.

Snowflake's own recommended practice is to scope roles specifically for agent use and create purpose-built roles limited to the exact tables, schemas and operations the agent requires. That advice is correct and most teams have not done it. If you do one thing after reading this page, do that one, because it costs nothing and it shrinks the radius of every other problem on this list.

What the CoCo sandbox does and does not cover

The agent terminal sandbox wraps every terminal command inside an isolated sandbox process, which is a real control. Snowflake documents its edges clearly: the sandbox applies only to terminal commands the agent runs via the Bash tool and does not restrict file edits or SQL execution, sandbox behavior depends on OS-level sandboxing capabilities and may vary between macOS, Windows and Linux, and web fetch content enters the main context window rather than an isolated one, with coverage of novel injection patterns that "isn't complete". Snowflake also states directly that defending against prompt injection in the inputs you supply is your responsibility, and advises vetting untrusted sources before letting the agent read them.

The vulnerability that showed why the gate matters

CVE-2026-6442 is worth knowing about, and worth describing accurately rather than dramatically. Improper validation of bash commands in Snowflake Cortex Code CLI versions before 1.0.25 allowed commands to execute outside the sandbox. The reported path was indirect prompt injection through untrusted repository content such as a poisoned README, abusing process substitution syntax that the agent's command allowlist failed to validate, which bypassed the human-in-the-loop command approval and escaped the sandbox. Snowflake fixed it in Cortex Code CLI 1.0.25, released on 28 February 2026, and the fix applies automatically when the CLI relaunches. Exploitation was non-deterministic and model dependent, and there were no confirmed reports of real-world exploitation.

Snowflake handled this well and patched it. The durable lesson is not that Snowflake was careless, it is structural: the approval gate and the allowlist lived inside the same agent process that was reading the attacker's text. Any control that an injected instruction can reach is a control an injected instruction can eventually argue with. That is the same reason we recommend an out-of-process policy check for agents on AWS Bedrock AgentCore and every other platform, and it has nothing to do with which vendor built the agent.

Any page comparing Snowflake to a third-party control layer that ignores this section is out of date. On 28 July 2026 at Black Hat, Snowflake announced Cortex AI Gateway, a centralized control layer for connecting, governing and monitoring AI agents as they reach into models, tools, MCP servers and internal systems. It is the most direct native answer to the gap the rest of this page describes, and it is more ambitious than most people realize.

Read that list honestly and it covers a lot of ground, including the cross-cloud problem, since governing Bedrock and Azure AI Foundry agents from one place is exactly the thing most warehouse-native tools cannot do. Short-lived task-scoped credentials are the right primitive. Shadow MCP discovery is a real problem few vendors address at all.

The caveat is maturity, and it is a factual one rather than a competitive jab. As announced, most Cortex AI Gateway features were in private or public preview with no general availability date given for the full platform, and third-party agent access was in private preview specifically. That matters for procurement in the ordinary way any preview feature does: preview terms usually carry different support commitments, feature behavior can change, and a control in preview is difficult to put in front of an auditor as your primary compliance answer. Google's Semantic Governance sits in the same position for the same reason, which we cover on the Gemini Enterprise security page.

Our straight recommendation: if your agent estate is centered on Snowflake and your timeline allows waiting for general availability, evaluate Cortex AI Gateway first. It is native, it is included in the platform relationship you already have, and buying a third-party layer to replicate something your data platform is shipping is a bad use of budget. Evaluate an independent layer when you need enforcement now rather than at GA, when you need a deterministic approval gate on irreversible actions rather than policy and monitoring, or when your account type is excluded from the native guardrails.

Here is the honest split. We are not the answer to most rows in this table, and pretending otherwise would waste your evaluation time.

Five of eight rows say buy nothing and configure Snowflake properly. That is the accurate answer for a team whose agents read data and answer questions. The three rows where an independent layer earns its place all involve an agent taking an action that changes something outside the warehouse, on an account type Snowflake excludes, or across more than one cloud. If none of those describe you, close this page and go write your agent roles.

If they do describe you, the shape of the fix is the same one we describe for every platform: a deterministic gate that evaluates the proposed tool call against rules you wrote, a human approval step on actions that cannot be undone, and one monitored record of every agent action that spans clouds. Agentshield sits in front of the tool call rather than inside the agent, which is the property that makes it hard for injected text to negotiate with.