Snowflake agent toolsets fail open on capability—but not on data access
Inherited tools can disappear without an error when a caller lacks USAGE, so a successful run is not proof that the intended capability set was present.
Snowflake’s new agent-toolset mechanism makes Cortex Agents easier to compose, but it also creates a failure mode operators need to test explicitly: an agent run can succeed after an inherited toolset has been silently removed.
What Snowflake now documents
An agent_toolset lets one Cortex Agent reference another agent and inherit its tools at runtime. Snowflake resolves the referenced agent under the caller’s identity, reads its stored tool configuration, recursively expands any nested toolsets, and passes a flat tool list to the orchestrator. The calling agent’s local definition wins when tool names conflict. Snowflake limits expansion to five nested levels and 25 referenced agents by default, and cycles fail with an error. Snowflake’s toolset documentation describes the full resolution path and limits.
The important exception is access failure. If the caller lacks USAGE on a referenced agent—or if that agent does not exist—Snowflake says the reference is silently skipped. The run continues with the calling agent’s own tools, with no error or annotation for the dropped reference. Creation-time validation checks only that the reference has the required structural fields; it does not resolve the target or verify authorization. Revoking a privilege or dropping the referenced agent later can therefore change the effective tool set without invalidating the parent agent’s specification. The same documentation makes that behavior explicit.
Why “successful” is not the same as complete
This design protects data access: the caller does not gain tools it is not authorized to inherit. But it does not protect the application from degraded capability. A finance agent that normally inherits a forecasting toolkit could still return an answer after that toolkit disappears, using only its local tools. Unless the application separately verifies the effective capability set, it may treat a narrower answer as a complete one.
That distinction matters because Cortex Agents are designed to combine structured and unstructured data, execute code, and call custom or remote tools inside a managed reasoning loop. Snowflake also cautions that agent answers and citations are not guaranteed and should be reviewed before being served to users. The Cortex Agents overview describes that runtime and review expectation.
A deployment check worth adding
Teams adopting toolsets should test at least three states for every inherited capability: normal access, revoked USAGE, and a missing referenced agent. The expected result should not merely be “the request returned successfully.” It should assert that the required tool actually ran, or that the application surfaced a capability-degraded state.
Toolsets reduce duplicated configuration, but they also move part of an agent’s behavior into runtime dependency resolution. In Snowflake’s current contract, authorization failure is safe for access control and quiet for application behavior. Production monitoring needs to make that silence visible.
sources
- Snowflake Documentation — Agent toolsetsdocs.snowflake.com
- Snowflake Documentation — Cortex Agentsdocs.snowflake.com
comments · 0