Agentic AI in Action, Part 31: Hands On with Temporary, Secure, and Personal Agents in Cortex

Snowflake rolled out three enhancements to its Cortex Agents object: temporary agents that exist only for the current session and require no CREATE AGENT privilege on the schema, secure agents that hide the agent specification from anyone who does not own the object, and personal database agents that give each user a private sandbox without a shared dev database and its grants. The temporary-agent capability removes the permanent schema-level objects that each experimental iteration previously left behind, with the agent disappearing automatically when the session ends. The walkthrough builds each agent type against a single semantic view, my_db.my_schema.sales_semantic_view, over a 12-row SALES_FACT table with a known-correct answer of 503000 for the highest-revenue region.

Snowflake recently rolled out a set of Cortex Agents object enhancements, and they solve a set of small but real friction points that anyone building agents day to day will recognize. Three new capabilities matter most for practitioners. Temporary agents let you spin up a session scoped agent without touching the schema. Secure agents hide the specification from anyone who doesn’t own the object. Personal database agents give every user a private sandbox to build in, without needing a shared dev database and its grants. Worth walking through each one with a working example, all pointed at the same small semantic view, with a DESCRIBE AGENT after every creation so you can actually see what got built, not just take my word for it. Getting there takes a few short, separate steps, a database and warehouse, a table of sample data, a semantic view on top of it, then each of the four agent types in turn. Nothing here needs more than a couple of statements at a time. Everything in this post lives in one database and schema, my db.my schema, so there’s a single consistent name to follow rather than a different placeholder per section. Alongside it, create a small warehouse. If you would rather point at a warehouse you already have, skip the CREATE WAREHOUSE statement and swap my wh for your own warehouse's name everywhere it appears further down. A dozen rows across three regions, four quarters, and two products, enough for an agent to answer a real aggregation question rather than an empty one. A native Snowflake semantic view on top of SALES FACT, with a region and quarter dimension and a TOTAL REVENUE metric. This is what every tool bearing agent below actually queries against. Note: Every example below that uses a tool points at this same object, my db.my schema.sales semantic view. The unqualified agent names in the next two steps, my temp agent and my secure agent, assume the session is still sitting in my db.my schema from the USE statements in Step 1. Run each step’s statements in order in the same worksheet, or qualify the names yourself if you’re picking up a step on its own, the way the COPY GRANTS and Personal Database steps already do. Let us perform a sanity check. Note: We will ask the agent below “which region has the highest total revenue”, so the above check gives us this known-correct number, “503000" to compare against. Most Cortex Agent development starts with a handful of experimental iterations. You are tweaking a semantic view binding, trying a different orchestration instruction, or testing whether a tool responds the way you expect. Before this release, each of those iterations created a permanent schema level object that someone eventually had to clean up. Temporary agents fix that. They exist only for the current session, are visible only to the creating user and role, and disappear automatically when the session ends. Creating one does not require the CREATE AGENT privilege on the schema. Let us go ahead and create one. Confirm the object exists and the semantic view binding is correct. DESCRIBE AGENT my temp agent; Close the session and the agent is gone anyway, nothing to drop, nothing left behind for someone else to find later and wonder whether it’s safe to delete. For a practice like ours, where developers are constantly prototyping agent configurations against client semantic models before anything goes to a shared dev environment, this removes a real source of clutter. I’d expect this to become the default mode for anything exploratory, with CREATE OR REPLACE AGENT reserved for what’s actually going into a demo or a client environment. Creating the object is one step, actually asking it something is a separate one. DATA AGENT RUN’s raw output is a single JSON payload holding the entire orchestration trace, the tool call into Cortex Analyst, the semantic model context it was handed, the SQL it generated, the query result, the model’s internal reasoning, the final answer, and a list of suggested follow up questions, all as elements of a content array. The query above flattens content and pulls out the one element whose type is text, which is the agent’s actual answer. Running it against this sample data returns a single row. That figure checks out against the sample data, North America’s four rows sum to 125000 + 138000 + 98000 + 142000 = 503000, so the semantic view’s total revenue metric is aggregating correctly. We had also verified this earlier when we ran a sanity check on the semantic view. If you want to see the SQL Cortex Analyst actually generated rather than just the answer, the same payload carries it a few levels deeper, in the tool result element for system execute sql, under its sql field. No DROP AGENT needed. The object disappears automatically when the session ends, and it was never visible to any other user or role. The second enhancement addresses a governance gap that shows up as soon as an agent’s configuration becomes something you don’t want every consumer to see. An agent specification can include orchestration instructions, tool bindings, and sometimes proprietary prompt engineering that took real effort to get right. Under the old model, anyone with USAGE on the agent could run DESCRIBE AGENT or GET DDL and read the whole thing. Secure agents close that off, following the same model Snowflake already uses for secure views and secure functions. Run that DESCRIBE AGENT as the owner and you’ll see all eight columns filled in, including the full JSON in agent spec. This is the one I'd flag hardest for client engagements. When we hand an agent over to a client's business users, we often don't want them accessing the orchestration instructions or the exact tool wiring, either because it's genuinely proprietary or because exposing it invites people to try to reverse engineer prompt behavior. SECURE gives us that separation without a second layer of custom access control. DESCRIBE AGENT my secure agent; Notice the agent spec coulmn that provides the agent specific orchestration details. This is the one we will subsequently hide from other roles. Create a role “test role”, in this example that has nothing to do with the agent’s ownership, grant it USAGE, and run DESCRIBE AGENT from there. By default this still comes back with the full agent spec, because it defaults to USE SECONDARY ROLES ALL. If ACCOUNTADMIN is the role you’ve used throughout, turning secondary roles off removes ACCOUNTADMIN from that set and leaves test role on its own, which is what actually triggers the redaction. Notice now that the agent spec column returns empty, hiding all the configuration and orchestration instructions. That’s the whole behavior change, nothing else about how the agent runs or answers is different. GET DDL omits the specification the same way, Snowsight’s agent spec field returns NULL in its resource view, and stage reads through GET or LS now require OWNERSHIP rather than USAGE alone. Execution itself is untouched, the agent:run endpoint, DATA AGENT RUN, and any task invoking the agent still load the full specification internally, so end users see no change in how the agent answers. Let us now restore the role before proceeding to the next section. Every Snowflake user already has a Personal Database, mostly used for scratch tables and one-off notebooks. This release extends that to agents. You can now create and run an agent directly in the PUBLIC schema of your own Personal Database, using nothing more than your own default privileges. Personal Database names follow the USER$<your username format, and the name needs to be in double quotes because of the special character. This example lives in its own location, and for simplicity we will point at sales semantic view, the same semantic view every other agent in this post uses, so it answers from the same sample data. Swap in your own username before running this. The DESCRIBE AGENT output below confirms it, database name comes back USER$KRISHNAN, schema name comes back PUBLIC, and owner also reads USER$KRISHNAN, the database and the owning role share the same name, since a Personal Database is owned by the user it belongs to. The object sits there, even though the semantic view it queries lives in my db.my schema. The practical benefit here is that it it removes a specific piece of setup friction. A developer who wants to try something persistent, something they intend to keep around past one session but don’t yet want to put in a shared schema, no longer needs someone to grant CREATE AGENT on a dev database first. Their Personal Database is already theirs. Let us now run this. Same fully qualified agent name, and the same FLATTEN extraction pattern, with the same QUALIFY narrowing it to the last text element. The answer comes back grounded in Widget A and Widget B from SALES FACT, as the agent, sitting in your own Personal Database, is querying the exact same semantic view as the temporary and secure agents above. A smaller fourth change rides along with these three. CREATE OR REPLACE AGENT now supports COPY GRANTS, which preserves explicit privileges, other than OWNERSHIP, when an agent is replaced. To actually see this in action, create the agent, grant a second role USAGE on it, then replace it with COPY GRANTS. Let us first create an agent to grant, so there’s something to replace. We will grant usage to the test role which we had previously created. Now replace it. Without COPY GRANTS, the GRANT above would need to be reissued, the replaced object starts with a clean grant slate otherwise. Anyone who has had to re-run a batch of GRANT statements after every CREATE OR REPLACE AGENT during iterative development will appreciate this one. Confirm that the granted role can call the agent. test role gets back the same North America answer as Step 5. USAGE survived the replace without a single GRANT statement re-run. Put together, these four changes describe a fairly clear intent from Snowflake. Temporary agents and Personal Database agents lower the friction of building and iterating. Secure agents and COPY GRANTS tighten up what happens once an agent is ready for production and needs to be shared, governed, and maintained without losing its access history. For our Cortex practice, the workflow this suggests is straightforward. Prototype with a temporary agent in a session, or a persistent one in your Personal Database if you want to come back to it. Once the configuration is solid, promote it into the shared schema as a secure agent, with COPY GRANTS, as required, carrying the access controls forward on every subsequent replace. It closes a real gap between prototyping and production that we would mostly been working around by hand until now. The code files for this blog can be accessed here. https://github.com/Krishsriniv/cortex agent types demo I share hands-on, implementation-focused perspectives on Generative & Agentic AI, LLMs, Snowflake and Cortex AI, translating advanced capabilities into practical, real-world analytics use cases. Do follow me on LinkedIn and Medium for more such insights. Agentic AI in Action, Part 31: Hands On with Temporary, Secure, and Personal Agents in Cortex https://pub.towardsai.net/agentic-ai-in-action-part-32-hands-on-with-temporary-secure-and-personal-agents-in-cortex-03b23a1f7ec5 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.