Extending Snowflake's Identity Model to AI Agents

Ask a security reviewer what they actually want to know before approving a Cortex pilot, and it usually comes down to one question: which human was behind this specific query? For a person logging into Snowflake, that's trivial. SSO resolves the user, masking and row-access policies apply to that identity automatically, the audit log has their name on it.

Agents mostly don't log in that way. One service credential, shared across a whole workflow, so the entitlements resolve to what the application can see rather than to any one person. I've watched this exact thing stall a Cortex pilot that had nothing wrong with it technically, the reviewer just couldn't get an answer to "who was this."

Resolving identity at the gateway

TrustAI sits in front of whatever's already running, whether that’s Cortex Agents, Copilot Studio, LangGraph, or any MCP client, and does token exchange: it resolves the human identity on-behalf-of the agent, end to end, using RFC 8693. Since "gateway" gets overused: this isn't a proprietary session hack, it's the standard OBO token-exchange pattern already used for delegated auth elsewhere, applied at the point where an agent's request meets Snowflake's managed MCP server.

The gateway functions as a PDP/PEP sitting between the identity provider (Entra ID, Okta) and Snowflake itself. Two ABAC paths run through it, one combining user and agent attributes for interactive calls, another handling agent-only attributes for CI/CD and non-human identity flows. Attributes sync from the IdP in real time, so a joiner-mover-leaver change updates policy without anyone re-provisioning anything by hand. 

Snowflake's own masking and row-access policies do the actual enforcing here, not TrustAI. TrustAccess writes those as native Snowflake objects, so there's no proxy in the human data path and no added query tax. That last part matters more to some architects than the identity piece does, honestly.

Intent is the harder question

RBAC tells you who someone is. ABAC adds their attributes. Neither one answers whether this specific request fits what the agent's supposed to be doing, and for agents that question carries more weight than it ever did for a person, since one agent identity can fire off far more requests than any single human would.

It works as a request/response envelope rather than a static rule table. Every tool call becomes a POST to an intent-evaluation endpoint. The gateway pulls the agent's declared attributes, purpose, department, agent or user ID, hands the request plus a natural-language description of it to an intent engine (LLM-based, Bedrock or OpenAI-compatible), and gets back an allow/deny decision with a stated rationale and whatever restrictions apply. The PEP then enforces that against the actual data source.

Take a sales agent running two queries back to back. "Total sales revenue by region this quarter" resolves cleanly, financial-analysis purpose, in scope, allowed. "Export all customer data including SSNs and credit card numbers" gets flagged, PII and financial credentials sitting well outside declared scope, and a bulk export like that looks a lot more like exfiltration than analysis. Same credentials both times. The intent check is the only thing that differed.

What a security reviewer actually gets

Security review usually wants three things: 

• who made the call, 
• what they were entitled to touch, and 
• why this particular request was in scope. 

Log all three per request, and that's usually enough to unstick a stalled Cortex rollout. The use case was rarely the real objection, the missing evidence was.

Some datasets get held back from Snowflake entirely over governance concerns. TrustDSPM discovers and classifies that data first, working off labels already in place, like Purview tags and Snowflake object tags, rather than replacing them. It also monitors activity without needing database agents to be installed. From there, TrustAccess turns those findings into enforced native masking and row-access policies. It’s not a report sitting in a dashboard. It’s actual policy.

Audit season raises a different problem: legacy database activity monitoring usually doesn't cover cloud platforms at all. TrustDSPM's monitoring and TrustAccess's entitlement analytics close that gap, comparing grants against actual usage and flagging or revoking what's unused, across Snowflake and whatever legacy estate is still in play.

How this shows up in deployment

One enterprise runs TrustAI as a single MCP control plane across several agent runtimes at once, Snowflake being one governed source among several others. Identity resolution is end-to-end OBO per RFC 8693, confirmed through the full request chain, so policy stays consistent no matter which runtime or vendor actually made the call.

Another organization puts an internal search and RAG platform behind the TrustAI gateway as its one enforcement point. Agents authenticate to the gateway instead of connecting to Snowflake or other sources directly, human identity carries through to the data layer, and every call gets allowed, denied, and logged centrally.

Get into production

Dynamic masking, row-access policies, object tagging, Trust Center posture checks, all of it stays exactly where it is. TrustLogix's layer writes and maintains the native policies at scale, extends the same ABAC model out to platforms like Databricks, and gives agents the identity resolution they'd otherwise be missing entirely.

For teams running Cortex or trying to move regulated data into Snowflake with something to actually show a reviewer, native enforcement plus resolved identity plus intent checking tends to be what gets a project out of review and into production.