For nearly thirty years I have watched cybersecurity change alongside the technology it is meant to protect. Self-contained networks gave way to the internet, then virtualization, cloud, SaaS, APIs and sprawling data estates. Every shift brought new architecture, new products and new vocabulary.

One question never changed: who, or what, are we trusting with access to our information?

AI agents make that question much harder to answer. And Snowflake’s recent work on AI agent identity is one of the clearest signs I have seen of a major platform treating agents as what they are becoming: non-human identities with real authority.

Framing

We have seen this pattern before

When cloud computing took off, workloads moved quickly and governance caught up later. The same happened with SaaS, then APIs, then machine identities. Each time, the technology solved a real business problem and adoption raced ahead.

And each time, security teams discovered that the hardest part was not securing the technology itself. It was understanding who had access to what, through which path, under whose authority, and with what evidence.

Agents add a new dimension. They don’t just run a fixed sequence of instructions. Give an agent an objective and it may work out the intermediate steps, pull information from several systems, call tools and act on the result. That is powerful. It also changes the trust model.

So I don’t think we should look at an agent as an AI application. We should look at it as an identity with authority, and often a privileged one.

The next privileged identity inside your enterprise may not be a person. It may be an agent.

Architecture

Two kinds of agent, one identity problem

For years most security professionals thought of Snowflake as a cloud data platform. That description is now incomplete. Cortex AI brings models to governed enterprise data, and the platform increasingly gives agents ways to act on that data and reach other systems.

One detail in Snowflake’s agent identity documentation deserves more attention than it gets. It separates delegated agents, which act on behalf of a user, from autonomous agents, which act under their own identity through a dedicated SERVICE_AGENT user type. That user type became generally available in July 2026.

Identity and access management has spent decades organized around two categories: people, and non-human identities such as service accounts, workloads and applications. Agents fit neither cleanly. They are non-human, but their behavior is dynamic. They may act alone or under delegated authority, touch several systems in a single task, and change course based on what they find along the way.

That is an identity problem, an authorization problem and an accountability problem at the same time.

Access

“Can it access the data?” is no longer enough

Traditional access control asks one question: is this identity permitted to access this resource? With agents, that is only where the conversation starts.

• Who authorized the agent, and is it acting for a person or on its own?
• What can it retrieve, and which tools can it invoke?
• Can it combine information from different security domains?
• Can it send information outside the environment, and what happens to what it creates?
• Can we reconstruct exactly what it did afterward?

That last row matters most, and Snowflake is designing for it. Query history records the agent that directly invoked each query in an agent_type column, and access history captures the chain of agents involved, from the nearest agent up to the top-level one. That is not an AI feature. That is security architecture.

When an employee with privileged access does something sensitive, mature organizations expect the action to be attributable. There is no good reason to accept a lower standard from an autonomous system capable of the same action.

Least privilege

Least privilege for AI agents that can reason

Least privilege is easy to state: give an identity only the access it needs to do its job. It has always been hard to implement. Agents make it harder, because of something intelligence analysts call the mosaic effect: pieces of information that are harmless on their own become sensitive once they are combined.

Picture an agent with legitimate access to the project ticketing system and legitimate access to vendor payment records. Both permissions pass review. Then someone asks it an innocent question about budget pressure next quarter. The agent links a confidential project codename to a spike in payments to an M&A advisory firm and outside counsel, and effectively reveals an unannounced acquisition.

Every permission was correct. The outcome was never authorized. In an agentic environment we cannot think only about what an identity can read. We have to think about what it can infer, combine, create, communicate and execute. That is a much larger security boundary.

Snowflake offers a useful building block here. A context function, IS_AGENT_ACTIVATED, lets a data protection policy behave differently when an agent is active, so sensitive values stay hidden from the agent even when the person behind it would be allowed to see them.

CREATE OR REPLACE MASKING POLICY mask_pii_for_agents
 AS (val STRING) RETURNS STRING ->
 CASE
 WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN
 THEN '** withheld from agents **'
 WHEN IS_ROLE_IN_SESSION('PII_READER') THEN val
 ELSE '********'
 END;

A policy like that won’t solve the mosaic problem on its own. But it lets you draw a tighter boundary around agents than around the people they serve, which is exactly the direction least privilege needs to go.

Control plane

Choke points: gateways, MCP and logging

Why the gateway matters

Cortex AI Gateway entered preview in September 2026 as a central control plane for how AI applications and third-party agents reach models, with per-request tracing and usage reporting built in.

For me, the concept matters more than the product. As organizations move from a handful of agents to dozens and eventually hundreds, letting each one build its own direct relationship with models, tools and data becomes ungovernable. Security needs choke points. Not to block everything, but to see what is happening and enforce policy where it counts.

One nuance is worth knowing. Snowflake is explicit that the gateway governs the path traffic takes, not the set of models a user is entitled to. A choke point gives you visibility and control over the route. It does not replace entitlement management.

MCP multiplies the paths

The Model Context Protocol gives agents a standard way to reach tools and context. For developers, that removes a lot of friction. For security teams, every connection is another route between an agent and an enterprise capability, one that might be harmless, or might query customer records, change code or kick off a business process.

So the question can’t be “do we support MCP?” It has to be: which servers do we trust, which tools do they expose, which agents can call them, under whose authority, with what data, and what happens to the result? That is the same question we already ask about APIs, privileged access and third-party integrations. The technology is new. The security problem is not.

More logging is not automatically better security

Security teams want prompts, responses and tool calls available for investigations. Privacy and legal teams will reasonably ask what exactly is being stored. A prompt can contain personal data, credentials, intellectual property or regulated material, and so can a response. Without care, your security telemetry quietly becomes one more sensitive data repository.

Snowflake’s gateway reflects that tension. It records traffic at the metadata level by default and captures prompts and responses only when payload logging is switched on. That is the right default, and the right mindset. Logging should be a risk decision, not a checkbox.

Lessons

The 2024 lesson: capability is not configuration

In 2024, threat actors got into a number of Snowflake customer environments using stolen credentials, many harvested by infostealer malware. Investigations pointed to accounts without multi-factor authentication and to customer-side identity and configuration weaknesses, not a compromise of Snowflake’s underlying platform.

That distinction carries straight into AI. You can have agent identities, masking policies, gateways, logging and excellent documentation. If an agent is given excessive permissions, connected indiscriminately to sensitive systems and never watched, none of those capabilities will compensate for weak governance.

We learned this with cloud. We learned it with identity and with SaaS. We should not have to learn it again with agents.

Direction

The bigger shift is authority

The first phase of enterprise generative AI was about information. We asked questions, and models gave answers.

The next phase is about authority. We are starting to let agents make things happen: read the document, query the database, create the ticket, change the code, contact the supplier, start the workflow, and perhaps one day approve the transaction.

Once AI moves from generating information to exercising authority, identity becomes central.

When agents begin working with other agents, the scale changes again. An organization could have thousands of non-human identities negotiating access, exchanging context and acting across cloud environments, with no human approving each step. Quarterly access reviews will not keep up.

I expect identity governance to become continuous and contextual. An agent will be authorized not just by who it is, but by who started the task, what the task is, what data is involved, which tool it wants to use, where the result is going and how much risk the organization is willing to accept at that moment.

Some of this is genuinely new. Prompt injection and model behavior deserve specialized attention. But most of what organizations will struggle with is familiar: identity, authorization, data classification, least privilege, third-party trust, monitoring, privacy and accountability. AI doesn’t make those disciplines obsolete. It raises the cost of getting them wrong.

Interactive

Is this agent ready for authority?

Not which model it uses. Not how impressive the demo was. These are the nine questions I would want answered before approving any enterprise agent.

Action

Three things to do before your next agent goes live

1. Inventory every agent and give each one an ownerInclude third-party coding agents and every MCP connection that touches your data, not just the agents your teams built. An agent nobody owns is the new orphaned account.
2. Separate agent identity from human identityGive autonomous agents their own identities, such as a SERVICE_AGENT user in Snowflake, instead of shared credentials baked into scripts. Then use agent-aware policies so sensitive data stays masked whenever an agent is active, including in delegated sessions.
3. Put a choke point in the path, and decide what it keepsRoute model and tool traffic through a gateway you control. Then make a deliberate, documented decision about whether prompts and responses are retained, for how long, and who can read them.

None of that depends on which model you choose.

The products will change quickly, and some of today’s terminology will fade. The governance problem will not. After three decades in this field, I have learned not to confuse a new technology with a new security principle. We still need to know what we are protecting, who has access, and who is accountable for the decision.

The organizations that get this right won’t be the ones that slowed AI adoption down. They will be the ones that understood autonomy without accountability is not a security architecture.

FAQ

Common questions

This perspective reflects Snowflake product status as of 17 September 2026. Cortex AI Gateway was in preview at the time of writing. Product names and availability change quickly, so verify current documentation before making architecture decisions.