Snowflake makes agent telemetry useful without making prompts provider-visible by default
Native Apps now redact orchestrator-authored content in consumer logs and require explicit approval before providers receive content-level telemetry.
Snowflake has added an observability boundary for Cortex Agents distributed through Snowflake Native Apps: providers can receive operational telemetry by default, but they do not automatically receive the agent’s content. That distinction matters for teams that need to troubleshoot an installed analytics agent without turning every prompt, instruction or generated answer into vendor-visible data.
Metadata first, content only with approval
The October 2 release says that when a Native App starts an agent through the REST agent:run API or SQL DATA_AGENT_RUN, Snowflake redacts orchestrator-authored content before writing the consumer’s event-table record. If the consumer enables event sharing, the app provider receives telemetry at the AI_METADATA level by default. Moving to AI_CONTENT requires the consumer to approve a SHARE_AI_OBSERVABILITY_CONTENT app specification.
That creates two separate decisions: whether to share agent telemetry at all, and whether the shared record may include content. For operators, the practical test is not simply “does the app support tracing?” It is which sharing level is active, who can approve a content escalation and whether that approval is appropriate for the data the agent handles.
The access boundary is separate
Snowflake’s Native App documentation says app-created Cortex Agents run under restricted caller’s rights. Every tool call needs both the consumer user’s privilege on the target object and a caller grant from the consumer administrator to the application. Snowflake also says restricted-caller chains compose by intersection, so an additional link can make access narrower but not broader.
The same documentation limits app-created Snowflake-managed MCP servers to app-owned tools and excludes the SYSTEM_EXECUTE_SQL tool. Consumer-owned semantic views, tables and workspaces require explicit caller grants. Before granting users access, Snowflake recommends that administrators inspect the full agent specification—including its model, tools, system prompt and referenced objects—with DESCRIBE AGENT or the agent UI.
What buyers should verify
The release improves the default disclosure posture, but it does not replace deployment review. A buyer should record the app’s caller grants, the users allowed to invoke it, the telemetry-sharing level and the administrator permitted to approve content sharing. It should also test what is actually present in provider-visible traces at AI_METADATA and after AI_CONTENT approval.
The useful design choice is that execution access and observability disclosure are controlled separately. An agent may be allowed to query consumer data without automatically exposing its conversational content to the app provider. That makes debugging possible while keeping content sharing an affirmative consumer decision rather than a side effect of installing the app.
sources
- Oct. 2, 2026: Snowflake Native Apps — Observability for Cortex Agentsdocs.snowflake.com
- Use Cortex Agents and MCP servers in a Snowflake Native Appdocs.snowflake.com
comments · 0