Head-to-head · updated 13 September 2026

DataShield vs Cortex Search: who gets to read what the index already swallowed?

Snowflake Cortex Search is the retrieval half of RAG. It ships as part of the warehouse you own. Their docs are direct about it. It gives you "low-latency, high-quality 'fuzzy' search over your Snowflake data." You pick a source query. Snowflake picks an Arctic or Voyage embedding model. You get hybrid keyword plus vector search. Plus semantic reranking. No vector database to run. No embedding pipeline to babysit. Your documents sit in Snowflake? This is the cheapest good search you will ever switch on.

We do the same job, from a new angle. DataShield is a self-hosted plane for agents: data and rules both. RAG is one part of it. We tokenize datasets at ingest. Agents then query tokenized data over MCP. Turning a token back is a privileged, audited step. We compute embeddings locally, with nomic-embed-text. Nothing leaves your machines to become a vector. We re-check each governed tool call against the agent's current authority. We seal each check into a hash chain. You can verify it, with no need to trust us. Most Snowflake shops will run both. Below is the honest split. It includes the rows Cortex Search wins outright.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

The documents hold PHI, card data or secrets. You want the sensitive values swapped for tokens, before anything gets embedded. The index then holds stand-ins, not the real thing.
Someone will ask you to prove an agent's retrieval log was not edited. An auditor, a regulator, or Article 12 of the EU AI Act. Our chain answers with math. Run the verifier.
Different readers must see different rows. A Cortex Search service searches with the owner's rights. So the index can return rows the asking user could not read in the source table.
The rule says the data, the embeddings and the keys stay on your side. We are self-hosted. Snowflake is not. No region setting changes that.

Pick Cortex Search when

Your corpus lives in Snowflake. No pipeline to build, no data to move, no second bill to explain.
You want managed embeddings and semantic reranking, with nobody on staff tuning an index. Four embedding models, one command, done.
Scale is the hard part. A single service indexes up to 400 million rows. The refresh runs on Dynamic Tables logic your team already knows.
You want retrieval, text-to-SQL, charts and a Python sandbox behind one agent API. Your procurement team has cleared this vendor.

Bottom line: Cortex Search is very good at finding the right passage fast. It is not trying to decide which agent may read that passage. It does not hide the value before it gets embedded. It does not prove later what happened. Your corpus is public, or internal-safe? Use theirs. Is it regulated? Then the index itself becomes the risk. That is our part of the job.

Feature by feature

Competitor cells describe what Snowflake's public site, docs, and press releases say. As of the date above. Did we get something wrong? Email support@myorg.ai and we will fix it, credited.

What matters	DataShield	Cortex Search	Edge
Retrieval quality and scale	Hybrid retrieval on Postgres pgvector: a tsvector keyword leg and a vector leg, 768 dimensions from nomic-embed-text. Good, plain, and ours to tune. We publish no accuracy benchmark. We have not run one worth publishing.	Managed hybrid search, with semantic reranking and four embedding models. Plus a 32,000-token multilingual option. A service indexes up to 400 million rows. It serves 20 queries per second by default. This is a real engineering asset. We won't pretend otherwise.	◇
Who can read the index	Retrieval runs under the agent's own tool token. Corpus visibility is explicit: personal or org-visible, moved by an audited promote or demote. Chunk views apply read-time masking. The keyword index is rebuilt from the masked text. Search cannot probe for a hidden value.	Services search with the owner's rights. Snowflake's own docs give a warning. Any role able to query a service may query any of the data the service has indexed. It says so regardless of that role's rights on the underlying objects. That includes rows behind row-level masking rules. Per-user row filtering is not how it works.	◆
Data handling and tokenization	Deterministic, join-safe, vault-reversible tokens, set at ingest. Plus quasi-identifier generalization. Dates go to year, decade, or age band. ZIPs go to 3 or 4 digits. Phones, SSNs, and emails get part masked. Each column gets its own cardinality score. Turning a token back needs admin tier, tenant-scoped, and it blocks if the log write fails.	The Cortex Search docs we read describe no PII or PHI check step, before the text gets embedded. No tokenize or generalize step, either. Platform masking rules exist in Horizon. The owner's-rights note above shows how far they reach into a search service.	◆
Where embeddings are computed	Locally, by a model that runs on your own hardware. We never send chunk text to a third party to turn into a vector. For a PHI corpus, that's the gap between a short review and a long one.	Snowflake computes them for you, on Snowflake infrastructure, billed as EMBED_TEXT tokens. That is a feature for most buyers, and a blocker for a few. Voyage is a third-party model family, served inside the platform.	◆
Prompt egress	We do not proxy your LLM traffic. We do gate each value that leaves a governed dataset for a prompt. A PHI dataset refuses an endpoint with no BAA. We redact a classified column with no set rule, rather than pass it through.	Cortex Agents call models inside Snowflake, which keeps traffic on the platform. We found no published per-column exit gate, and no BAA-aware endpoint refusal for prompt assembly.	◆
Audit evidence	A SHA-256 hash chain, with Ed25519-signed checkpoints, themselves chained. A check returns clean, damage found, or tampered. It names the failure: tampering, insertion, deletion, or truncation. Try the verifier.	The Cortex AI Gateway gives "a centralized, end-to-end record of agent activity." Agents ship threads, logs, and traces. The managed MCP doc says nothing about audit logs. We found no published tamper-proof way to check it.	◆
Agent authorization	Every governed tool call passes a scope ceiling, a consented-tool allowlist, and an authority tier. It also passes a metering guard and a revoke re-check before it goes out. It fails closed.	Snowflake OAuth, plus role-based access control. Grants on the MCP server object gate tool discovery. SQL execution defaults to read-only, a sound default. The unit of authority is still the role, not the call.	◆
Break-glass	Scoped, time-boxed emergency access for agents. Admin and IP-allowlist gated. It auto-revokes. It cannot be quietly removed from the log.	Not described in their public material.	◆
GDPR erasure	Crypto-shred of per-subject key material, cited to ISO/IEC 27040 and Article 17. Plus ISO 27560 consent receipts. The audit chain still checks out afterward.	Delete the row. The service picks it up on its next refresh, at the lag you set. That removes the row. It does not destroy key material. It says nothing about vectors served into a model context.	◆
MCP and agents	More than 200 MCP tools, across Ontology, Auth, Corpus, and Lighthouse. Tool tokens carry scope ceilings, plus RFC 8693 delegation with an enforced ceiling. Per-call metering ties back to the agent.	A managed MCP server, with five tool types, and a cap of 50 tools per server. Plus Cortex Agents. It runs search, text-to-SQL, charts, a Python sandbox, and web search. The July 2026 Cortex AI Gateway governs agent access, across more than 100 MCP servers.	◈
Deployment	Self-hosted, in your own cloud or data center. Or on a single-tenant server we run for you. Docker images cover Auth, Ontology, Corpus, and Lighthouse, with a signed deploy manifest that Guardian checks. Audit-signing keys stay on your instance, in a key folder you control. Key rotation fails closed on an unknown key. KMS or HSM custody is a built seam in Auth, not a shipped link. Tokenization keys sit in your environment today, not in a KMS.	SaaS only, on AWS, Azure or GCP. Virtual Private Snowflake is still Snowflake-run. The managed MCP server is not supported in government regions.	◆
Maturity signals	Auth, Guardian, and Lighthouse are live in production. Guardian and Lighthouse have run since April 2026. SOC 2 not yet certified, and we say so.	Public company, thousands of enterprise accounts, platform-level certifications. Named reference customers such as Thomson Reuters and Sanofi. We cannot match that, and will not try.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Consumption across several meters at once. Warehouse compute for refresh, EMBED_TEXT tokens, serving compute per GB per month, and storage. Dollar rates are not on the page. The site sends you to the Service Consumption Table.	◆

◆ DataShield leads◇ Cortex Search leads◈ comparable

Snowflake claims are drawn from docs.snowflake.com, snowflake.com, and Snowflake's own press releases. Last checked 13 September 2026. We link them below rather than work from memory.

Three things you get here that you won't get from a warehouse-native retrieval service

Tokens go in, not secrets

An index is a copy. Chunk a social security number, embed it, serve it. Now it lives in more places than you can point at. We take the value out at ingest. We park the vault outside the query path. A token goes into the index, not a secret. A hijacked agent pulls back a token. That token resolves to nothing it can use. How the data plane works.

Proof that leaves with you

Retrieval logs matter now. An examiner will ask which agent read which document in March. And whether the record was changed since. Ours is a hash chain with signed checkpoints. The verifier says what broke. Not just that something did. It keeps checking after export. After a move, too. Even in front of someone with no login to your platform. Try it in your browser, no signup.

Authority that can change mid-flight

An analyst leaves on a Friday. Their research agent is 20 minutes into a 40-minute job over the policy corpus. With DataShield, the next governed tool call gets checked again. Against current authority. It fails closed. Not at the next token refresh. The next call. How Auth does it.

Where Snowflake Cortex Search is genuinely stronger

Let us be fair about the thing we are up against. Cortex Search is a serious managed search tool. You point it at a query. It handles chunking, embedding, refresh, and reranking. It scales to 400 million rows, with no new database for you to learn. The model menu goes from a 768-dimension English default up to a multilingual model with a 32,000-token window. Refresh reuses Dynamic Tables logic, so the behavior feels familiar to your team. Around it sits Cortex Agents. It strings search together with text-to-SQL, charts, a Python sandbox, and web search, behind one API. Then the Cortex AI Gateway, announced 28 July 2026, adds access rules. It also adds an end-to-end record of agent activity, across more than 100 MCP servers. Your data is in Snowflake? Building your own search stack to match this is a strange way to spend a quarter.

Here is the push-back that matters. It's one line from their own docs. A Cortex Search service "performs searches with owner's rights." So any role that can query the service can reach anything the service indexed. That includes rows behind masking rules that role could never read in the source table. That's a fair trade for a tool built to make search fast. It's a poor trade when the caller is an agent. An agent does not know it is holding something it should not have. It will happily quote that into an answer. Add three more gaps that regulated buyers feel. Nothing in the Cortex Search docs tokenizes or generalizes sensitive fields before the text gets embedded. The audit story is a record, not a proof. And there is no way to run any of it on your own hardware.

We built for the case where those three things are the rule, not the nice-to-have. For everything else, honestly, use theirs.

Questions worth asking both of us

These are the questions we would want answered if we were the ones buying. Ask them on each call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes. Each record commits to the one before it. Checkpoints are Ed25519-signed and chained. A check tells deletion apart from truncation and from tampering. Try it on a sample chain at /verify. Snowflake: the Cortex AI Gateway keeps an end-to-end record of agent activity. Agents produce threads, logs, and traces. We found no published tamper-proof method. Ask them to show one, and ask who can write to the table.

What happens to a revoked agent mid-session?

DataShield re-checks authority on each governed tool call. The pull lands on the very next call. The context drops to anonymous. Snowflake checks role grants. Pulling a grant stops new work. But we could not find published rules for a mid-session pull, in an in-flight Cortex Agent or MCP session. Ask how long a compromised agent keeps working after you cut its access.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds per-subject key material. It issues an ISO 27560 consent receipt too. Actor identities in the chain are HMAC-committed. The evidence still checks out once the subject is gone. With Cortex Search, you delete the source row. Then you wait for the refresh lag you set. That is a delete, not key destruction. It leaves open what to do about text a model already saw. Ask for the mechanism, not the workflow.

Does Cortex Search apply row-level security per user?

Not in the way most people assume. This is the question to ask first. Their docs say services search with the owner's rights. A role able to query a service can reach data the service indexed. That holds even where the role has no right on the underlying objects. Including rows behind masking rules. The usual fix is attribute filters you pass at query time. That means your app is now the access control. Our answer is different. Sensitive values get tokenized before indexing. The index does not hold the thing you were protecting.

We are all-in on Snowflake. Do we rip out Cortex Search?

No, and anyone who tells you to is selling harder than they are thinking. Keep it for the corpora where speed matters and the content is internal-safe. Add us where the corpus is regulated. Also add us where the reader is an agent you cannot fully trust. Or where the proof has to check out outside the platform. Plenty of teams will sensibly run both. We also have a page on the governance layer next door: DataShield vs Snowflake Horizon.

Can you index data that lives in Snowflake today?

Not as a catalog provider. Our in-place scan and profile is GA for PostgreSQL only. Snowflake, BigQuery, Databricks, and S3 are named, but have no handler built yet. We would rather say that now than have you find out in week three. What works today: ingest the documents you want agents to read. Files, URLs, or S3-compatible storage. Extract PDF, DOCX, and EML text. Tokenize at ingest. Serve retrieval over MCP, under Auth.

Does DataShield have SOC 2?

Not yet, and we will not imply otherwise. Snowflake carries platform certifications we cannot match. For some buyers, that settles it. What we offer instead: a published threat model, and a verifier anyone can run. Also, design-partner terms that include source escrow. That way a small vendor is not a single point of failure. Details are on the security page.

Cortex Search "enables low-latency, high-quality 'fuzzy' search over your Snowflake data." It combines vector search, keyword search, and semantic reranking. With managed Arctic and Voyage embedding models, from 768 to 1024 dimensions. Plus a materialized result limit of 400M rows. - docs.snowflake.com, 13 Sep 2026
"Cortex Search Services perform searches with owner's rights." Also: "any role with sufficient privileges to query a Cortex Search Service may query any of the data the service has indexed, regardless of that role's privileges on the underlying objects." That includes rows behind row-level masking policies. - docs.snowflake.com, 13 Sep 2026
The Snowflake managed MCP server exposes five tool types (CORTEX_AGENT_RUN, CORTEX_SEARCH_SERVICE_QUERY, CORTEX_ANALYST_MESSAGE, SYSTEM_EXECUTE_SQL, GENERIC). It caps a server at 50 tools. It defaults SQL execution to read-only. It is not supported in government regions. - docs.snowflake.com, 13 Sep 2026
Cortex Agents is GA. It orchestrates Cortex Search, Cortex Analyst, a Python code execution sandbox, chart generation, custom tools, MCP connectors and web search. Billing runs across orchestration tokens, index size, warehouse compute and external tool calls. - docs.snowflake.com, 13 Sep 2026
Cortex AI Gateway, announced 28 July 2026, governs first- and third-party agents. It comes "with support for more than 100 MCP servers." It provides "a centralized, end-to-end record of agent activity." - Snowflake press release, 28 Jul 2026
Snowflake's pricing page lists four editions. It defers all dollar rates to an external Service Consumption Table. Cortex Search cost must be pieced together from several meters, not read off a page. - snowflake.com, 13 Sep 2026

Other head-to-heads

Same market

Get free Demo Center access

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →