Snowflake agents now fail open on missing tools—so clients must surface the warning

Snowflake’s new inaccessible-tool handling makes one Cortex Agent usable across callers with different grants—but it also creates a new class of successful, incomplete answer.

By default, orchestration.tool_not_accessible is now accept. If a caller cannot access a named Cortex Search, Cortex Analyst, MCP or skill tool, the run continues with the tools that remain available. Snowflake emits a warning rather than rejecting the request. Operators can instead select reject, which returns one HTTP 4XX listing every inaccessible tool in the checked set, or legacy, which stops at the first inaccessible supported tool. (Snowflake documentation)

A completed run is not a complete answer

The practical risk is not privilege bypass: Snowflake says this feature does not grant access the caller lacks. The risk is interpretation. A client that treats HTTP success as evidence that the agent had its full configured capability set can present a partial answer as complete.

The warning surface depends on the invocation path. Streaming REST clients receive a response.warning event before the first model call; non-streaming REST and SNOWFLAKE.CORTEX.DATA_AGENT_RUN place warnings in the final JSON; Snowflake Intelligence displays the warning in the conversation. Snowflake also records it in SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS. Any custom client that ignores those fields discards the only structured signal that a named capability was unavailable. (Snowflake documentation)

The pre-check has a boundary

Snowflake checks Cortex Search, Cortex Analyst, MCP and skill access at the start of every run. It does not pre-check custom functions and stored procedures, SQL execution, code execution or other tool types. Those failures arrive later as tool results, after which the agent can continue reasoning with whatever it has.

There is another visibility distinction. If the specification names an inaccessible resource, accept mode emits a warning. If Snowflake discovers resources—for example, an MCP configuration using selection: all—unauthorized items are omitted without a warning because the caller did not name them. For Cortex Analyst, the initial check covers access to the semantic model or view, not every referenced table or embedded search service; those failures can surface only when the tool runs. (Snowflake documentation)

Choose a completeness contract

Use reject for workflows where every configured source is required—for example, a financial answer that must reconcile a semantic model with a policy document. Use accept when degraded service is legitimate, but make warnings visible beside the answer and include them in evaluation records.

Then test two failure paths separately: privileges missing at run start, and privileges failing inside SQL, code or custom-tool execution. The former is a configuration gate; the latter is an execution-path test. Without both, a green response code proves only that the agent produced an answer—not that it had the evidence the application promised.