{"slug": "agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents", "title": "Agentic AI in Action, Part 31: Hands On with Temporary, Secure, and Personal Agents in Cortex", "summary": "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.", "body_md": "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.\n\nWorth 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.\n\nGetting 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.\n\nEverything 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.\n\nIf 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.\n\nA 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.\n\nA 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.\n\n*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.*\n\nLet us perform a sanity check.\n\n*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.*\n\nMost 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.\n\nTemporary 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.\n\nLet us go ahead and create one.\n\nConfirm the object exists and the semantic view binding is correct.\n\nDESCRIBE AGENT my_temp_agent;\n\nClose 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.\n\nFor 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.\n\nCreating the object is one step, actually asking it something is a separate one.\n\nDATA_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.\n\nThat 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.\n\nNo DROP AGENT needed. The object disappears automatically when the session ends, and it was never visible to any other user or role.\n\nThe 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.\n\nSecure agents close that off, following the same model Snowflake already uses for secure views and secure functions.\n\nRun 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.\n\nDESCRIBE AGENT my_secure_agent;\n\nNotice the agent_spec coulmn that provides the agent specific orchestration details. This is the one we will subsequently hide from other roles.\n\nCreate 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.\n\nBy default this still comes back with the full agent_spec, because it defaults to USE SECONDARY ROLES ALL.\n\nIf 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.\n\nNotice now that the agent_spec column returns empty, hiding all the configuration and orchestration instructions.\n\nThat’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.\n\nLet us now restore the role before proceeding to the next section.\n\nEvery 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.\n\nPersonal 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.\n\nSwap in your own username before running this.\n\nThe 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.\n\nThe 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.\n\nLet us now run this.\n\nSame 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.\n\nA 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.\n\nLet us first create an agent to grant, so there’s something to replace.\n\nWe will grant usage to the test_role which we had previously created.\n\nNow replace it. Without COPY GRANTS, the GRANT above would need to be reissued, the replaced object starts with a clean grant slate otherwise.\n\nAnyone who has had to re-run a batch of GRANT statements after every CREATE OR REPLACE AGENT during iterative development will appreciate this one.\n\nConfirm that the granted role can call the agent.\n\ntest_role gets back the same North America answer as Step 5. USAGE survived the replace without a single GRANT statement re-run.\n\nPut 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.\n\nFor 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.\n\nThe code files for this blog can be accessed [here.](https://github.com/Krishsriniv/cortex_agent_types_demo)\n\n*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.*\n\n[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.", "url": "https://wpnews.pro/news/agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents", "canonical_source": "https://pub.towardsai.net/agentic-ai-in-action-part-32-hands-on-with-temporary-secure-and-personal-agents-in-cortex-03b23a1f7ec5?source=rss----98111c9905da---4", "published_at": "2026-10-22 05:05:26+00:00", "updated_at": "2026-10-22 05:40:04.206139+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "developer-tools"], "entities": ["Snowflake", "Cortex Agents", "Cortex Analyst", "DATA_AGENT_RUN", "my_db.my_schema.sales_semantic_view", "SALES_FACT"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents", "markdown": "https://wpnews.pro/news/agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents.md", "text": "https://wpnews.pro/news/agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents.txt", "jsonld": "https://wpnews.pro/news/agentic-ai-in-action-part-31-hands-on-with-temporary-secure-and-personal-agents.jsonld"}}