Snowflake’s agent object enhancements make it easier than ever to move from AI agent experimentation to governed production deployment without treating every agent as a long-lived, broadly visible shared asset. Temporary agents, Personal Database agents, and secure agents each reduce friction, including setup friction, specification exposure, or shared-environment dependency. Together, these three new agents support a practical operating pattern.

Temporary Agents: Fast, Disposable Experiments

A temporary Cortex Agent is scoped to the user, role, and session that created it. You can create one with CREATE TEMPORARY AGENT or CREATE TEMP AGENT and then test the temporary agent’s instructions, tools, orchestration settings, and semantic-model behavior. Afterward, Snowflake drops the temporary agent automatically when the session ends. It’s important to note that a temporary agent can’t be recovered, converted into a permanent agent, or versioned.

The important developer-experience advantage is that creating a temporary agent doesn’t require the CREATE AGENT privilege on the target schema. As a result, this makes temporary agents very useful for prototyping in notebooks and for early semantic-view or tool-configuration testing without needing to make an access-control request. And because temporary agents are not visible to other users and sessions, they support teams failing fast without cluttering a shared agent catalog or leaving any experimental agents behind.

Personal Database Agents: A Private Development Lane

Snowflake now allows users to create agents in their own Personal Database, named USER$<username>, by using the PUBLIC schema. This creates a user-specific development location without requiring access or object creation privileges in a shared database.

Personal database agents are useful when an analyst, architect, or agent developer needs a persistent place to independently build and test and an agent. The advantage is that users don’t need to negotiate a shared schema to begin creating agent objects. However, the underlying data permissions still exist and the agents and their tools still need appropriate access to the data objects they use.

These features make Personal Database agents effective for personal proof-of-concepts, prompt iteration, training, and for creating reusable agent templates before a team promotes the design into a governed shared environment.

Secure Agents: Protect the Production Specification

A secure agent is a Cortex Agent created with the SECURE designation or updated with SECURE = TRUE. The purpose of a secure agent is for controlling who can inspect the implementation details and not about changing who can invoke the agent.

For example, roles that have USAGE or MODIFY privileges but don’t have the agent owner role, Snowflake hides the full agent specification.

• DESCRIBE AGENT returns NULL for the agent specification
• GET_DDL for the agent omits the specification
• SHOW VERSIONS IN AGENT doesn’t disclose protected version details in the same way as an owner session
• Snowsight resource descriptions and stage access won’t expose the specification to non-owners

All of this matters because an agent specification can encode valuable and sensitive implementation details including system prompts, business instructions, model and orchestration settings, tool configuration, semantic-view references, and the structure of the grounded data experience. A secure agent enables the production team to grant people the ability to invoke or modify the agent without broadly exposing the contract.

As a result, secure agents are a production hardening measure. They preserve operational access while reducing accidental disclosure, prompt copying, and unauthorized inspection.

A Production Operating Pattern for Agents

Moving an agent from an individual experiment to a dependable enterprise capability isn’t simply a matter of changing its name, schema, or access grants. The agent’s lifecycle needs to account for how quickly develpers can test an idea, whether they can safely iterate on prompts and tools, who can inspect or change the implementation, and how the organization prevents a production agent from becoming an undocumented dependency.

Snowflake’s temporary agents, Personal Database agents, and secure agents map naturally to those distinct stages. This allows teams to adopt a deliberate progression rather than forcing every use case into a shared, permanent object that is a fully inspectable object from day one.

Temporary agents minimize the overhead of validating an idea. Personal Database agents establish a private development late. Secure agents ensure that a production agent can be used operationally without turning its full specification into discoverable metadata.

There’s less friction to experiment, it’s safer to deploy agents, and the risk of accidental breakage is decreased. The addition of these three new Snowflake agents ensures enterprise teams can build production-ready Snowflake agents with less friction using a mature agent lifecycle.